Core Web Vitals と画像最適化
一言まとめ
LCP 2.5s / INP 200ms / CLS 0.1 が閾値。LCP 画像には fetchpriority="high" を付けて lazy にしない、背景画像を LCP 要素にしない、width / height を明示する。フォーマットは AVIF → WebP → JPEG のフォールバックチェーン。
目次 5 sections
調査時点: 2026-04。サポート率と統計は当時の値。
Core Web Vitals は、Google が定める Web ページの利用体験を測る主要指標群。LCP は主なコンテンツの表示速度、INP は操作への応答性、CLS は表示中のレイアウトのずれを測る。
閾値
INP が FID を置き換えたのは 2024-03。
| 指標 | Good | Poor |
|---|---|---|
| LCP | 2.5s 以下 | 4.0s 超 |
| INP | 200ms 以下 | 500ms 超 |
| CLS | 0.1 以下 | 0.25 超 |
2025 Web Almanac では、モバイルページの 77% が INP Good、高トラフィック上位 1,000 サイトでは 53%。全指標 Good のサイトは全体の 47%。
画像フォーマット
- AVIF: サポート 93.8%(2025-09)、JPEG 比で 50% 前後削減。
- WebP: 95.29%。当時もっとも安全なモダンフォーマット。
<picture>で AVIF → WebP → JPEG / PNG の順にフォールバックする。
<picture> <source srcset="hero.avif" type="image/avif"> <source srcset="hero.webp" type="image/webp"> <img src="hero.jpg" alt="..." width="800" height="1200"></picture>LCP 画像の扱い
- LCP 画像には
fetchpriority="high"を付け、loading="lazy"を付けない。lazy-load した LCP 画像の Good 率は 65%、preload した場合は 83%。 - 折り返し以降の画像は
loading="lazy"+decoding="async"。 - CSS の
background-imageを LCP 要素に使わない。発見が遅れ、読み込みが遅れ、レスポンシブなバリアントも指定できない。 width/height属性を明示して CLS を防ぐ(デスクトップの 65% がまだ省略している)。
関連
更新履歴
- 2026-04-19: 初版(ローカル調査ノート)
- 2026-10-17: Wiki へ移植、概念ページとして再構成。冒頭に定義を追加
出典
同じトピック — Web
- 単一画面の Canvas ツールのスタック選定(vanilla TS / Svelte / Preact と PWA ツーリング)
- DAM カラオケ検索(clubdam)の挙動と制約
- favicon の最小構成(SVG + ICO + apple-touch-icon + manifest)
- フロントエンドのフレームワークとツールの動き(2025)
- HTML-in-Canvas API
- HTML-in-Canvas の実現性(a11y・性能・セットアップ・シェーダー)
- iOS Safari で canvas の画像を保存させる(download 属性 / Web Share / 長押し)
- 日本語 Web フォントのライセンスとサブセット化
- 個人サイトのライブウィジェットと外部 API の制限
- モダン CSS / Web API の対応状況(2025-2026)
- OPFS(Origin Private File System)
- Google Places API のキーの守り方(ブラウザ露出 vs サーバ中継)
- iOS の PWA 制限
- 機能別 React / TS ライブラリ対応表(2026-04 時点)
- URL 長の上限と日本語の URL エンコード膨張
- 書き出すテキストファイルの UTF-8 BOM と Markdown 継続行
- 縦書き Web の実装(writing-mode・ルビ・圏点・縦中横・禁則)
- PWA の Web Share Target(Android)の実測と落とし穴
- WebAssembly(Wasm)
- YouTube oEmbed で動画タイトルとチャンネル名を取る