0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

@ta-ke-no-bu

Core Web Vitals再履修

0
Posted at

前置き

この記事では、計測・改善、そして CWV 全体を正しく見るための最新（2025年11月現在）の流れを調べたもののまとめ。

関連記事

🧱 ブラウザの基礎（Rendering Pipeline）

⚙️ JavaScript と非同期処理

🚀 パフォーマンスと UX

Core Web Vitals とは

コアウェブバイタルズ（Core Web Vitals）とは、Google が提唱する 「Webページの実際のユーザー体験を定量的に評価するための指標」 のことです。

Googleはこれを 検索順位（SEO）の評価要素 にも取り入れています。

「全ユーザーの中央値」ではなく「75パーセンタイルの実測値がGOODしきい値以下であること（＝ページ読み込みのうち少なくとも75%がGOODに収まること）」を基準にしている。

Core Web Vitals は“バージョニングされた指標”で、Google が毎年見直し・更新している。
FID → INP のように、新しい研究成果に応じて改善され続ける仕様。

ページの読み込み・操作性・視覚安定性を数値で評価できる。

Core Web Vitals は以下の 3 つで構成される（2025年11月現在）：

  • LCP（読み込み体験）
  • INP（操作体験）
  • CLS（視覚安定性）

主要 3 指標

LCP（Largest Contentful Paint / 読み込み）

ページ内のメインコンテンツが描画されるまでの時間。

ページの“中心的な要素”が描画されるまでの時間を測る。

LCP の対象はブラウザが自動判定する。多くの場合は「ファーストビューのヒーロー画像」や「そのページで最も大きなビューポート内要素」。

ロード体験を評価するための最重要指標。

LCPとして扱う要素の優先順位

  • <img>
  • <video>ポスターフレーム
  • CSS の background-image
  • ブロックレベル要素内のテキスト

理想値

  • GOOD: ≤ 2.5 秒
  • Needs improvement: 2.5–4.0 秒
  • POOR: > 4.0 秒

改善策（主に Load）

🔴 即効性・影響大、🟡 中程度、🟢 効果はあるが他と併用推奨

  • Hero 画像や動画の最適化（WebP/AVIF・圧縮・適切なサイズ）🔴
  • LCP 要素の preload 🔴
<link rel="preload" as="image" href="/hero.avif" fetchpriority="high">

※fetchpriority="high"は対応ブラウザが限定的なので対応環境で有効。未対応環境ではpreloadを併用

※CSS背景画像をLCPにしたい場合はでは拾われないケースがある

  • レンダリングブロッカー CSS/JS の削減（ クリティカルCSS のインライン化、jsの非同期読み込み）🟡
  • CDNやキャッシュを活用した配信高速化 🟡
  • サーバー応答（TTFB）の短縮 🟢
  • 重要でない JS の遅延読み込み
  • Client-side JS の肥大化削減（bundle/ship の見直し）

INP（Interaction to Next Paint / 応答性）

ユーザーの操作（タップ・クリック・タイプ）に対する応答性。

2024 年に FID に代わって主要指標へ格上げされた。

FIDに変わってINPが選ばれた理由は、FID は “最初の入力” しか測定しなかった、INP は “たまたま速かった一回の入力” ではなく、“ページを使い続けたときの操作全体の快適さ” を測る指標

INP は「最も遅い 1 回」ではなく、全入力イベントの 98 パーセンタイルの値で評価される。

INP は、ページ内のすべての入力イベントを集計し、そのうち**98 パーセンタイル（最も遅い 2% を除いた最大値）**を採用することで、異常値に引っ張られすぎず、実際の操作感に近い応答性を評価できる。

理想値

  • GOOD: ≤ 200ms
  • Needs improvement: 200–500ms
  • POOR: > 500ms

対策（主に Response）

🔴 即効性・影響大、🟡 中程度、🟢 効果はあるが他と併用推奨

  • 重いイベントハンドラの分割・最適化 🔴
// ❌ Before: 一度に全処理
button.addEventListener('click', () => {
  heavyCalculation(); // 500ms
  updateUI();
});

// ✅ After: 分割実行
button.addEventListener('click', async () => {
  requestIdleCallback(() => heavyCalculation());
  updateUI(); // すぐ反映
});

※ユーザー操作に対する即時フィードバックはidleに送らない。UI反応は先に、小さい処理をidleへ。

  • Long Task の削減 🟡
    • メインスレッドの混雑を減らす（Web Workerや遅延ロードに分割 / JavaScriptの処理を軽量化）
  • スクロール・タッチ系の Passive Listener 🟡
element.addEventListener('touchstart', handler, { passive: true });

  • requestIdleCallback / async import を活用

  • 不要な 3rd party script（Google Analytics、広告タグなど） を減らす 🔴

    ※計測を保ったまま軽量化する代替（gtagのconsent modeやdefer、server-side gtagなど）

  • アニメーション処理を JS から CSS に移行

  • レイアウトスラッシングの解消（read/write の分離）

CLS（Cumulative Layout Shift / 視覚安定性）

要素のレイアウトずれを数値化したもの。

読み込み中に “ガタガタ動く” ページを防ぐための指標。

CLS の増加は「どれくらい広い範囲の要素が」「どれくらいの距離動いたか」の掛け算で決まる。小さな揺れより、大きな揺れのほうがスコアに強く影響する。

理想値

  • GOOD: ≤ 0.1
  • Needs improvement: 0.1–0.25
  • POOR: > 0.25

対策（主に Layout / Visual Stability）

🔴 即効性・影響大、🟡 中程度、🟢 効果はあるが他と併用推奨

  • 画像・広告・iframe に width/height を指定 🔴
  • 広告や埋め込み要素の領域を確保してからコンテンツ表示 🔴
  • フォント読み込み戦略（font-display: swap） 🟡
@font-face {
  font-family: 'MyFont';
  font-display: swap; /* フォールバックを先に表示 */
  src: url('/fonts/myfont.woff2');
}
  • 動的コンテンツ挿入時に領域を確保してからコンテンツ表示 🟡
  • Lazyload でプレースホルダ（Skeleton UI）を使う
  • スタイルの後から適用（FOUC/FOIT）を最小化する

より良いユーザー体験を求めて "Skeleton UI" について深掘りする

RAIL と CWV の違い

RAILについては別ページ

ユーザー中心のパフォーマンス モデル RAIL

比較

  • RAIL はどのように作れば速く感じるか（設計思想）
  • CWV は出来上がったページを実際に速く感じているか（フィールドデータ評価）
モデル 目的 視点
RAIL UX を壊さないための設計ガイド ユーザー操作の流れ
CWV ページ全体の体験を数値で評価 実測データ・SEO

開発フェーズでは “体感速度の設計モデル” である RAIL に従い、リリース後は “実ユーザーの実測評価” である Core Web Vitals を監視するのが最も効果的。

測定ツール

Lighthouse や DevTools のスコアはラボデータ。

CWV の最終判定には、CrUX（Chrome User Experience Report）が収集した“実ユーザーのフィールドデータ”だけが使われる。

ラボデータは診断用でフィールドデータは評価用なので、「ローカル計測は良いのに CWV は悪い」という現象が普通に起こる。

速度の測定方法

PageSpeed Insights

Core Web Vitals のフィールドデータ・ラボデータをまとめて確認できる。
PageSpeed Insights
PageSpeed Insights で Chrome UX レポートデータを表示する方法

CrUX History API と CrUX Vis

実ユーザーのフィールドデータを可視化するための手段。
CrUX Vis
CrUX ツール

※CrUX Dashboard / CrUX APIは2025年11月末にサ終する予定（BigQuery は継続）
CrUX ダッシュボードのサポート終了
CrUX Dashboard

Lighthouse

ローカル環境でのオフライン測定。改善点が分かりやすい。
Lighthouse の概要

Chrome DevTools

Performance パネル
パフォーマンス機能のリファレンス
Chrome Devtools による フロントエンドパフォーマンスの計測

計測フロー例

  1. フィールドデータ（実ユーザーデータ）で現状を把握する（PSI / CrUX Vis）
    PageSpeed Insights または CrUX Visなど を使い、実ユーザーの 75 パーセンタイル値を確認する。

  2. ラボデータ（Lighthouse）で根本原因を絞り込む

  3. DevTools Performance パネルでフレームレベルの原因を深掘りする

  4. 改善 → リリース → 再計測（フィールドデータで確認）
    修正後の結果は、CrUX が収集する実ユーザーデータを通じて数日〜数週間で反映される。
    最終評価は PageSpeed Insights のフィールドデータで確認する。

まとめ

  • Core Web Vitals は、実ユーザーの体験をそのまま数値で評価するための指標
  • LCP（読み込み）・INP（応答性）・CLS（視覚安定性）の3つを改善することで、ページが「速く見える」だけでなく「使っていて気持ちいい」状態に近づく
  • Lighthouse やローカル測定ではなく、CrUX のフィールドデータで評価されるため、“実際のユーザーがどう感じたか” がそのままスコアになる点が特徴
  • RAIL は“どう作れば体感が速くなるか”の設計指針で、CWV は“作った結果がどうだったか”を測る評価指標。この2つを合わせて使うことで、UX と SEO の両方を改善できる
  • Core Web Vitals は継続的に見直される指標なので、Web.dev の更新や Chrome のリリースノートを定期的に確認すると改善方針のズレを防げる

参考サイト

Web Vitals

ウェブに関する主な指標のしきい値の定義方法

Core Web Vitals について学ぶ

Interaction to Next Paint（INP）

0
0
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
0
0

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?