Core Web Vitalsと画像最適化(LCP/CLS/INPを崩さず高速に)
ページの体感速度は画像の設計と実装で大きく変わります。要点は3つだけ:LCPは「解像度×優先ロード」、CLSは「寸法×プレースホルダ」、INPは「遅延の線引き」です。本文は横1200–1600px、一覧は600–800pxに統一し、 写真はWebP 80–85%を起点、ヒーローだけ優先ロード、広告は固定高で受ける——これが最短の勝ち筋です。
要点(TL;DR)
- LCP:ヒーローだけ優先ロード+適正解像度(例:1600px 横)。
- CLS:すべての
<img>
にwidth/height。広告は固定高。 - INP:スクロール直後に重いデコードを作らない。fold上直下は遅延しない。
- 品質は±5%の狭いレンジで詰め、200KB前後を目安に。
CWV×画像:どこに効く?
- LCP(最大視覚コンテンツ描画):ヒーロー画像の解像度・形式・優先ロードが支配的。
- CLS(レイアウトシフト):
<img>
未指定のwidth/height、広告の高さ未確保が主因。 - INP(操作応答性):遅延画像の一斉デコード・重いCanvas処理が悪化要因。
判断フロー(解像度→形式→品質→実装)
- 解像度を統一:本文1200–1600px/一覧600–800px → /resize
- 形式を選ぶ:写真WebP/互換JPEG/ロゴ・図PNG → /convert
- 品質を±5%で微調整(目安200KB) → /compressor
- 実装:ヒーローは優先ロード、一覧は遅延、
<img>
にwidth/height、広告に固定高。
実装パターン(Next.jsの最短設計)
- ヒーロー:優先(
priority
or 先読み)。fold上直下は遅延しない。 - 一覧:loading="lazy"。スクロール直後の負荷を観測し必要なら閾値調整。
- 全
<img>
にwidth/height(またはaspect-ratio)。CSSでmax-width:100%
。 - 広告:AdSlotをページ側に置き、min-hで高さ確保(CLS回避)。
- OGP:1200×630・高コントラスト・広い安全域(→ テンプレ)。
配信・キャッシュ(安定運用の土台)
- CDNで長めのキャッシュ+ファイル名ハッシュ(差替えは新名)。
- OGP画像は絶対URL・正しいContent-Typeで配信。
- XMLサイトマップに画像URL、robotsで
sitemap.xml
を明記。
ケース別レシピ
A. ヒーローが重い
横1600px / WebP 80–85% / 優先ロード。背景の合成はCSS側、画像は単体化。
B. 一覧でCLSが出る
<img>
にwidth/height、AdSlotに固定高。カード高さを一定に。
C. OGPで文字が潰れる
1200×630・広い安全域・7語以内・高コントラストで再出力 → テンプレ量産
よくある落とし穴(回避策)
- 巨大画像のまま品質だけ上げる → 根本は解像度から。
- 寸法なし
<img>
→ width/height必須。 - 広告の高さ未確保 → プレースホルダで先に高さ確保。
公開前チェックリスト(10項目)
- 本文1200–1600px/一覧600–800pxに統一した。
- 写真=WebP、互換=JPEG、ロゴ=PNGの原則を守った。
- 品質は±5%で微調整し、目安200KBに収まった。
- ヒーローは優先ロード、fold下は遅延に設定した。
- 全
<img>
にwidth/height(or aspect-ratio)がある。 - 広告枠の高さをmin-hで確保し、CLSを回避した。
- OGPは1200×630・安全域広め・高コントラスト。
- CDNキャッシュ/ファイル名ハッシュで差替えが即時反映される。
- 画像サイトマップ/robots の整合を確認した。
- 本番のCWV(field data)で悪化がない(GSC/CrUXで監視)。