プリロードスキャナー：Webブラウザの「先読み」という名の職人芸
Webブラウザという巨大な機械仕掛けの時計を覗き込むとき、多くのエンジニアは「レンダリング」という華やかなプロセスに目を奪われがちだ。しかし、真のパフォーマンス・チューナーが注目するのは、メインのDOMツリー構築という「表舞台」ではなく、その裏で静かに、かつアグレッシブに動く「プリロードスキャナー（Preload Scanner）」の挙動である。
我々が書くコードは、往々にしてブラウザにとって「予測不可能なノイズ」だ。だが、ブラウザは常に賢い。メインのHTMLパーサーが `` に出くわすと、ブラウザは「DOMの構造がこのスクリプトによって改変されるかもしれない」と考え、解析を完全に停止する。いわゆる「パーサーブロック」だ。
もしプリロードスキャナーが存在しなければ、ブラウザはこのスクリプトのダウンロードが終わるまで、次に続く `` や `CSS` ファイルの存在すら知ることができない。ネットワークはアイドル状態になり、ユーザーは白い画面を眺めることになる。
プリロードスキャナーは、メインのDOM構築とは独立したスレッド（あるいは低優先度のパス）で走り、HTMLのバイトストリームを眺めて「将来必要になるリソース」をリストアップする、いわば「先遣隊」だ。
プリロードスキャナーを最大限に活かすアーキテクチャ
プリロードスキャナーを味方につけるには、ブラウザの「解析アルゴリズム」を理解する必要がある。彼らが探しているのは、HTMLタグの属性値だ。
1. 宣言的リソースの重要性
プリロードスキャナーは、JavaScriptが動的に生成するリソース（`document.createElement('script')` など）を追いかけることはできない。DOMツリーが構築された後のJS実行で初めて現れるリソースは、プリロードスキャナーの視野の外にある。
- 鉄則: 重要なリソース（主要CSS、ファーストビュー画像、重要なJS）は、可能な限りHTML内に宣言的に記述すること。
2. `` の誤用を避ける
最近、なんでもかんでも `` を貼るエンジニアがいるが、これはメモリ効率の観点から危険だ。
プリロードスキャナーは賢いが、人間が「何が本当に重要か」を正しく指示しなければ、リソースの優先順位付けでエンジンと競合してしまう。
---
パフォーマンスを極限まで引き出すテクニック
プリロードスキャナーに「次に何が重要か」を教え込むための、現場で使える最適化コードを紹介しよう。
現場で遭遇する「落とし穴」
筆者がこれまで見てきた現場で、最も多いミスは「動的な注入によるプリロードの回避」だ。
例えば、ReactやVueなどのSPA環境で、コンポーネントがマウントされるまでCSSやJSを読み込まない設計にしている場合、プリロードスキャナーは「そのリソースが必要であること」を事前には知ることができない。結果、ネットワークのウォーターフォール（滝状の読み込み）が発生し、LCP（Largest Contentful Paint）が劇的に悪化する。
解決策:
- Critical CSSのインライン化: 最小限のCSSを`