Output Console——借助 shadow DOM 快 50×
Output Console——抓取页面日志的开发者窗口——长期以来有一个限制：条目超过几百条之后，渲染就开始拖沓。列表里有 700 条时，窗口每次更新都会卡顿——每次 re-render 大约 ~5 秒。在 v3.2.30 中，我们把这个窗口包进了 shadow DOM——除了把样式与页面隔离开之外，还意外地获得了一次巨大的提速。同样的 700 条条目，如今 ~100 毫秒就能渲染完。快了五十倍。
慢从哪里来
Output Console 过去作为普通元素挂在页面的 DOM 树里。每新增一条都会迫使浏览器对树中每个元素重新计算样式——因为页面 CSS 理论上可能影响其中之一。对 700+ 个元素做 style recalc，加上后台 500+ 页 CSS，再加上窗口在每条新日志时都要重新渲染——这些累加起来就是肉眼可见的延迟。
额外成本：某些服务（Google Workspace、Notion、企业内网）会在页面样式表里塞进数千条 CSS 规则。Output Console 每出现一行新内容，都要在数千个选择器上做匹配搜索——其中是否有命中我们的？
shadow DOM 做了什么
把窗口渲染为 shadow root，就是在告诉浏览器：页面样式不适用于这棵子树。每新增一条时，浏览器会跳过选择器匹配搜索。Style recalc 只作用于 shadow root 内部的样式——只有 Output Console 自己几十行的 CSS，而不是页面上千行的 CSS。
效果：profiler 显示，shadow DOM 之前的渲染时间中有 87% 浪费在 Output Console 节点的 RecalculateStyle 上。迁移之后，这部分成本几乎消失了。
我们怎么测的
Repro：一个激活了 Output Console 的页面，加上 700 条已有条目（Network、Console、dataLayer）。DevTools 的 Performance 面板，操作：JUSTZIX.log('test ' + i) 跑一个 100× 的循环。
- v3.2.30 之前（light DOM）：100 条新条目 = ~5000 毫秒主渲染时间。
- v3.2.30 之后（shadow DOM）：100 条新条目 = ~100 毫秒。
实际倍数取决于页面——在极简页面（about:blank）上只有 5×，在生产环境的 Google Workspace 上则接近 60×。"50×"是大致的中位数——所以我们用它作为标题。
这对工作流的改变
三种它真正起作用的具体情境：
- 长时间调试——你把 Output Console 留在屏幕上数小时，页面在后台正常活动（自动保存、轮询、GTM 事件）。以前过一段时间窗口就会变迟钝；现在它一直保持响应。
- 网络风暴——分析每秒触发 ~100 个请求的页面的瀑布图（例如带 lazy-load 的无限滚动）。以前窗口比真实流量落后半秒；现在能跟上。
- dataLayer 监视——GTM 非常活跃的页面（电商、CRM 看板）每秒 push 5–10 个事件。"新 push"的列表增长很快——现在你可以实时滚动查看。
这会影响其他窗口吗
Output Console 是第一个迁移到 shadow DOM 的窗口（v3.2.30）。同样的模式随后用到了 AI Helper（v3.2.76，见单独的文章）。其余的开发者窗口——CSS 面板、JS 面板、JS Console——仍然活在 light DOM 中。它们每一个的节点都少得多（CSS 面板 = 一个 textarea 加一个标题栏，JS 面板类似），所以并没有承受同样的性能冲击。把它们迁移过去，被规划为这次隔离的自然延伸。
另请参阅
- Output Console——窗口与其各个标签页的完整说明
- AI Helper 进入 shadow DOM——窗口隔离的第二步
- 页面窗口——扩展自带的每一个开发者窗口
安装 JustZix——拥有一个跟得上页面流量的 Output Console。
为这篇文章评分
暂无评分 — 成为第一个。