ブラウザはHTMLをどのように解析し、ページを構築しますか（クリティカルレンダリングパス）？

Question

Accepted Answer

**クリティカルレンダリングパス**とは、ブラウザがHTMLとCSSとJSをピクセルに変えるまでの一連のステップです。これを理解することで、何がレンダリングをブロックするのか、どうしてページを速く描画できるのかが分かります。 ## ステップ ```text 1. Parse HTML → DOM tree (the document structure) 2. Parse CSS → CSSOM tree (the style rules) 3. DOM + CSSOM → Render tree (visible nodes + their styles) 4. Layout (reflow) → compute each node's geometry (position/size) 5. Paint → fill in pixels (colors, text, images) 6. Composite → combine layers onto the screen ``` ## レンダリングをブロックするもの **CSSはレンダリングブロッキングです。** ブラウザはCSSOMの準備ができるまで描画しません（スタイルが当たっていないコンテンツのフラッシュを避けるため）。つまり、大きい／遅いCSSは初回描画を遅延させます。クリティカルCSSを小さく保ち、可能なら逆向きに組み込んでください。 **同期スクリプトはパーサーをブロックします。** 通常の` ``` さらに悪いことに、CSSOMが必要な同期スクリプト（例えば計算されたスタイルを読むもの）はCSSも待機します。つまり、CSSファイルが間接的にスクリプトをブロックし、スクリプトがパーサーをブロックする可能性があります。 ## 最適化方法 - CSS を `` に置く（早期ロード）。クリティカルCSSを逆向きに組み込む。 - スクリプトに`defer`（または`type="module"`）を追加するか、``の直前に配置する。 - CSS/JSを最小化・圧縮し、未使用のルールを削除する。 - クリティカルフォント/アセットには`preload`を、キーオリジンには`preconnect`を使う。 - レイアウトスラッシング（JSのレイアウト反復読み書き）を避ける。それは余分なリフローを強制します。 ## なぜ重要なのかクリティカルレンダリングパスは、First Contentful PaintやLargest Contentful Paintなどのメトリクスを決定します。 CSSがレンダリングをブロックし、同期JSがパーサーをブロックすることを知っていれば、なぜ`defer`/`async`、インライン化されたクリティカルCSS、リソースヒントがページを高速化するのか、すなわちこのパスを短くしたりブロック解除したりするのかが、正確に分かります。