LCPの多くは「画像」で決まる

Core Web Vitalsは、LCP（最大コンテンツの描画速度）・CLS（レイアウトの安定性）・INP（操作への応答性）の3指標でユーザー体験を測る考え方です。このうちLCPの対象要素は、多くのサイトでファーストビューの画像です。つまり画像まわりの最適化は、スコア改善の中でも特に費用対効果の高い一手になります。当スタジオでもパフォーマンス改善のご依頼では、まず画像から着手することがほとんどです。

フォーマットをWebP / AVIFへ

JPEGやPNGのまま配信している場合、WebPへ変換するだけでファイルサイズを大きく削減できるケースが大半です。さらに圧縮効率の高いAVIFも主要ブラウザで利用できるようになっており、picture要素でAVIF→WebP→JPEGの順にフォールバックさせる構成が定番になっています。

  • 写真はWebP（品質75〜85前後）を基準にし、劣化が気になるものだけ品質を上げる
  • ロゴ・アイコン・図版は、拡大に強く軽いSVGを第一候補にする
  • 変換は手作業にせず、ビルド時やアップロード時に自動化する

注意したいのは「とにかく軽く」ではなく、表示品質とのバランスを見ながら圧縮率を決めることです。商品写真や実績画像は、サイトの信頼感に直結します。

width / height指定でCLSを防ぐ

imgタグにwidth / height属性を書いておくと、ブラウザは画像の読み込み前から縦横比を計算して表示領域を確保できます。これにより、画像の到着でレイアウトがガタッとずれるCLSを防げます。CSSのaspect-ratioで枠を確保する方法も有効です。レスポンシブで表示サイズが変わる場合も、縦横比さえ伝わっていればレイアウトは安定します。地味な施策ですが、全imgに徹底するだけでCLSはかなり改善します。

lazyとfetchpriorityで優先度を設計する

すべての画像を同じ優先度で読み込む必要はありません。画面に映る順序に合わせて、読み込みの優先度を設計します。

  • ファーストビュー外の画像 → loading="lazy" で遅延読み込みにする
  • LCP候補となる主役画像 → fetchpriority="high" を指定し、lazyは付けない
  • decoding="async" でデコード処理を描画から切り離す

ありがちな失敗が、LCP画像にまでlazyを付けてしまい、かえって表示を遅らせるケースです。「遅らせる画像」と「最優先で読み込む画像」をはっきり分けることが、この手順の要点です。

計測して初めて「最適化」になる

施策の後は必ず計測します。Lighthouseなどの合成テストで施策前後の変化を確認しつつ、Search Consoleのレポートで実際の訪問者の数値（フィールドデータ）を追いかけるのが基本です。手元のテストの点数だけを見て満足せず、実ユーザーの体感が改善しているかまで確かめて、はじめて「最適化した」と言える状態になります。改善は一度きりではなく、画像が追加されるたびに崩れない仕組みづくりまで含めて設計するのがおすすめです。