レンダリングブロックの深層：なぜあいつらは画面描画を止めるのか

こんにちは。日々、ブラウザのメインスレッドと冷徹に向き合っているフロントエンド・アーキテクチャの住人です。

Webアプリケーションのパフォーマンスチューニングを語る時、誰もが口を揃えて「JavaScriptのバンドルサイズを削れ」「CSSを分割しろ」と言います。しかし、なぜそれらのリソースがこれほどまでに画面の描画を遅らせ、ユーザーをイライラさせるのか、そのブラウザ内部のバイナリレベル、あるいはメモリ管理の挙動まで正確に理解しているエンジニアはどれほどいるでしょうか。

今回は、BlinkやWebKitといった現代のレンダリングエンジンが、HTMLのパース中にCSSやJavaScript（JS）に遭遇したとき、内部で何をやらかしているのか。そして、その強欲なブロッキング挙動をどう手なずけ、極限までパフォーマンスを絞り出すのかについて、少しディープな話をしようと思います。

—

1. なぜCSSはレンダリングをブロックするのか？（DOMとCSSOMのデッドロック）

まず大前提として、ブラウザはHTMLを上から順にただ素朴に読んでいるわけではありません。ネットワーク層からチャンク単位で流れてくるバイト列を、レキサー（Lexer）とパーサーが受け取り、トークン化してDOM（Document Object Model）ツリーを構築していきます。

ここにCSSが現れた瞬間、残酷な事実が突きつけられます。それが 「CSSOM（CSS Object Model）ツリーの構築完了待ち」 です。

描画のパイプラインにおける致命的な依存関係

ブラウザは、DOMツリーだけでもCSSOMツリーだけでも、画面をピクセル単位で描画することはできません。この2つが結婚して初めて、スタイルが適用されたレイアウトツリー（Blinkでは `LayoutObject` のツリー）が生成され、ペイントのフェーズに進むことができます。

もし、HTMLの途中に `` が現れたとします。この時、ブラウザの挙動はこうです：

1. HTMLパーサーの即座の停止（またはストールの発生）: CSSのダウンロードとパースが終わるまで、後続のDOM構築は継続されますが、「レンダリング（First Paint）」は完全にブロックされます。
2. スクリプトの実行ブロック: ここが罠なのですが、CSSの読み込みが終わるまでは、そのCSSよりも後にある（あるいは前にある一部の）JavaScriptの実行もブロックされます。なぜなら、JSは `element.getBoundingClientRect()` などを通じてCSSOMの状態（レイアウト情報）をいつでも参照できるべきだからです。もしCSSOMが構築途中であれば、JSは間違ったレイアウト計算結果を返すことになり、アプリがクラッシュするか致命的なUIのバグを生みます。

結果として、CSSが1つロード遅延を起こすだけで、メインスレッド上ではDOM構築のストール、JS実行の凍結、そして白画面（Blank Screen）の継続という三重苦が発生します。

—

2. JavaScript：パースを根底から破壊する「絶対的皇帝」

CSSが「描画のブロック」だとすれば、JavaScriptは 「パースそのものの完全停止」 を引き起こします。

`

このテキストのDOM化は、上のJSのダウンロードと実行が終わるまで絶対に始まらない

なぜ、ブラウザはこのような非効率な挙動をするのでしょうか？
理由はシンプルです。DOMの改変（Mutation）です。JSは実行中に `document.write()` やDOMの動的追加・削除を行い、HTMLのパーサーが構築しているツリー構造そのものを根底から書き換える可能性があります。そのため、パーサーは「安全のため」に、スクリプトの実行が完了するまで次のHTMLトークンを処理するのを待たざるを得ないのです。

メモリ効率とパーサーの再起動コスト

メモリの観点からも、このブロッキングは厄介です。パーサーが中断している間、未処理のHTMLチャンクや途中のDOMノードはメモリ上に保持され続けます。巨大なサードパーティ製スクリプトが同期的に読み込まれると、メモリ使用量が跳ね上がり、モバイル端末ではガベージコレクション（GC）の頻発を誘発します。これが、ロースペック端末での「カクつき」の正体です。

---

3. 最適化アーキテクチャ：非同期と遅延の境界線

この理不尽なブロッキングから逃れるため、私たちはHTML5以降、いくつかの強力な武器を手に入れました。それが `async` と `defer`、そしてCSSのメディアクエリによる最適化です。

それぞれの内部挙動と使い分けの境界線を整理しましょう。

`async` と `defer` の内部挙動の決定的な違い

[HTMLパーサー] ---------------------------------------------> (完了)
[asyncスクリプト] ---(並行DL)---> [即座に実行(パース中断)]
[deferスクリプト] ---(並行DL------------------------------>)[HTMLパース完了後に順序通り実行]

• `async` (非同期実行)
• 挙動: バックグラウンドでダウンロードし、ダウンロードが完了し次第、HTMLパースを一時中断して即座に実行します。
• ユースケース: 完全に独立したスクリプト（アクセス解析のタグや広告など）。他のDOMやスクリプトに依存しないもの。
• `defer` (遅延実行)
• 挙動: バックグラウンドでダウンロードし、HTMLのパースが完全に完了し、`DOMContentLoaded` イベントが発生する直前に、HTMLに記述された順序を厳密に守って実行します。
• ユースケース: アプリケーションのメインロジック、UIフレームワークのエントリポイントなど、DOM要素の存在が絶対条件となるスクリプト。

上級エンジニアとして、メインのアプリケーションコードには基本的にすべて `defer` を付与し、順序が結果に影響しない孤立したカウンターやアナリティクスのみに `async` を許可する、というのが鉄則です。

---

4. 実戦的コード例：クリティカルパスの極限チューニング

それでは、理論を現場のコードに落とし込みましょう。
以下は、CSSのレンダリングブロックを回避し、JSの非同期実行によってFCP（First Contentful Paint）を極限まで削ぎ落としたHTMLヘッダーの模範解答です。

この設計が優れている理由（アーキテクチャ的視点）

1. ゼロ・ブロッキング・ファーストペイント: インラインのクリティカルCSSにより、ブラウザはネットワークを待たずに即座にLayoutとPaintを実行できます。ユーザーは「白画面」を見る時間がほぼゼロになります。
2. CSSの非同期トグル（`media="print"` のハック）: 現代のブラウザのプリロードスキャナは優秀ですが、外部CSSはどうしてもレンダリングブロックを引き起こします。この `onload` ハックを使うことで、メインスレッドの処理を阻害せずにバックグラウンドでスタイルシートを安全にフェッチできます。
3. メインスレッドの競合回避: `defer` を使ったバンドルJSの読み込みにより、DOMツリーが完全に組み上がった状態で安全にフレームワーク（ReactやVueなど）をハイドレーションさせることができます。

---

5. 重大なバグの回避策：非同期化が引き起こす「レースコンディション」

最後に、非同期化や遅延実行を進めるエンジニアが必ず踏み抜く「地雷」について言及しておきます。

スクリプトの実行順序の逆転によるエラー

`async` を適当なスクリプトに貼り付けまくると、「依存関係の逆転（Race Condition）」という深刻なバグが発生します。例えば、ライブラリA（例: LodashやjQuery、あるいは独自ユーティリティ）に依存しているスクリプトBに `async` を付与した場合、ネットワークの状況によってはスクリプトBが先にダウンロード・実行されてしまい、`Uncaught ReferenceError: _ is not defined` のようなクラッシュを引き起こします。

回避策:

• DOMや他のスクリプトに依存するコードには絶対に `async` を使わず、`defer` または通常のモジュールインポート（`