定義
同じ瞬間に取得すべきリソースが複数あるとき、「何を先に取得するか」をブラウザが決めるルール、そしてその順序を開発者が調整する方法である。ブラウザはリソースの種類(画像・スクリプト・CSS など)と文書内の位置に応じて、ダウンロード優先度(priority、ネットワークリクエストを処理する順番)を自動的に割り当てる。fetchpriority 属性でこの順番をヒントとして上書きできる。
なぜ必要か
ブラウザは同時に開ける接続数に制限があるため、リソースが多いと順番待ちの列を作って順に取得する。このとき、本来ユーザーが最初に見るべきヒーロー画像が、下部の広告画像や補助的なスクリプトに押しやられて遅れて届くと、LCP(最大のコンテンツが描画されるまでの時間)が悪化する。ブラウザの自動優先度は「位置・種類」しか見ないので、本当に重要なリソースが何かは開発者がヒントで伝える必要がある。
動作原理
- ブラウザは HTML をパースしながら、preload scanner(本格的なレンダリング前に文書を走査して取得しておくべきリソースを先に見つける仕組み)でリソースを発見する。
- 各リソースに種類・位置ベースのデフォルト優先度(高/低など)を割り当てる — 例:ビューポート内の画像は概して低く始まる。
fetchpriority="high"が付いていれば、そのヒントを反映して順番を引き上げる。fetchpriority="low"は逆に下げる。<link rel="preload">は、まだパーサーが到達していないリソースでも先に取得するようリクエストを前倒しする。
実務適用
- LCP 候補である最初の画面の画像には
fetchpriority="high"を検討する。Next.jsImageのpriorityが内部的にこのヒントを付けてくれる。 - 折りたたまれた領域の画像や後で必要になるスクリプトは、優先度を低くするか遅延ロードする。
トレードオフ
優先度を上げたリソースは他のリクエストを押しのける。複数のリソースに high を乱用すると「全部高い = 全部普通」となり、ヒントが無意味になる。本当のボトルネック一つだけに適用するのが基本である。
使ってはいけない場合
- リソースが少なくそもそも競合がないページ — ブラウザのデフォルト優先度で十分。
- LCP 要素が何かを計測で確定していない状態 — 見当違いのリソースを上げると、かえって悪化する。
よくある間違い
- すべての画像に
priority/fetchpriority="high"を付けて優先度信号を希釈してしまう。 - preload だけを掛けて、実際にそのリソースがレンダリング経路のボトルネックか確認せず、帯域だけを浪費する。
関連概念
- largest-contentful-paint — 優先度調整で改善しようとする対象指標