レンダリングパイプライン
Rendering Pipeline各要素に当たる CSS を確定する Style、位置とサイズを計算する Layout、ピクセル列に落とす Paint、GPU でレイヤーを合成する Composite の 4 段階で構成される。どの CSS プロパティを変更したかによって、この中の「どこまで走るか」が決まる。
§ Glossary
フロントエンド道場で使われる語の一覧です。各 Lab の解説文にも同じ用語が登場し、 下線付きの語にカーソルを合わせると短い定義が出ます。ここはその詳しい版です。
各要素に当たる CSS を確定する Style、位置とサイズを計算する Layout、ピクセル列に落とす Paint、GPU でレイヤーを合成する Composite の 4 段階で構成される。どの CSS プロパティを変更したかによって、この中の「どこまで走るか」が決まる。
DOM とスタイルシートを突き合わせ、各要素の最終的なスタイル値（computed style）を確定する段階。どの CSS プロパティを変えても Style は必ず走る。DevTools Performance パネルでは紫で表示される。
確定した Style をもとに、要素の位置・サイズ・行送りなどを決める工程。width / height / top / margin などサイズや位置に関わるプロパティを変えると走る。周囲の要素にも影響が及ぶため、発生するコストは比較的大きい。
Layout の結果に基づいて、各要素を実際のピクセル（色・枠・影など）として描き込む段階。まだ画面に出る前のレイヤー単位の仕上げで、background-color / color / box-shadow など見た目系のプロパティで走る。
Paint で作られた合成レイヤーを GPU で重ね合わせて最終画面を作る段階。transform や opacity はこの段階の情報だけを書き換えるため、Layout / Paint をスキップできる。アニメーションを軽くするなら transform / opacity を使う、という定石の根拠はここにある。
ブラウザは要素を複数の内部レイヤーに分けて Paint し、最後に Composite で重ね合わせる。will-change: transform や 3D transform などが適用されるとレイヤーが独立し、そのレイヤーだけを GPU で動かせるため軽くなる。ただしレイヤー数が増えすぎるとメモリと GPU 負荷が跳ね上がる副作用もある。
歴史的には Gecko 由来の呼び方。Chromium では Layout と呼ぶが、実質同じものを指していることがほとんど。ブログなどでは Reflow / Relayout / Layout が混在するので、読むときは同義と思って差し支えない。
Layout が不要（位置・サイズが変わらない）だが描き直しが必要な変更に対して走る。background-color や box-shadow の変更はこの Repaint のみで済むケース。
従来の long task API よりも細かく、個別フレームに対して scriptDuration / styleAndLayoutStart / renderStart / duration などを取得できる。Safari / Firefox では未対応。本サイトの実測はこの API をベースにしている。
PerformanceObserver で type: "longtask" を観測すると、50 ms を超えたタスクが取れる。LoAF 非対応ブラウザではこちらがフォールバックとして使われる。
Paul Lewis らが公開していた分類表。Blink / Gecko / WebKit のソースに埋まっている「どのプロパティがどのフェーズに影響するか」を整理したもので、本サイトの「理論」列はこれに準拠している。原典サイトは閉鎖されたがアーカイブが閲覧可能。
標準的な画面は 60 Hz リフレッシュレートなので、60 FPS = 毎フレーム 16.67 ms 以内に描画が終わっている状態。下がると「カクつき」「ジャンク」として体感される。
60 Hz の画面で 60 FPS を維持するには、1000ms / 60 ≒ 16.67 ms に全ての処理（JS 実行 + Style + Layout + Paint + Composite）を収める必要がある。現実的には 10 ms 前後で終えて、余裕を残すのが望ましい。
setTimeout や setInterval の代わりに使うアニメーション用 API。ブラウザのフレームタイミングに同期するため、無駄な中間フレームが走らない。本サイトの FPS メーターもこれをベースに測定している。
observer.observe({ type: ... }) で必要なエントリ種別だけを指定して観測する。本サイトの RUM とフレーム計測はこの API の上に成り立っている。
⌘⌥I で開き、Performance タブで Record ボタンを押すと、その間のフレーム内訳がタイムラインで表示される。紫 = Rendering（Style + Layout）、緑 = Painting、黄色 = Scripting、水色 = Loading。本サイトの計測と対応する。
ビューポート内で最大の画像やテキストブロックが描画されたタイミング。ユーザーが「ページが来た」と感じる瞬間の近似。画像の最適化、フォント遅延、サーバ応答改善が主な打ち手。
2024 年から FID（First Input Delay）を置き換えた指標。クリック/タップ/キー入力からブラウザが次に画面を更新するまでの時間を取る。長い JS 処理や高頻度の Layout / Paint が悪化の主要因。
画像サイズ未指定の後読み込み、広告や iframe の挿入、Web フォント切り替わりなどが原因。サイズを事前予約する / 新規コンテンツは上から割り込ませない、が王道対策。