プリロードスキャナの内部アーキテクチャ：なぜあなたのWebサイトは「見えないボトルネック」で失速するのか
こんにちは。ブラウザの内部構造やレンダリングエンジンの挙動を追いかけるのが生きがいのようなエンジニアなら、一度は「なぜHTMLのパースはこれほどまでに複雑怪奇なのか」と頭を抱えたことがあるはずです。
DOMツリーが構築され、CSSOMと合流してレンダーツリーになり、レイアウト、ペイント、そしてコンポジットへ――。この教科書的なパイプラインを暗記している人は多いでしょう。しかし、その華やかなメインストリームの裏側で、誰にも褒められず、しかし命がけでブラウザの速度を支えている「隠れた主役」の存在を知っていますか？
それが今回深掘りする「プリロードスキャナ（Preload Scanner）」です。
WebKit/Blinkのソースコードを覗いたことがある人なら、`HTMLPreloadScanner` や `HTMLToken` といったクラス名に心躍らせた経験があるかもしれません。今回は、このプリロードスキャナがメモリとネットワークの荒野をどう駆け抜けているのか、そのアーキテクチャの核心に迫ります。
—
1. メインパーサーの孤独と「ブロッキング」のジレンマ
現代のWebアプリケーションは肥大化しています。数メガバイトのJavaScript、サードパーティのタグマネージャー、外部フォント、CSSフレームワーク。これらすべての依存関係を解決しながらHTMLを上から順に解釈していくのは、メインのHTMLパーサー（HTML Parser）にとって過酷な労働です。
ここで思い出してください。HTMLパーサーは「同期的なストリーム処理」の塊です。
メインパーサーが `
`document.write` や、クライアントサイドのJavaScript（React/Vueのハイドレーション前など）でリソースタグを動的にHTMLに挿入する場合、サーバーから送られてくる初期のHTML生テキストにはそのタグが存在しません。
したがって、プリロードスキャナは事前にそのリソースの存在を検知できず、JavaScriptの実行とパースが完了して初めてネットワークリクエストが飛ぶことになります。これが、CSRサイトにおける初期表示の遅延の根本原因の一つです。
② CSSOMの構築遅延とJSの実行ブロック
CSSの読み込み自体はプリロードスキャナによって先行されますが、CSSファイルのダウンロード完了とその適用（CSSOM構築）は、その後に続くJavaScriptの実行タイミングに大きな影響を与えます。
もし、非同期ではない通常の `
コメント