LCP画像をWebPで最適化する手順｜Core Web Vitals 改善の実務

Links Create 編集部 ・ 公開: 2026-05-21 ・ 更新: 2026-05-21

Google Search Console の Core Web Vitals レポートで「LCP が悪い」と表示された場合、その大半は画像が原因です。本記事では LCP (Largest Contentful Paint) の仕組み、画像サイズ・形式の最適化、WebP / AVIF 変換の判断基準、fetchpriority と lazy loading の使い分け、改善後に見るべき指標を実用ベースで整理します。画像圧縮の科学 (Pillar) もあわせて参照してください。

1. LCP で画像が問題になる理由

LCP (Largest Contentful Paint) は web.dev の LCP 解説 によれば「ビューポートに表示される最大の要素のレンダリングタイミング」を測る Core Web Vitals 指標です。多くのページでは ファーストビューにある大きな画像 (ヒーロー画像・記事サムネイル) が LCP 候補となります。

LCP の評価しきい値

web.dev によれば LCP のしきい値は次のとおりです (フィールドデータの 75 パーセンタイル基準)。

なぜ画像が LCP のボトルネックになるか

2. まず確認する画像サイズと形式

web.dev 画像パフォーマンスガイド によれば、LCP 改善で最も即効性があるのは画像容量の削減です。

ステップ 1: 現状把握

ステップ 2: リサイズ

表示サイズに対して過大な原寸画像はまずリサイズします。画像リサイズツール で配信先に合わせて 1200-1600px 幅にリサイズ (Retina ディスプレイ考慮で表示幅の 2 倍程度)。

ステップ 3: 形式変換

JPG/PNG のままなら WebP に変換して容量を下げます。画像変換ツール で WebP 出力可。詳細は WebP 画像を圧縮して軽くする方法、AVIF も検討するなら AVIF と WebP はどちらが安全？ を参照。

ステップ 4: 圧縮

変換後の WebP を 画像圧縮ツール で品質 70-80% に圧縮。JPG 品質設定の考え方は JPG 圧縮で画質劣化を抑える方法 を参考にしてください。

3. WebP・AVIF 変換の判断基準

状況推奨形式備考
LCP 候補が写真 (ヒーロー画像等)AVIF (フォールバック WebP/JPG)picture 要素で並列、最高圧縮
透過要素を含むWebP (フォールバック PNG)WebP は可逆モードで透過保持
ロゴ・アイコンSVG (ラスター不要なら)ベクターで容量最小、解像度非依存
古いブラウザサポート必須JPG / PNG互換性最優先、容量は二次
制作工数を最小化したいWebP のみ運用シンプル、フォールバック省略 (古環境は劣化容認)

picture 要素での 3 段並列例

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="ヒーロー画像"
       width="1200" height="630"
       fetchpriority="high">
</picture>

ブラウザは上から順に source を評価し、対応する最初の形式を採用します。<img> の fetchpriority="high" で優先取得 (次節で解説)。

4. loading と fetchpriority の注意点

loading 属性の使い分け

主要モダンブラウザは loading="lazy" を広く対応していますが、MDN の Lazy loading ガイド も参照してください。ファーストビュー (特に LCP 候補) に lazy を付けると LCP が悪化するため要注意です。

fetchpriority 属性で優先度を明示

web.dev: Fetch Priority によれば、HTML の fetchpriority 属性 (high / low / auto) でブラウザにリソース取得の優先度を伝えられます。LCP 候補画像には fetchpriority="high" を付けることで、CSS/JS よりも先に取得が始まる挙動が期待できます。

<img src="hero.webp" alt="..."
     width="1200" height="630"
     fetchpriority="high"
     loading="eager">

preload 関連の補足

レスポンシブ画像で複数解像度を提供する場合、web.dev: レスポンシブ画像プリロード によれば <link rel="preload" as="image" imagesrcset="..." imagesizes="..."> でブラウザに事前取得を指示できます。ただし過剰な preload はかえって帯域競合を招くため、本当に最優先の LCP 画像 1 枚に限定するのが基本です。

5. 改善後に見るべき指標

Lab data (合成測定) と Field data (実測) の使い分け

確認推奨ツール

段階的改善のチェックリスト

  1. LCP 候補画像を特定 (Lighthouse / DevTools)
  2. 表示サイズの 2 倍程度にリサイズ
  3. WebP (または AVIF) に変換
  4. 品質 70-80% で圧縮
  5. fetchpriority="high" と loading="eager" を付与
  6. picture 要素でフォールバックを並列
  7. width / height 属性で CLS も同時改善
  8. 本番デプロイ後、1-2 週間でフィールドデータが反映されるのを待って Search Console で確認

LCP 候補画像の圧縮・WebP 変換をブラウザ完結で

→ 画像を圧縮 (LCP 改善) → WebP に変換

OGP 画像の最適化と関連する話題は OGP 画像の最適サイズ (1200×630) も参照してください。

よくある質問

LCP 画像は必ず WebP にすべきですか？

必ずではありませんが、Web 表示用の写真であれば WebP / AVIF を優先候補にすると LCP 改善が見込めるケースが多いです。WebP は主要ブラウザ対応が安定、AVIF は更に高圧縮ですが対応がまだ広がりつつある段階。古いブラウザへの配信が必要なら <picture> 要素でフォールバック JPG を併設するのが堅実です。

ファーストビュー画像に lazy loading を使ってもよいですか？

使わないことを推奨します。loading="lazy" は画面外画像を遅延読み込みする属性ですが、ファーストビューに含まれる画像 (特に LCP 候補) に付けると逆に LCP を遅らせます。ファーストビュー画像は loading="eager" (デフォルト) を維持し、必要に応じて fetchpriority="high" を付与して優先取得させます。

画像を小さくすると CLS も改善しますか？

直接の関係はありません。CLS (Cumulative Layout Shift) は画像のファイルサイズではなく、画像表示前後のレイアウトずれが原因です。<img> 要素に width/height 属性 (または aspect-ratio CSS) を入れて表示領域を予約することで CLS を防げます。画像容量を下げると LCP は改善しますが CLS は別問題と考えてください。

Lighthouse のスコアだけ見れば十分ですか？

不十分です。Lighthouse は単一端末・単一ネットワーク環境での合成測定 (lab data) です。実ユーザーの体感を反映する CrUX (Chrome User Experience Report) や RUM (Real User Monitoring) も併用して、フィールドデータでの 75 パーセンタイル指標を確認するのが堅実です。Search Console の Core Web Vitals レポートも有用です。

関連記事: WebP 画像を圧縮して軽くする方法 ・ AVIF と WebP はどちらが安全？ ・ JPG 圧縮で画質劣化を抑える方法 ・ OGP 画像の最適サイズ

戻る: 画像・QRツール完全ガイド (圧縮の科学セクションへ)

一次情報源: web.dev: LCP 最適化 ・ web.dev: 画像パフォーマンス ・ web.dev: Fetch Priority ・ MDN: Lazy loading ・ web.dev: レスポンシブ画像プリロード