Civitai 无限滚动 Feed 的 Layerize 性能治理合成器开销来源、修复实践与剩余优化杠杆【免费下载链接】civitaiA repository of models, textual inversions, and more项目地址: https://gitcode.com/GitHub_Trending/ci/civitai导读本文基于 docs/feed-layerize-investigation.md 整理系统梳理 Civitai 无限滚动 Feed 页面/images、个人主页 Feed、模型 Feed 等上 Chromium 合成器Layerize步骤的性能开销来源、已落地修复与仍未兑现的优化杠杆。读者将掌握Layerize在什么条件下触发、为什么 Feed 页面单次事件成本远高于普通页面、四条已修复的根因动画提升、数字滚动层风暴、非被动触摸监听、内容可见性以及七条待验证的优化手段A–G并得到可直接复用的决策规则与 10 秒空闲 trace 验证方法。本文是 docs/feed-layer-perf-checklist.mdcontent-visibility、图片右尺寸化、Mantine 补丁三项清单的姊妹篇聚焦合成器Layerize这一反复出现的痛点JS 侧的优化已在其他文档中覆盖。Layerize 是什么为什么 Feed 页面要为它买单Layerize是 Chromium 主线程上的一个步骤它遍历渲染树决定哪些元素应该成为独立的合成层composited layer。它在下述任一情况发生时运行合成原因compositing reasons发生变化——元素获得或失去will-change、transform、filter、opacity 1或激活/停止动画图层重叠分析需要重算——一个未被提升的元素与已提升图层重叠时可能被隐式提升implicit promotionDOM 变更影响图层树图层的边界bounds发生变化。Layerize的开销大致与变更子树下图层树的规模、复杂度成正比。单次大的Layerize发生在空闲时刻没有问题但在大图层树上每秒发生多次Layerize会饿死主线程并掉帧——这正是无限滚动 Feed 的典型场景。原始调查2026-04-28在一条 13.8 秒的生产空闲 trace 中测得4716 ms 的Layerize时间占墙钟时间的 34%而当时用户只是在页面上移动鼠标。后续多次回归与修复证明Feed 拥有多个相互叠加、彼此独立的Layerize来源。已知来源按贡献度大致排序1..scroll-area约 500 MB 的合成图层定义于 src/styles/globals.css:1321-1328.scroll-area { overflow-x: hidden; will-change: transform; position: relative; scrollbar-width: thin; display: flex; flex-direction: column; }will-change: transform强制整个可滚动区域成为一个独立的合成瓦片tile其尺寸等于完整的scrollHeight。在/images个人 Feed 上DevTools Layers 面板测得约500 MB估算值。任何需要遍历该图层的Layerize事件其开销都与其尺寸成正比——这就是为什么 Feed 页面上单事件Layerize成本始终高于非 Feed 页面。2026-04-28 曾尝试移除will-change: transform结果滚动流畅度回退。事后查明是混淆因素MantineuseClickOutside的非被动触摸监听把该图层标记为 slow-scroll region。在 Mantine 补丁落地后我们从未在更干净的环境下重新测试移除will-change——这仍是桌上最大的未兑现收益见下文杠杆 A。2. 重叠元素上的合成器不友好 CSS 动画每次页面加载都有四个无限 CSS 动画在运行SupportButton 的 pulse bounce、RewardsBonusBanner 的 gradient shimmer。它们动画化的属性都不是合成器友好的box-shadow、background-position因此每帧都触发主线程绘制。由于这些元素在视觉上与巨大的.scroll-area图层重叠每次绘制都会针对 500 MB 图层重新运行重叠分析。状态已修复。四个元素现在都有will-change: transform其逐帧绘制被限制在自己的提升图层内。修复后生产 trace 中的AnimationFrame::Render次数从 882/13.8s 降到 0/10.7s。此外还有一个尚未定位的第五个动画——2026-04-29 DOM 扫描发现的button-highlight动画动画化background-position见下文未决调查。3. CustomNumberFlow 栈提升风暴Feed 上每个AnimatedCount实例源码位于 src/components/Metrics/AnimatedCount.tsx经 src/components/Metrics/LiveMetric.tsx 使用渲染多个数字列每列包含一个.stackspan通过垂直位移显示当前数字。首个实现为.stack设置了will-change: transform永久地把每一位数字提升为独立合成层。按约 30 张活跃卡片 × 6 个反应计数 × 每位 1–4 个数字估算全 Feed 达到400 个永久提升图层。每个Layerize事件都必须遍历它们全部。状态已修复2026-04-29。从 src/components/Metrics/CustomNumberFlow.module.css 的.stack移除了will-change: transform。当前源码中.stack仅保留transition: transform 400ms cubic-bezier(0.4, 0, 0.2, 1)见第 36-42 行Chrome 仍会在数字滚动期间为栈提升图层滚动结束后自动降级——空闲时无动画时图层风暴消失。该文件还包含prefers-reduced-motion: reduce降级处理第 66-73 行。4. MantineuseClickOutside非被动touchstart监听每个 MantinePopoverMenu、HoverCard、Combobox等的基础原语都会在document上注册一个非被动touchstart监听无论弹层是否打开。Feed 卡片上挂载约 30 个Menu实例时就堆叠出 30 个 document 监听触发 Chromium 的 Slow scroll regions with many touch event handlers 提升把 Feed 图层标记为慢滚动区域。状态已修复。通过pnpm patch对mantine/hooks打补丁使useClickOutside的touchstart监听变为被动passive。该 bug 在 v8.3.18 与 v9.1.1 中依然存在所以补丁可跨版本存活。补丁内容见 patches/mantine__hooks.patch核心是- (fn) document.addEventListener(fn, listener, ...) (fn) document.addEventListener(fn, listener, fn.startsWith(touch) ? { passive: true } : undefined)补丁只对以touch开头的事件附加 passive 标志避免扰动mousedown监听行为ESM 与 CJS 两份构建均需同改。5. 虚拟化行上的 content-visibilityMasonryColumnsVirtual的每一行使用content-visibility: auto加contain-intrinsic-size让浏览器跳过屏外 overscan 行的布局/绘制。这在单独来看是真实的收益——但每一行也因此拥有自己的隐式 IntersectionObservercontent-visibility: auto的内部机制再叠加我们显式的useInViewIntersectionObserver两者相互叠加。状态已上线、互补但值得做一次受控测试。若修复后的 trace 在空闲时仍显示偏高Layerize下一步实验就是移除content-visibility: auto重新 trace。它可能用滚动期收益换取空闲期合成器成本。源码佐证在 src/components/MasonryColumns/MasonryColumnsVirtual.tsx:156-157行 wrapper 同时设置了contentVisibility: auto与containIntrinsicSize配合第 148 行显式height保证虚拟化滚动数学不受影响。数字上的体现同页面的生产空闲 trace日期Layerize总量事件数单事件均值掉帧率2026-04-28 基线4716 ms / 13.8 s34%44010.7 ms50%2026-04-28 部署后CustomNumberFlow 带will-change8522 ms / 10.7 s79%37422.8 ms75%2026-04-29 预期移除will-change后TBDTBDTBDTBD中间的回归4 月 28 日部署后清楚展示了一个看似安全的小元素上的will-change声明可以把图层数量放大约 50 倍并让单事件Layerize成本翻倍。教训是Feed 页面组件中任何新增的will-change声明合并前都必须先评估实例数量。仍可兑现的杠杆按投入产出比大致排序。A. 重新尝试移除.scroll-area的will-change: transform这是最大的潜在单项收益。500 MB 图层是单次Layerize成本的上限没有它Chrome 会基于可见内容自动瓦片化可滚动区域而不是把完整scrollHeight备份成一张纹理。与 2026-04-28 失败尝试相比当前条件已实质不同MantineuseClickOutside监听已被动化不再标记 slow-scroll region四个动画重叠已消除不再逐帧对图层做重叠抖动CustomNumberFlow 栈图层风暴已消失。这是在新基线上唯一可能让情况变差的变更因此值得在干净条件下做一次受控测试。测试计划创建分支从.scroll-area移除will-change: transform在civitai.red上采集一条空闲 trace 和一条滚动 trace与修复后基线移除.stack的will-change之后采集的下一条空闲 trace对比重点观察Feed scroll-area 的图层内存估算目标降到视口瓦片大小远低于 100 MB触摸设备上的滚动流畅度历史上唯一回退过的东西Slow scroll regions 警告是否重现说明仍有未发现的非被动监听。权衡若滚动手感仍回退说明还存在未发现的非被动监听来源。检测脚本[touchstart,touchmove,wheel].forEach(...)源自 Mantine 补丁验证会把它暴露出来。B. 定位并修复button-highlight动画2026-04-29 DOM 扫描发现一个未入账的无限动画button-highlight background-positionbackground-position不是合成器友好属性因此动画元素每帧都会重绘。若该元素全局挂载header、sidebar、AppLayout或在每张卡片上就会产生与已修复的四个动画相同的重叠分析效应。步骤定位元素document.querySelectorAll(*).forEach((el) { if (getComputedStyle(el).animationName button-highlight) console.log(el); });在代码库中 grep keyframesgrep -rn keyframes button-highlight src/套用与 SupportButton 相同的修复模式在动画元素上直接加will-change: transform使其重绘停留在自己的合成层内。改动虽小但结构与已上线的 SupportButton 修复完全同构。C. 每行contain: layout paint做更强隔离MasonryColumnsVirtual已为每行添加content-visibility: auto。在同一 wrapper 上再叠加contain: layout paint甚至仅contain: paint可提供更强隔离某一行子树内的变更图片解码、hover 状态、NumberFlow 数值变化不会使父 Feed 图层的重叠分析失效。重要告诫contain: paint曾因保存的记忆笔记被否决在父级.scroll-area上——该否决只针对父级。用在单行上结构不同每行很小约一张卡片大小单层成本可忽略隔离收益真实存在不干扰父 scroll-area 的提升机制。仅在杠杆 A 未能完全解决Layerize成本时才测试此项。实现在 src/components/MasonryColumns/MasonryColumnsVirtual.tsx:132-146 的行 wrapper 样式中加一行。D. 收紧IntersectionObserverProvider的 rootMarginsrc/components/IntersectionObserver/IntersectionObserverProvider.tsx:182 设置了rootMargin: 100% 0px——这会把约3 倍视口高度的卡片计为在视内用于实时指标订阅。收紧为25% 0px或0px可减少活跃的实时指标订阅数量信号流量期间的 NumberFlow 分配压力滚动期间的强制布局forced layout。代价是卡片进入视口时可能出现更多0 → 真实值的闪烁若指标在屏外时更新过。服务端拉取的初始值让这一影响有界。该项与Layerize无直接关系——它削减的是每次信号扇出per-signal-fan-out的成本。在此提及是因为它与多个 Feed 页面成本同时交互。E. 验证 content-visibility 的净效果每行上的content-visibility: auto是在逐行绘制隔离的收益大于每行隐式 IntersectionObserver 开销的假设下添加的。2026-04-28 部署后的 trace 中 IO 计算时间升高93 ms 对比基线 43 ms可能说明隐式 observer 有贡献。测试计划分支中移除虚拟化行 wrapper 的contentVisibility: auto与containIntrinsicSize采集空闲 滚动 trace与最新基线对比若Layerize总量下降说明 content-visibility 在合成器成本上是净负值需与其滚动期收益权衡若Layerize总量不变或上升说明 content-visibility 工作正常保留。这是低优先级实验——仅在杠杆 A 与 C 未能完全解决Layerize成本时值得做。F. 图片解码稳定性每个img在滚动中途完成解码都可能触发其父级的Layerize图层树新增一张图片位图图层。确保所有 Feed 图片使用decodingasync与loadinglazy可把解码工作移出滚动 tick 路径。检查点src/components/EdgeMedia/EdgeImage.tsx 及EdgeMedia2内的图片渲染是否具备这些属性缺失则补上。单项收益较小但在多张卡片上会累积放大。G. 滚动期间订阅去抖滚动时卡片的挂载/卸载会向 signals worker 发送topic:register与topic:unsubscribe消息worker 再转发到 SignalR hub。快速滚动 快速订阅抖动。本地插桩被回退前未获得干净的 prod 测量值但生产 trace 中 348 条 worker 端口消息/秒2026-04-28暗示其规模可观。对SignalsProvider的releaseTopic做 250 ms 去抖可平滑该抖动卡片滚出 → 250 ms 后调度释放同一卡片在 250 ms 内滚回 rootMargin 内 → 取消释放无抖动否则 → 延迟后释放。不直接影响Layerize但减少了与Layerize叠加导致掉帧的逐帧 React 重渲染扇出。未决调查以下事项信息尚不足以决策button-highlight来源杠杆 B——修复前需先快速定位。生产 worker 消息量构成——本地插桩已回退本地 hub 不连接因此仍无法确定生产测得的 348 msg/sec 由订阅抖动杠杆 G、真实指标流量服务端限速还是其他信号类型主导。要回答需将插桩部署到 staging 或临时部署到 prod必要时查阅提交历史中的插桩 diff。.stack修复后的 Layers 面板合成原因——下一次空闲 trace 时截取 Layers 面板记录任何意外的合成原因。500 MB 的 scroll-area 图层应仍存在检查是否有其他东西冒出来。已排除的选项供后续读者参考以下方案曾被考虑并明确否决切换到窗口化虚拟化器基于 translate、无 spacer——因与 masonry 风格与观感偏离过大而否决。按桶边界分页 Feed——因 UX 原因否决。父级.scroll-area上的contain: paint——被用户记忆笔记否决由杠杆 C 的每行 containment 取代。JS 切换.scroll-area的will-change——尝试过否决。每次滚动开始时切换会在 Layers 面板产生可见过渡小图层 → 完整 Feed 图层。成本并未避免只是推迟到滚动开始感觉比始终开启更糟。从package.json完全移除number-flow/react——在验证CustomNumberFlow覆盖所有消费者需求前保持安装。移除是CustomNumberFlow在生产中证明后的后续动作。面向未来贡献者的决策规则要往 Feed 页面组件里加东西合并前快速过一遍清单不得新增will-change声明而不先测量实例数量。若元素每页渲染超过 50 次will-change很可能是错的让浏览器自己决定。不得在非合成器友好属性上新增无限 CSS 动画background-position、box-shadow、top/left等。若必须用will-change: transform提升动画元素使其重绘留在自己的图层内。不得在document或window上新增非被动touchstart/touchmove监听——它们会把自己所在的滚动区域标记为 slow-scroll region。带 ShadowRoot 的新自定义元素在规模化时很昂贵——每个都分配独立的 DOM 树与样式作用域。Feed 页面上 100 实例是性能悬崖。确保你添加到卡片的任何img都设置了decodingasync与loadinglazy。拿不准时在受影响页面上采集一条 10 秒空闲 trace对比变更前后的Layerize总量。总结从 34% 到可验证目标的路径围绕Layerize的治理形成了一条清晰的闭环先量化4716 ms / 13.8 s34% 墙钟时间→ 归因五类相互叠加的来源→ 修复动画提升、数字栈层风暴、被动触摸监听→ 再验证AnimationFrame::Render归零、下一步空闲 trace 对比。四个已修复根因中will-change滥用是最值得警惕的模式——一处看似无害的声明能把图层数量放大 50 倍。剩余杠杆 A移除.scroll-area的will-change是最大的潜在收益其成功与否取决于 touch 滚动手感与 Slow scroll regions 警告是否重现B–G 则按投入产出比依次推进。配套的 docs/feed-layer-perf-checklist.md 给出了三件套的落地顺序content-visibility→ 被动监听补丁 → 图片右尺寸化最终目标是让空闲 trace 的Layerize总量降到 500 ms 以下。【免费下载链接】civitaiA repository of models, textual inversions, and more项目地址: https://gitcode.com/GitHub_Trending/ci/civitai创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Civitai 无限滚动 Feed 的 Layerize 性能治理：合成器开销来源、修复实践与剩余优化杠杆
Civitai 无限滚动 Feed 的 Layerize 性能治理合成器开销来源、修复实践与剩余优化杠杆【免费下载链接】civitaiA repository of models, textual inversions, and more项目地址: https://gitcode.com/GitHub_Trending/ci/civitai导读本文基于 docs/feed-layerize-investigation.md 整理系统梳理 Civitai 无限滚动 Feed 页面/images、个人主页 Feed、模型 Feed 等上 Chromium 合成器Layerize步骤的性能开销来源、已落地修复与仍未兑现的优化杠杆。读者将掌握Layerize在什么条件下触发、为什么 Feed 页面单次事件成本远高于普通页面、四条已修复的根因动画提升、数字滚动层风暴、非被动触摸监听、内容可见性以及七条待验证的优化手段A–G并得到可直接复用的决策规则与 10 秒空闲 trace 验证方法。本文是 docs/feed-layer-perf-checklist.mdcontent-visibility、图片右尺寸化、Mantine 补丁三项清单的姊妹篇聚焦合成器Layerize这一反复出现的痛点JS 侧的优化已在其他文档中覆盖。Layerize 是什么为什么 Feed 页面要为它买单Layerize是 Chromium 主线程上的一个步骤它遍历渲染树决定哪些元素应该成为独立的合成层composited layer。它在下述任一情况发生时运行合成原因compositing reasons发生变化——元素获得或失去will-change、transform、filter、opacity 1或激活/停止动画图层重叠分析需要重算——一个未被提升的元素与已提升图层重叠时可能被隐式提升implicit promotionDOM 变更影响图层树图层的边界bounds发生变化。Layerize的开销大致与变更子树下图层树的规模、复杂度成正比。单次大的Layerize发生在空闲时刻没有问题但在大图层树上每秒发生多次Layerize会饿死主线程并掉帧——这正是无限滚动 Feed 的典型场景。原始调查2026-04-28在一条 13.8 秒的生产空闲 trace 中测得4716 ms 的Layerize时间占墙钟时间的 34%而当时用户只是在页面上移动鼠标。后续多次回归与修复证明Feed 拥有多个相互叠加、彼此独立的Layerize来源。已知来源按贡献度大致排序1..scroll-area约 500 MB 的合成图层定义于 src/styles/globals.css:1321-1328.scroll-area { overflow-x: hidden; will-change: transform; position: relative; scrollbar-width: thin; display: flex; flex-direction: column; }will-change: transform强制整个可滚动区域成为一个独立的合成瓦片tile其尺寸等于完整的scrollHeight。在/images个人 Feed 上DevTools Layers 面板测得约500 MB估算值。任何需要遍历该图层的Layerize事件其开销都与其尺寸成正比——这就是为什么 Feed 页面上单事件Layerize成本始终高于非 Feed 页面。2026-04-28 曾尝试移除will-change: transform结果滚动流畅度回退。事后查明是混淆因素MantineuseClickOutside的非被动触摸监听把该图层标记为 slow-scroll region。在 Mantine 补丁落地后我们从未在更干净的环境下重新测试移除will-change——这仍是桌上最大的未兑现收益见下文杠杆 A。2. 重叠元素上的合成器不友好 CSS 动画每次页面加载都有四个无限 CSS 动画在运行SupportButton 的 pulse bounce、RewardsBonusBanner 的 gradient shimmer。它们动画化的属性都不是合成器友好的box-shadow、background-position因此每帧都触发主线程绘制。由于这些元素在视觉上与巨大的.scroll-area图层重叠每次绘制都会针对 500 MB 图层重新运行重叠分析。状态已修复。四个元素现在都有will-change: transform其逐帧绘制被限制在自己的提升图层内。修复后生产 trace 中的AnimationFrame::Render次数从 882/13.8s 降到 0/10.7s。此外还有一个尚未定位的第五个动画——2026-04-29 DOM 扫描发现的button-highlight动画动画化background-position见下文未决调查。3. CustomNumberFlow 栈提升风暴Feed 上每个AnimatedCount实例源码位于 src/components/Metrics/AnimatedCount.tsx经 src/components/Metrics/LiveMetric.tsx 使用渲染多个数字列每列包含一个.stackspan通过垂直位移显示当前数字。首个实现为.stack设置了will-change: transform永久地把每一位数字提升为独立合成层。按约 30 张活跃卡片 × 6 个反应计数 × 每位 1–4 个数字估算全 Feed 达到400 个永久提升图层。每个Layerize事件都必须遍历它们全部。状态已修复2026-04-29。从 src/components/Metrics/CustomNumberFlow.module.css 的.stack移除了will-change: transform。当前源码中.stack仅保留transition: transform 400ms cubic-bezier(0.4, 0, 0.2, 1)见第 36-42 行Chrome 仍会在数字滚动期间为栈提升图层滚动结束后自动降级——空闲时无动画时图层风暴消失。该文件还包含prefers-reduced-motion: reduce降级处理第 66-73 行。4. MantineuseClickOutside非被动touchstart监听每个 MantinePopoverMenu、HoverCard、Combobox等的基础原语都会在document上注册一个非被动touchstart监听无论弹层是否打开。Feed 卡片上挂载约 30 个Menu实例时就堆叠出 30 个 document 监听触发 Chromium 的 Slow scroll regions with many touch event handlers 提升把 Feed 图层标记为慢滚动区域。状态已修复。通过pnpm patch对mantine/hooks打补丁使useClickOutside的touchstart监听变为被动passive。该 bug 在 v8.3.18 与 v9.1.1 中依然存在所以补丁可跨版本存活。补丁内容见 patches/mantine__hooks.patch核心是- (fn) document.addEventListener(fn, listener, ...) (fn) document.addEventListener(fn, listener, fn.startsWith(touch) ? { passive: true } : undefined)补丁只对以touch开头的事件附加 passive 标志避免扰动mousedown监听行为ESM 与 CJS 两份构建均需同改。5. 虚拟化行上的 content-visibilityMasonryColumnsVirtual的每一行使用content-visibility: auto加contain-intrinsic-size让浏览器跳过屏外 overscan 行的布局/绘制。这在单独来看是真实的收益——但每一行也因此拥有自己的隐式 IntersectionObservercontent-visibility: auto的内部机制再叠加我们显式的useInViewIntersectionObserver两者相互叠加。状态已上线、互补但值得做一次受控测试。若修复后的 trace 在空闲时仍显示偏高Layerize下一步实验就是移除content-visibility: auto重新 trace。它可能用滚动期收益换取空闲期合成器成本。源码佐证在 src/components/MasonryColumns/MasonryColumnsVirtual.tsx:156-157行 wrapper 同时设置了contentVisibility: auto与containIntrinsicSize配合第 148 行显式height保证虚拟化滚动数学不受影响。数字上的体现同页面的生产空闲 trace日期Layerize总量事件数单事件均值掉帧率2026-04-28 基线4716 ms / 13.8 s34%44010.7 ms50%2026-04-28 部署后CustomNumberFlow 带will-change8522 ms / 10.7 s79%37422.8 ms75%2026-04-29 预期移除will-change后TBDTBDTBDTBD中间的回归4 月 28 日部署后清楚展示了一个看似安全的小元素上的will-change声明可以把图层数量放大约 50 倍并让单事件Layerize成本翻倍。教训是Feed 页面组件中任何新增的will-change声明合并前都必须先评估实例数量。仍可兑现的杠杆按投入产出比大致排序。A. 重新尝试移除.scroll-area的will-change: transform这是最大的潜在单项收益。500 MB 图层是单次Layerize成本的上限没有它Chrome 会基于可见内容自动瓦片化可滚动区域而不是把完整scrollHeight备份成一张纹理。与 2026-04-28 失败尝试相比当前条件已实质不同MantineuseClickOutside监听已被动化不再标记 slow-scroll region四个动画重叠已消除不再逐帧对图层做重叠抖动CustomNumberFlow 栈图层风暴已消失。这是在新基线上唯一可能让情况变差的变更因此值得在干净条件下做一次受控测试。测试计划创建分支从.scroll-area移除will-change: transform在civitai.red上采集一条空闲 trace 和一条滚动 trace与修复后基线移除.stack的will-change之后采集的下一条空闲 trace对比重点观察Feed scroll-area 的图层内存估算目标降到视口瓦片大小远低于 100 MB触摸设备上的滚动流畅度历史上唯一回退过的东西Slow scroll regions 警告是否重现说明仍有未发现的非被动监听。权衡若滚动手感仍回退说明还存在未发现的非被动监听来源。检测脚本[touchstart,touchmove,wheel].forEach(...)源自 Mantine 补丁验证会把它暴露出来。B. 定位并修复button-highlight动画2026-04-29 DOM 扫描发现一个未入账的无限动画button-highlight background-positionbackground-position不是合成器友好属性因此动画元素每帧都会重绘。若该元素全局挂载header、sidebar、AppLayout或在每张卡片上就会产生与已修复的四个动画相同的重叠分析效应。步骤定位元素document.querySelectorAll(*).forEach((el) { if (getComputedStyle(el).animationName button-highlight) console.log(el); });在代码库中 grep keyframesgrep -rn keyframes button-highlight src/套用与 SupportButton 相同的修复模式在动画元素上直接加will-change: transform使其重绘停留在自己的合成层内。改动虽小但结构与已上线的 SupportButton 修复完全同构。C. 每行contain: layout paint做更强隔离MasonryColumnsVirtual已为每行添加content-visibility: auto。在同一 wrapper 上再叠加contain: layout paint甚至仅contain: paint可提供更强隔离某一行子树内的变更图片解码、hover 状态、NumberFlow 数值变化不会使父 Feed 图层的重叠分析失效。重要告诫contain: paint曾因保存的记忆笔记被否决在父级.scroll-area上——该否决只针对父级。用在单行上结构不同每行很小约一张卡片大小单层成本可忽略隔离收益真实存在不干扰父 scroll-area 的提升机制。仅在杠杆 A 未能完全解决Layerize成本时才测试此项。实现在 src/components/MasonryColumns/MasonryColumnsVirtual.tsx:132-146 的行 wrapper 样式中加一行。D. 收紧IntersectionObserverProvider的 rootMarginsrc/components/IntersectionObserver/IntersectionObserverProvider.tsx:182 设置了rootMargin: 100% 0px——这会把约3 倍视口高度的卡片计为在视内用于实时指标订阅。收紧为25% 0px或0px可减少活跃的实时指标订阅数量信号流量期间的 NumberFlow 分配压力滚动期间的强制布局forced layout。代价是卡片进入视口时可能出现更多0 → 真实值的闪烁若指标在屏外时更新过。服务端拉取的初始值让这一影响有界。该项与Layerize无直接关系——它削减的是每次信号扇出per-signal-fan-out的成本。在此提及是因为它与多个 Feed 页面成本同时交互。E. 验证 content-visibility 的净效果每行上的content-visibility: auto是在逐行绘制隔离的收益大于每行隐式 IntersectionObserver 开销的假设下添加的。2026-04-28 部署后的 trace 中 IO 计算时间升高93 ms 对比基线 43 ms可能说明隐式 observer 有贡献。测试计划分支中移除虚拟化行 wrapper 的contentVisibility: auto与containIntrinsicSize采集空闲 滚动 trace与最新基线对比若Layerize总量下降说明 content-visibility 在合成器成本上是净负值需与其滚动期收益权衡若Layerize总量不变或上升说明 content-visibility 工作正常保留。这是低优先级实验——仅在杠杆 A 与 C 未能完全解决Layerize成本时值得做。F. 图片解码稳定性每个img在滚动中途完成解码都可能触发其父级的Layerize图层树新增一张图片位图图层。确保所有 Feed 图片使用decodingasync与loadinglazy可把解码工作移出滚动 tick 路径。检查点src/components/EdgeMedia/EdgeImage.tsx 及EdgeMedia2内的图片渲染是否具备这些属性缺失则补上。单项收益较小但在多张卡片上会累积放大。G. 滚动期间订阅去抖滚动时卡片的挂载/卸载会向 signals worker 发送topic:register与topic:unsubscribe消息worker 再转发到 SignalR hub。快速滚动 快速订阅抖动。本地插桩被回退前未获得干净的 prod 测量值但生产 trace 中 348 条 worker 端口消息/秒2026-04-28暗示其规模可观。对SignalsProvider的releaseTopic做 250 ms 去抖可平滑该抖动卡片滚出 → 250 ms 后调度释放同一卡片在 250 ms 内滚回 rootMargin 内 → 取消释放无抖动否则 → 延迟后释放。不直接影响Layerize但减少了与Layerize叠加导致掉帧的逐帧 React 重渲染扇出。未决调查以下事项信息尚不足以决策button-highlight来源杠杆 B——修复前需先快速定位。生产 worker 消息量构成——本地插桩已回退本地 hub 不连接因此仍无法确定生产测得的 348 msg/sec 由订阅抖动杠杆 G、真实指标流量服务端限速还是其他信号类型主导。要回答需将插桩部署到 staging 或临时部署到 prod必要时查阅提交历史中的插桩 diff。.stack修复后的 Layers 面板合成原因——下一次空闲 trace 时截取 Layers 面板记录任何意外的合成原因。500 MB 的 scroll-area 图层应仍存在检查是否有其他东西冒出来。已排除的选项供后续读者参考以下方案曾被考虑并明确否决切换到窗口化虚拟化器基于 translate、无 spacer——因与 masonry 风格与观感偏离过大而否决。按桶边界分页 Feed——因 UX 原因否决。父级.scroll-area上的contain: paint——被用户记忆笔记否决由杠杆 C 的每行 containment 取代。JS 切换.scroll-area的will-change——尝试过否决。每次滚动开始时切换会在 Layers 面板产生可见过渡小图层 → 完整 Feed 图层。成本并未避免只是推迟到滚动开始感觉比始终开启更糟。从package.json完全移除number-flow/react——在验证CustomNumberFlow覆盖所有消费者需求前保持安装。移除是CustomNumberFlow在生产中证明后的后续动作。面向未来贡献者的决策规则要往 Feed 页面组件里加东西合并前快速过一遍清单不得新增will-change声明而不先测量实例数量。若元素每页渲染超过 50 次will-change很可能是错的让浏览器自己决定。不得在非合成器友好属性上新增无限 CSS 动画background-position、box-shadow、top/left等。若必须用will-change: transform提升动画元素使其重绘留在自己的图层内。不得在document或window上新增非被动touchstart/touchmove监听——它们会把自己所在的滚动区域标记为 slow-scroll region。带 ShadowRoot 的新自定义元素在规模化时很昂贵——每个都分配独立的 DOM 树与样式作用域。Feed 页面上 100 实例是性能悬崖。确保你添加到卡片的任何img都设置了decodingasync与loadinglazy。拿不准时在受影响页面上采集一条 10 秒空闲 trace对比变更前后的Layerize总量。总结从 34% 到可验证目标的路径围绕Layerize的治理形成了一条清晰的闭环先量化4716 ms / 13.8 s34% 墙钟时间→ 归因五类相互叠加的来源→ 修复动画提升、数字栈层风暴、被动触摸监听→ 再验证AnimationFrame::Render归零、下一步空闲 trace 对比。四个已修复根因中will-change滥用是最值得警惕的模式——一处看似无害的声明能把图层数量放大 50 倍。剩余杠杆 A移除.scroll-area的will-change是最大的潜在收益其成功与否取决于 touch 滚动手感与 Slow scroll regions 警告是否重现B–G 则按投入产出比依次推进。配套的 docs/feed-layer-perf-checklist.md 给出了三件套的落地顺序content-visibility→ 被动监听补丁 → 图片右尺寸化最终目标是让空闲 trace 的Layerize总量降到 500 ms 以下。【免费下载链接】civitaiA repository of models, textual inversions, and more项目地址: https://gitcode.com/GitHub_Trending/ci/civitai创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考