こんにちは。フロントエンドの現場で日々、LCP（Largest Contentful Paint）の数ミリ秒に命を削っているエンジニアの皆さん。

ブラウザが画面をピクセル単位で描き出すまでの裏側の舞台裏――特にHTMLのパーシングからDOM、CSSOM、そしてレンダリングツリーの構築に至るまでの阿鼻叫喚のドラマを、どれほど解像度高く理解できているでしょうか？

「CSSはレンダリングをブロックする」というのは、Webパフォーマンスチューニングの教科書を開けば一番最初に書いてあるお決まりの文句です。しかし、なぜブロックしなければならないのか？メモリ上でCSSOM（CSS Object Model）とDOMがどのように結びつき、JavaScriptの実行やペイント処理とどう競合するのか。そのレイヤーまで踏み込んでアーキテクチャを語れる人は、そう多くありません。

今回は、BlinkやWebKitといったモダンブラウザエンジンの内部挙動に潜り込み、CSSOM構築とレンダリングブロッキングの深淵を覗いてみましょう。

—

1. なぜCSSOM構築はレンダリングをブロックするのか？

まず大前提として、ブラウザはHTMLを上から下へストリーミングで読み込みながら、逐次的にDOMノードを生成していきます。ネットワークからバイトストリームが流れてくると、それを文字コードにデコードし、トークナイザーがタグを認識し、ツリーを組み上げていく。このプロセス自体は非常にインクリメンタルで効率的です。

しかし、その途中で `` に遭遇した瞬間、ブラウザのパーサーは意図的に足を止めます。

なぜパーサーを止めるのか？答えはシンプルで、「後から読み込まれたCSSによって、すでに構築済みのDOMのスタイルやレイアウトが根本から覆されるのを防ぐため」です。

もしCSSOMが完成していない状態でDOMを画面に描画（First Paint）してしまうと、何が起きるでしょうか？
最初はスタイルの当たっていない裸のHTML要素が画面の端に一瞬表示され、CSSの読み込みとパースが完了した瞬間に、レイアウトがグニャリと崩れながら再配置される――いわゆる FOUC（Flash of Unstyled Content） の地獄絵図が展開されます。ユーザー体験としても最悪ですし、ブラウザにとっても無駄なレイアウト計算（リフロー）の嵐が発生し、メインスレッドのCPUリソースが溶けていきます。

したがって、ブラウザは「CSSOMが完全に構築されるまで、DOMからのレンダリングツリー（Render Tree）の生成を許可しない」という鉄の掟を敷いています。これが、CSSがレンダリングブロッキングリソースと呼ばれる所以です。

—

2. メモリ効率とツリー構造の裏側

エンジニアとして知っておくべきは、DOMとCSSOMがそれぞれ独立したメモリ上のツリー構造を持っているという点です。

DOM: ノード（`Node` インターフェース）の階層構造。各ノードはメモリ上にオブジェクトとして存在し、イベントリスナーやプロパティを保持するため、リッチなアプリケーションでは数百MB規模のメモリを消費します。
CSSOM: CSSのセレクタやカスケード規則、継承関係を解決するためのツリー。こちらもツリー構造を持ちますが、DOMよりもさらに「カスケードの解決」という計算コストの高いフェーズを伴います。

ブラウザのレンダリングエンジンは、これら2つの独立したツリーをマージして、実際に画面に表示すべき要素だけを含む「レンダリングツリー」を生成します。

ここで重要なのが、「CSSOMの構築が完了するまで、JavaScriptの実行もブロックされる場合がある」という点です。
「えっ、CSSはHTMLのパースを止めるだけじゃないの？」と思うかもしれませんが、スクリプトの前に記述されたCSSがまだロード中・パース中の場合、JavaScriptは「要素のスタイル（例: `element.getBoundingClientRect()` など）を正確に取得できない可能性」があります。そのため、モダンブラウザは、未解決のCSSOMがある状態でJavaScriptを実行すると、そのスクリプトの実行をブロック（または遅延）します。

これが、CSSの遅延や配置ミスが、DOMの構築だけでなく、インタラクティブ性（TBT: Total Blocking TimeやINP: Interaction to Next Paint）の悪化に直結する根本的な原因です。

—

3. メディアクエリがCSSOM構築に与える影響と「真の最適化」

ここで、少しマニアックな話をしましょう。すべてのCSSが、初期レンダリングをブロックすべきなのでしょうか？

答えは「No」です。例えば、デスクトップ向けの巨大なCSSファイルや、印刷用のスタイルシート、あるいはダークモード用のスタイルシートを、スマホでアクセスしているユーザーの初期表示のためにブロックさせるのは、アーキテクチャの観点から見ても明らかな無駄です。

ここに救世主として現れるのが メディアクエリ（Media Queries） です。

ブラウザは、CSSリンクタグに `media` 属性が付いている場合、その挙動を賢く変化させます。

ブラウザの内部挙動の妙

ここで面白い（そしてハマりやすい）ブラウザの仕様があります。
`media=”(min-width: 768px)”` のような条件付きCSSリンクに遭遇したとき、ブラウザは「CSSファイルのネットワークダウンロード自体をキャンセルするわけではない」という点です。

ダウンロード: 優先度は下がりますが、ブラウザはすべての外部CSSファイルをダウンロードしようとします。
CSSOMへの適用とブロック: しかし、現在のビューポート（例えばスマホの375px）に一致しないメディアクエリを持つCSSは、CSSOMの構築において「ブロック対象」から外されます。つまり、そのCSSのパースが完了していなくても、ブラウザはレンダリングツリーの構築に進むことができます。

この挙動をハックすることで、初期表示に必要なクリティカルCSSと、そうでない非クリティカルCSSを綺麗に分離し、レンダリングブロック時間を極限まで削ぎ落とすことが可能になります。

—

4. 実務で直面する重大なアンチパターンと回避策

現場のコードレビューをしていると、次のような絶望的なコードにしばしば遭遇します。

これでは、ブラウザのメインスレッドは完全に沈黙し、ユーザーには真っ白な画面（Blank Screen）が長時間提示されます。

堅牢なアーキテクチャのための最適解

この問題をクリアし、Core Web Vitalsの指標（特にLCPとFCP）を劇的に改善するための実戦的なアプローチは以下の通りです。

1. Critical CSSのインライン化:
above-the-fold（ファーストビュー）の描画に最低限必要なCSSだけを抽出（Critical CSS）、HTMLの `` 内に `

アーキテクチャ最適化サンプル

このコンテンツはCSSOMのブロックを受けずに瞬時に描画されます。

コードの解説

`media="print" onload="this.media='all'"` というイディオムは、Webパフォーマンスの世界では定番のテクニックです。ブラウザに対して「これは印刷用だ」と偽ることで初期ブロックを回避し、ダウンロードが完了した瞬間に `media="all"` に書き換えて通常のスタイルとして適用させています。
これにより、CSSOMの構築待ちによるレンダリングの停滞を完全にハックしつつ、スタイルの適用漏れを防ぐことができます。

---

最後に：ブラウザの気持ちに寄り添うということ

フロントエンド開発において、フレームワークの機能やコンポーネントの綺麗さにこだわるのも大切ですが、その下層でうごめくWebブラウザの身動き一つひとつに思いを馳せられるかどうかが、ジュニアから真のシニア・チーフアーキテクトへ駆け上がるための分水嶺です。

「ブラウザが今、どのツリーを構築していて、どこでスレッドがブロックされているのか」を脳内にパッと描けるようになれば、パフォーマンス上のボトルネックなど恐るに足らずです。

さあ、明日のコードレビューでは、無秩序に並んだ `` タグにメスを入れてやりましょう。ブラウザエンジンが喜ぶ、美しいパイプラインを構築するために。

【テクニカル・上級編】 CSSOMツリー構築とレンダリングブロッキング – Webブラウザの仕組み実践ガイド