CSS性能调优实录：选择器匹配成本与重排重绘分析

最近接手了一个后台项目，页面里的表格有两千多行，上线之后运营同事反馈"滚动的时候卡得像幻灯片"。我第一反应是 JS 的问题，打开 Performance 面板录了一段，结果发现脚本执行只占了不到 15%，真正的大头是 Layout 和 Paint——每次滚动都有一次全表重排。这让我重新审视了一个老话题：CSS 到底会不会成为性能瓶颈，以及它在什么情况下才会。

这篇文章不打算罗列"CSS 性能优化 20 条"这类清单，而是把我这轮排查的过程和结论记下来，重点放在两个经常被混为一谈的概念上：选择器匹配成本和重排重绘。

先给选择器匹配成本一个客观的位置

网上流传很广的说法是"后代选择器很慢，尽量用类选择器"，这话对，但被夸大了。

浏览器的选择器匹配是从右向左进行的。对于 .list .item .title span，引擎会先找出所有 span，然后逐级向上验证祖先。这意味着最右侧的那一段（key selector）决定了候选集的大小，左边的部分只是过滤条件。所以真正影响匹配成本的不是选择器有多长，而是最右端的选择器有多"泛"。

我们用 Chrome DevTools 的 Selector Stats 在一段渲染 5000 个节点的列表上做过对比：

• 纯类选择器 .cell-title：匹配耗时约 4ms
• 三层后代 .table .row .cell .cell-title：约 11ms
• 通配符 *：约 60ms+
• 属性选择器 [data-status="done"]：约 18ms

结论很清楚：类选择器之间的差异在毫秒级，真正的坑是 * 和宽泛的属性选择器。如果你的页面节点规模在几百个量级，选择器写法基本不会成为瓶颈，把精力花在这上面属于过早优化。

顺带修正一个常见误解：div.title 和 .title 在现代引擎里性能几乎无差，但前者可读性和复用性更差，没有理由写。

重排与重绘：代价差着一个数量级

这两个概念的区别值得反复强调：

• 重排（Layout / Reflow）：几何属性变了，浏览器必须重新计算每个元素的位置和尺寸。改 width、height、margin、padding、font-size、top/left、display 都会触发。
• 重绘（Paint）：外观变了但布局没变，比如 color、background-color、visibility、box-shadow。
• 仅合成（Composite）：transform 和 opacity 可以完全绕过前两步，直接交给 GPU 合成层。

那次表格卡顿的根因就在这里：行悬停效果我用了 background-color 过渡，同时给行加了 padding-left 的位移动画。前者触发重绘还算便宜，后者每次 hover 都要重新计算整个表格的列宽——两千行的表格，一次重排就是几十毫秒。

改成 transform: translateX(4px) 加 will-change: transform 之后，hover 的帧率从 20fps 直接回到 60fps。凡是能用 transform 替代 top/left/margin 的地方，都应该换掉。

布局抖动：比单次重排更致命

比"一次重排很贵"更糟糕的是"强制同步布局"，也就是常说的 layout thrashing。

看这段代码：

for (const row of rows) {
  row.style.width = row.offsetWidth + 10 + 'px';
}

每次循环里，读 offsetWidth 会强制浏览器立刻结算当前所有待处理的样式变更并执行一次布局，紧接着的写操作又让它变成脏状态。循环一千次，就是一千次同步重排。

修复方式很朴素：读写分离。先用一轮循环把需要的值全部读出来，再用另一轮统一写回；或者用 requestAnimationFrame 把写操作推迟到下一帧。这个改动在我们那个表格里把交互耗时从 400ms 降到了 30ms 以内。

把代价关进笼子

除了改写触发属性，还有几个工具值得用起来：

• contain: layout paint：告诉浏览器这个子树的变化不会影响外部，布局计算可以被局部化。用在列表项、卡片这类独立组件上效果明显。
• content-visibility: auto：让视口外的内容跳过渲染，配合 contain-intrinsic-size 避免滚动条跳动。长列表页面的收益非常直接。
• will-change 要节制：它会把元素提升为独立图层，滥用会吃掉大量显存，反而拖慢合成。只在动画开始前加，结束后移除。

写在最后

CSS 性能排查有一条朴素的优先级：**先看触发了什么（重排 > 重绘 > 合成），再看动画属性能不能换成 transform，最后才去纠结选择器写法**。选择器匹配在现代浏览器里早已不是主要矛盾，把 * 和深层后代收敛掉就够了，不必为此重构整个样式表。

真正值得投入时间的地方，是理解浏览器渲染管线的那几个阶段，以及在 Performance 面板里读懂 Layout 那一栏为什么突然拉长。工具会告诉你答案，前提是你知道该问什么问题。