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

フロントエンド開発の現場で、こんな壁にぶつかったことはないか？

「Lighthouseのパフォーマンススコアを上げろって言われたから、とりあえず適当に `preconnect` や `prefetch` をヘッダーにベタベタ貼り付けた。でも、逆にサイトが重くなった気がする……」

おいおい、その気持ちは痛いほどよく分かる。ネット上の適当な記事を鵜呑みにして「これ張っとけば速くなるらしいよ」なんて魔法の呪文のようにリソースヒントを乱用すると、ブラウザのネットワーク層でリソースの奪い合い（リソースコンテンション）が起きて、かえってメインスレッドや回線を窒息させる。マジで最悪のアンチパターンだ。

今回は、Webブラウザが裏側でどうやってHTMLをパースし、ネットワークと格闘しながらDOM/CSSOMツリーを構築しているのか、その深層メカニズムを紐解きながら、`dns-prefetch`、`preconnect`、`prefetch` の正しい使い分けをプロの視点で徹底的に叩き込んでやろう。

—

1. ブラウザの裏側で何が起きているか？ リソースヒントの生存戦略

まず、ブラウザがURLを叩いてから画面を描画するまでの過酷な旅路を思い出してほしい。
サーバーからHTMLの最初のチャンクが返ってきた瞬間、ブラウザのパーサー（HTML Parser）は猛烈な勢いで上から下へ文字を読み解き、DOMツリーの構築を始める。途中で `` や `

---

4. シニアとして最後に伝えたい注意点

いいか、リソースヒントは「使えば使うほど速くなる魔法の粉」じゃない。

特に `preconnect` や `prefetch` を全リソースに対して無責任に貼りまくると、ブラウザが本当に今必要なメインのリソース（LCP画像やクリティカルなCSSなど）と帯域やCPUリソースを奪い合い、結果的にパフォーマンス指標（LCPやINP）を悪化させるという本末転倒な事態を引き起こす。

現場で実装するときは、必ずLighthouseやChrome DevToolsの「Network」タブを開き、「本当にそのコネクションや先読みは最初から必要か？」 を自分の目で確認する習慣をつけろ。

プロなら、なんとなくではなく「根拠を持って」コードを書く。今日の話を理解したお前なら、明日からのレビューで自信を持ってチームメンバーにアドバイスできるはずだ。頼んだぞ！