レンダリングパイプライン — どのCSSが重いかは工程で決まる

What — HTML から画面までの5工程

同じ「動かす」でも工程数が違う

element.style.top = '100px';

Style → Layout → Paint → Composite
      ~~~~~~~~~~~~~~~~~~~~~~~~~~
      3工程やり直し

Why — なぜ Layout が飛び抜けて重いのか

Layout が重いのは、1箇所の変更が全体に波及しうるからです。

ある要素の幅を広げると、その中のテキストの折り返し位置が変わります。行数が変われば高さが変わり、高さが変われば下にある要素が押し下げられ、それが親の高さを変え、さらに上の階層に波及する。変更の影響範囲を事前に限定できないため、ブラウザは広い範囲を計算し直します。

Paint は影響が限定的です。色が変わっても、他の要素の位置は動きません。Composite に至っては、すでに描き終わった絵を GPU で重ねるだけなので、計算らしい計算がありません。

この3段階の差は構造的なものであり、ブラウザの実装が改善しても順序は変わりません。

強制同期レイアウトという落とし穴

さらに厄介なのが、読み取りと書き込みを交互に行うパターンです。

// これは非常に遅い
for (const el of elements) {
  el.style.width = el.offsetWidth + 10 + 'px';
  //               ~~~~~~~~~~~~~~ 読み取り
  // ~~~~~~~~~~~~~ 書き込み
}

ブラウザは、書き込みをすぐには反映せず溜めておきます。しかし offsetWidth のような現在の値を問い合わせる操作が来ると、溜めた変更を全部適用して Layout を走らせないと正しい値が返せません。

結果として、ループの回数だけ Layout が実行されます。100要素なら100回。これが強制同期レイアウトです。

// 読み取りを先に全部済ませてから、書き込みをまとめる
const widths = elements.map((el) => el.offsetWidth);
elements.forEach((el, i) => {
  el.style.width = widths[i] + 10 + 'px';
});
// Layout は 1 回で済む

演習 — まず自分で判断する

解説を読む前に、まず自分で判断してみてください。ここで一度詰まっておくと、 次の節の判断軸が「なるほど」ではなく「そう来たか」に変わります。