「ブラウザは、HTMLを上から順に読んで、上から順に描画する」。
もし君がまだそう信じているなら、今日でその認識をアップデートしよう。
ブラウザのレンダリングエンジンは、もっと貪欲で、もっとせっかちだ。我々が書いたHTMLを先読みし、ネットワークの帯域を奪い合い、実行の優先順位を常に計算している。この「ブラウザの裏側の深淵」をコントロールする術を知っているかどうか。それが、凡庸なフロントエンドエンジニアと、パフォーマンスを支配するアーキテクトの境界線だ。
今日は、リソースヒント（`preload`, `prefetch`, `preconnect`）という強力な武器について、現場の泥臭い話を交えて解説する。
—
なぜブラウザに「ヒント」を与える必要があるのか？
ブラウザの「プリロードスキャナ」は非常に優秀だ。HTMLをパースしながら、DOM構築を待たずにJSやCSSを先読みしてくれる。だが、人間が書いたコードの複雑さには勝てないこともある。
例えば、CSSの中で読み込まれるフォントファイルや、JSの非同期読み込みによって動的に生成される画像。これらはブラウザが「あ、これも必要だ！」と気づくのが遅れがちだ。結果として、レンダリングのクリティカルパスに遅延が生じる。
ここに我々が「ヒント」を差し込むことで、ブラウザの先読みをブーストさせ、体験を劇的に変えることができる。
—
1. ``：最優先の緊急配送
`preload`は、「今すぐ必要だ、何よりも優先しろ！」という強いメッセージだ。
主に、ファーストビューで必須となる重いアセット（メインのフォント、ヒーローイメージ、クリティカルなJS）に使う。注意すべきは「使いすぎない」こと。すべてを最優先にすると、結局何も優先されないのと同じだからだ。
シニアの視点： `as` 属性を忘れるな。ブラウザは `as` がないとリソースの優先度を判定できない。特にフォントは `crossorigin` 属性を付けないとダブルフェッチ（二重取得）を引き起こす地雷だ。気をつけてくれ。
—
2. ``：挨拶だけでも済ませておけ
Webサイトは今や、自社サーバーだけでなく、APIサーバー、CDN、Analyticsなど、多くの外部ドメインと通信する。
DNSの解決、TCPハンドシェイク、TLSネゴシエーション……。これらは「通信の準備」だけで往復数ミリ秒～数百ミリ秒を食う。
`preconnect` は、「いずれ通信するから、今のうちに握手（コネクション確立）だけ済ませておいてくれ」という指示だ。
シニアの視点： 乱用は厳禁だ。コネクションを張るということは、メモリとCPUを消費する。本当に通信が発生する「メインのドメイン」に対して3つから5つ程度に絞るのが、現場のセオリーだ。
—
3. ``：余裕がある時に仕込んでおけ
`prefetch` は、`preload` とは対照的だ。「今は不要だが、次のページで確実に使うだろうから、暇な時に取っておいてくれ」という、非常に気の利いた機能だ。
ユーザーがリンクにカーソルを合わせた瞬間や、アイドルタイムに取得される。
シニアの視点： 「遷移先が確実に分かっている場合」に使う。例えば、ログイン後のダッシュボードから遷移する重いレポートページなどだ。ここぞという場面で使うと、ユーザーは「ページ遷移が爆速になった」と錯覚するほどの体験を提供できる。
—
実践的な使い分けフローチャート
現場で迷ったら、こう考えろ。
1. 今すぐ必要なもの（LCPに関連する等） → `preload`
2. 次に遷移するページで必要になるもの → `prefetch`
3. 外部ドメインへのAPI通信 → `preconnect`
注意：魔法の杖ではない
リソースヒントは、ネットワーク帯域の「先食い」に過ぎない。
過剰な `preload` は、本来読み込まれるべきCSSやJSのダウンロードをブロックし、むしろパフォーマンスを悪化させる。
「計測、適用、再計測」。このサイクルを回せないエンジニアに、リソースヒントを触る資格はない。`Chrome DevTools` の `Network` タブの優先度（Priority）カラムを常に監視し、君のヒントが正しく機能しているか、自分の目で確かめてほしい。
—
ブラウザは忠実な部下だ。しかし、指示が曖昧だと迷走する。
「なんとなく」ではなく、「なぜここでこれを使うのか」を説明できるレベルまで噛み砕いて実装してくれ。
それが、君の作るWebサイトを「ただ動くもの」から「極上のユーザー体験」へ昇華させる鍵になるはずだ。健闘を祈る。
コメント