画像配信最適化 2025 — Priority Hints / Preload / HTTP/2 の実戦ガイド

TL;DR: 画像は「正しいサイズ・正しいタイミング・正しい優先度」で配信する。fetchpriority, preload, 適切なフォーマット（AVIF/WebP/PNG）と srcset/sizes、遅延読み込みの境界設計、HTTP/2/3 の特性理解、キャッシュ戦略の4点セットで LCP を安定化し、検索流入と体験を同時に伸ばします。

なぜ今、画像配信が重要か

ユーザー体験と検索流入の両輪で、画像は最大の転送量・描画コストを占めます。LCP 画像の取得が 200–300ms 遅れるだけで直帰率が顕著に悪化し、広告/収益・CV も鈍ります。2025 年の実務では Priority Hints と preload に加え、HTTP/2/3 の多重化特性、srcset/sizes の厳密設計、CLS 回避の寸法指定、CDN のオリジンヒントを組み合わせて「初回表示の優先度制御」をミスなく実装するのが定石です。

基本用語を30秒でおさらい

• LCP: ファーストビュー最大要素（多くはヒーロー画像）。
• CLS: レイアウトシフト指標。画像寸法未指定で悪化。
• Priority Hints: ブラウザに相対優先度を伝える仕組み（fetchpriority）。
• Preload: 先読みを強制し取得開始を前倒し（<link rel="preload">）。
• HTTP/2/3: 多重化のため過剰な Preload は逆効果になり得る。

ルール1: LCP 画像の優先度を明示する

• LCP 対象の <img> に fetchpriority="high" を付与。
• Hero 画像に decoding="async" と loading="eager"（レイアウト確定済みの場合）。
• width/height を必ず設定して CLS を回避。

実装例（Next.js）

<img
  src="/hero.avif"
  alt="..."
  width={1200}
  height={630}
  loading="eager"
  decoding="async"
  fetchPriority="high"
/>

優先度制御の理解（ネットワーク層/レンダリング層）

• ネットワーク層: DNS/TLS/HTTP 接続の確立と多重化で「どれを先に取るか」を調整。
• レンダリング層: レイアウト情報・視覚優先度から LCP 候補を推定し、画像デコードとペイントを配慮。 → fetchpriority="high" は双方に作用し、LCP 候補の取得・デコード・描画を前倒しに寄せます。

ルール2: Preload は「本当に必要な1枚だけ」

• <link rel="preload" as="image" imagesrcset="..." imagesizes="..."> を使用。
• 乱用は逆効果（帯域の先取り）。Hero 1枚に限定するのが安全。

Preload の失敗パターン

• as="image" の欠落 → 優先度が上がらない。
• imagesizes 不一致 → 間違った解像度を先読みして帯域を浪費。

正しい Preload の書き方（レスポンシブ対応）

<link
  rel="preload"
  as="image"
  href="/hero-1200.avif"
  imagesrcset="/hero-800.avif 800w, /hero-1200.avif 1200w, /hero-1600.avif 1600w"
  imagesizes="(min-width: 1024px) 1200px, 92vw"
  fetchpriority="high"
/>

ルール3: HTTP/2/3 とキャッシュ設計

• 初回表示を軽く、再訪問を極端に速く。Cache-Control と ETag を整備。
• OGP/共通アセットは長期キャッシュ（ハッシュ付与）に。
• HTTP/2/3 では1コネクション多重化のため、Preload 乱発より fetchpriority と正確な srcset/sizes が効くケースが多い。

ルール4: 正しいサイズを正しい画面に

• srcset/sizes を適切に設定し、sizes はレイアウト実寸に合わせて書く。
• アートディレクションは picture でブレークポイント毎に切り替え。

関連: 2025年のレスポンシブ画像設計 — srcset/sizes 実践ガイド

ルール5: 遅延読み込みの境界

• ファーストビュー外の画像は loading="lazy"。
• ただし「あと 1 スクロールで見える」距離は IntersectionObserver で早めにプリフェッチ。

ケーススタディ（実務での落とし穴）

• SPA の遅延ヘッダーヒーロー: ルーティング直後に LCP 候補が確定せず、preload だけ先行し実描画が遅れる → SSRでヒーローを直置き、fetchpriority="high" で安定。
• 画像CDNの自動変換: Accept ヘッダーによりフォーマット切替。srcset 内の派生が過多で始動が重い → 800/1200/1600 の3段を上限に絞る。
• 未指定の sizes: 端末幅そのまま推定で過大画像を取得 → レイアウトに合わせて sizes を明示。

計測と検証（手順）

• Lab: Lighthouse / WebPageTest で LCP・CLS・TBT を確認。
• Field: CrUX / GA4 で実トラフィックの LCP p75 を監視。
• DevTools: Performance パネルで LCP 候補・ネットワーク優先度（Priority 列）・画像解像度の過不足を点検。
• Network パネルで preload ヒット有無・cache-control ヘッダー・content-type を確認。

チェックリスト（恒久運用）

• [ ] LCP 画像に fetchpriority="high"
• [ ] Preload は 1 枚に限定
• [ ] width/height で CLS 回避
• [ ] srcset/sizes はレイアウトに忠実
• [ ] キャッシュ戦略（初回軽量・再訪最速）
• [ ] 画像CDN の自動派生は 3 段以内に制御
• [ ] DevTools で Priority/解像度/キャッシュを定期監査
• [ ] レポート: LCP p75, CLS p75 を月次トレンド化

FAQ

• Q: Preload と Priority Hints はどちらが優先？

• A: 役割が異なります。Preload は「先に取りに行く」宣言、Priority Hints は「相対的な優先度」をブラウザに伝えます。Hero 1 枚は併用が有効です。

• Q: loading="eager" は必須？

• A: LCP 画像でレイアウトが確定済みなら推奨です。未確定なら CLS リスクが上がるため避けましょう。

• Q: HTTP/3 にしたら速くなりますか？

• A: ロスの多いネットワークでは有利ですが、設計が悪ければ効果は出ません。まずは優先度・解像度・キャッシュの基本を固めてください。

• Q: sizes の設計が難しいです。

• A: 実レイアウトの CSS 幅をそのまま書くのが鉄則です。曖昧な % や vw での過大取得に注意しましょう。