こんにちは。ブラウザのレンダリングパイプラインを夜な夜なプロファイラで眺め、メインスレッドのわずか数ミリ秒のブロッキングにすら愛おしさを覚える、そんな変態的なフロントエンド・ギークの皆さん。
今日は、現代のWebブラウザが隠し持つ「最強の裏方」、プリロードスキャナー（Preload Scanner）について深く掘り下げていこうと思う。
Lighthouseのスコア画面で「最大コンテンツの描画（LCP）」の改善に頭を悩ませたことがある人なら、一度は耳にしたことがあるはずだ。「CSSやJavaScript、あるいは巨大なヒーロー画像が、なぜかパースの終盤までダウンロードされない」というあの絶望的な現象の裏側で、ブラウザがどれほど必死に先読みを行っているか、その内部アーキテクチャの泥臭い真実を語らせてもらう。
—
なぜメインのHTMLパーサーだけでは戦えないのか？
まず、ブラウザのレンダリングエンジン（Blink, WebKit, Geckoなど）がHTMLをどう料理しているか、その基本構造を思い出してほしい。
メインのHTMLパーサーは、ネットワーク層から送られてくるバイトストリームを文字にデコードし、トークナイザーで切り刻み、DOMツリーを構築していく。非常に素直で、上から下へ流れる職人的な逐次処理だ。
しかし、ここで致命的なボトルネックが発生する。
HTMLをパースしている最中に、以下のような外部リソースの参照にぶつかったとする。
メインパーサーはここで立ち止まる。特にスクリプトタグ（`async`や`defer`がついていない場合）に出会うと、JavaScriptの実行エンジンに制御を渡し、スクリプトのダウンロードと実行が完了するまでDOM構築を完全にブロックする。CSSだってそうだ。CSSOMが構築されるまで、その後の描画はブロックされる。
もし、ブラウザがメインパーサーの「逐次的な歩み」だけに頼っていたらどうなるか？
パーサーがスクリプトのブロックで足止めを食らっている間、HTMLのさらに下流にあるはずの巨大な画像や外部フォント、追加のCSSの存在に、誰も気づくことができない。結果として、ネットワークのパイプラインはアイドル状態になり、ページの表示速度（LCP）は目も当てられない惨状になる。
ここで登場するのが、プリロードスキャナーという名の優秀な「偵察部隊」だ。
—
プリロードスキャナーの動作原理：メインパーサーを追い抜く「先読み」の裏技
プリロードスキャナーは、メインのHTMLパーサーとは独立して動く、非常に軽量なサブパーサーだ。
彼らの仕事はシンプルかつアグレッシブ。「HTMLドキュメントのテキストを先読みし、タグや属性（`href`, `src`, `imagesrcset`など）のパターンを高速でスキャンして、外部リソースのURLを片っ端から見つけ出し、ネットワーク層にリクエストを投げること」。
メインパーサーがJavaScriptの実行や重いDOMツリーの構築で苦悶している最中も、プリロードスキャナーは数千行先のHTMLを先回りしてシュパッと読み進め、必要なアセットを先回りしてダウンロードプールに放り込んでいる。
メモリ効率と並行性の絶妙なバランス
ここで面白いのが、プリロードスキャナーは「完全なDOMツリーをメモリ上に構築しない」という点だ。
DOMノードを作らないためメモリ消費量はごくわずか。純粋に正規表現や高速なステートマシンに近いアルゴリズムで文字列を舐め回し、リソースのヒント（URL）だけを抽出して破棄していく。この割り切りがあるからこそ、メインスレッドの足を引っ張らずに、ネットワーク帯域を限界まで有効活用できるのだ。
—
現代のWeb開発者が陥る「プリロードスキャナーの罠」
しかし、このプリロードスキャナーも万能ではない。エンジニアが無知なコードを書くと、この優秀な偵察部隊の目を欺き、パフォーマンスを自ら破壊してしまうことがある。いくつか代表的な「やらかし」を見ていこう。
1. JavaScriptによる動的なリソース生成（クライアントサイド・レンダリングの弊害）
SPA（Single Page Application）の初期実装にありがちだが、HTMLがほぼ空っぽで、すべてのDOM構造や画像タグをJavaScriptが動的に生成している場合、プリロードスキャナーは完全に見事に機能しなくなる。
この状態では、プリロードスキャナーがスキャンしても、肝心の画像やCSSのURLが見つからない。結局、`bundle.js`がダウンロードされ、パースされ、実行され、DOMが構築されて初めてリソースの存在がネットワークに伝わる。これではリソースの発見が何百ミリ秒も遅れ、LCPが致命的に悪化する。
2. インラインスクリプトによるパースのサスペンド
プリロードスキャナーは先読みの天才だが、HTML内にインラインのJavaScript（``）が現れたとき、慎重にならざるを得ない。なぜなら、そのインラインスクリプトが `document.write()` などを使い、HTMLの構造をその場で書き換える可能性があるからだ。
そのため、ブラウザによってはインラインスクリプトに遭遇すると、安全のためにプリロードスキャナーの先読みを一時停止（あるいは制限）せざるを得ないケースがある。
—
高度な最適化：プリロードスキャナーを手玉に取る技術
このプリロードスキャナーの挙動を深く理解していれば、ブラウザの機嫌をとり、レンダリング速度を極限まで引き上げるコードを書くことができる。
実務で使える具体的なテクニックを見ていこう。
テクニック1: `` による明示的な先回り指示
プリロードスキャナーは優秀だが、CSSから読み込まれる背景画像や、JavaScriptのモジュールからインポートされる動的依存関係（Dynamic Import）の奥深くまでは、最初のHTMLスキャンだけでは気づけないことがある。
そこで、開発者が手動で「このリソースは絶対にすぐ必要だ」とプリロードスキャナーに教えてやるのだ。
このコードをブラウザが受け取った瞬間、メインパーサーが `
` の中で迷っていようとも、プリロードスキャナーは即座にフォントとヒーロー画像のダウンロードをネットワーク層に要求する。結果として、フォントの点滅（FOIT/FOUT）やLCPの遅延を劇的に防ぐことができる。テクニック2: レスポンシブ画像における `imagesrcset` と `imagesizes` の活用
レスポンシブデザインでよく使われる `
しかし、もし `srcset` の解釈に迷うような複雑な構造にしたり、JavaScriptで遅延読み込み（Lazy Loading）を不適切に実装したりすると、プリロードスキャナーが誤動作を起こす。
以下のサンプルを見てほしい。LCP候補の画像には、絶対に `loading=”lazy”` をつけてはならない。
`loading=”lazy”` を指定してしまうと、ブラウザはその画像のロードをビューポートに入る直前まで意図的に遅らせようとする。プリロードスキャナーがいくら優秀でも、「lazyだから後回しにしよう」と判断してしまい、結果としてLCPの計測値が跳ね上がることになる。ファーストビューに入る重要なアセットには、常に `fetchpriority=”high”` を添え、lazy loadingは絶対に避けること。これがプロの選択だ。
—
結びにかえて
Webブラウザという巨大なブラックボックスは、私たちが書いたコードをただ受動的に解釈しているわけではない。その内部では、今回紹介したプリロードスキャナーのように、数々の泥臭い最適化アルゴリズムがミリ秒単位の戦いを繰り広げている。
「なぜこのリソースの読み込みが遅いのか？」
「なぜLCPが改善しないのか？」
そう悩んだときは、Chrome DevToolsの「Network」タブや「Performance」タブを開き、タイムライン上でリクエストが発火しているタイミングを凝視してほしい。そこには、プリロードスキャナーがあなたのために必死に先回りして開いた、ネットワークの足跡が鮮明に残っているはずだ。
ブラウザの仕組みを愛し、そのエンジンの息吹を感じながらコードを書く。それこそが、真に堅牢で爆速なWebアプリケーションを生み出す唯一の道なのだから。
コメント