【実務・中級編】リソースヒントの活用（preload, prefetch, preconnect） – Webブラウザの仕組み実践ガイド

やあ。今日も今日とてコードレビューに追われてお疲れさん。
「Lighthouseのパフォーマンススコアが赤いままで、どうにかしてくれってマネージャーに詰められたんだよ……」なんて顔して席に戻ってきた後輩が、まさに君かい？

まあ落ち着きなよ。Webフロントエンドのパフォーマンスチューニングなんて、ブラウザが裏側でどう動いているか（＝「ブラウザの気持ち」）を理解しちまえば、パズルみたいにスルスルと解けるようになるもんさ。

今日は、ブラウザのレンダリングパイプラインを強引にブーストさせる奥の手、「リソースヒント（`preload`, `prefetch`, `preconnect`）」について、俺の実務の泥臭い経験も交えながら徹底的に解説してやる。教科書には載ってない、ブラウザの内部挙動の裏側まで丸裸にしてやろうじゃないか。

—

1. なぜ「普通のHTML読み込み」では遅いのか？（ブラウザの裏側の話）

まず、敵を知るためにブラウザがHTMLを受け取ってから画面を描画するまでの「苦悩のプロセス」を思い出してほしい。

ブラウザはHTMLを上から順にパースしていく。
1. `` を見つけて、DOMツリーを作り始める。
2. 途中で `` にぶつかる。ここでCSSOMを作るためにCSSのダウンロードが完了するまでDOMの構築がブロックされる。
3. さらに `

---

4. シニアから後輩へ送る「現場の教訓（アンチパターン）」

最後に、実務でやりがちな失敗をいくつか共有しておく。ここを間違うと、逆にパフォーマンスが落ちるから気をつけてくれ。

1. `preload` の乱用は禁物
「とりあえず全部preloadしておけ」は最悪の手だ。コンソールに `The resource was preloaded using link preload but not used within a few seconds...` という警告（Warning）が出たことがあるだろう？あれは「お前、嘘ついてpreloadさせたのに使わなかったじゃねぇか！ユーザーのパケット返せよ！」というブラウザからの怒りのメッセージだ。本当に必要な、LCP（Largest Contentful Paint）やファーストビューに直結するものだけに絞り込むこと。
2. HTTPヘッダー経由での制御も検討する
HTMLの `` タグだけでなく、サーバーのHTTPレスポンスヘッダー（`Link` ヘッダー）として返すこともできる。特にCDNやService Workerを挟んでいる場合、HTTPヘッダーで `preload` を指示した方が、ブラウザがHTMLのボディをパースし始めるよりも数ミリ秒早くダウンロードを開始できるという強力なメリットがある。

さあ、理屈は分かったな？
自分の担当しているプロジェクトのLighthouseの診断結果を開いて、LCPやFCP（First Contentful Paint）の足を引っ張っているリソースがどれか、今日の夕方までに洗い出してみなよ。

困ったらまた俺のところに相談に来い。応援してるぜ！