Core Web Vitals 2026年版:基準値と変化した点
指標そのものは今年も変わっていません。変わったのはその周辺のツール類です。いま本当に正しいことだけを整理します。
指標は3つ、しかも2024年からずっと同じ3つです。Largest Contentful Paintは2.5秒以内、Interaction to Next Paintは200ミリ秒以内、Cumulative Layout Shiftは0.1以内が目標値です。いずれも実際のページ読み込みの75パーセンタイルで判定され、モバイルとデスクトップは別々に集計されます。
2026年のCore Web Vitalsのしきい値は
数値の出どころは、Googleが定義を公開しているweb.devの各指標ページです。すべてページ読み込みの75パーセンタイルで採点されるため、合格と言えるのは実際の訪問者の4分の3が良好な結果を得たときであって、手元のノートPCで速く表示されたときではありません。
| 指標 | 測っているもの | 良好 | 改善が必要 | 不良 |
|---|---|---|---|---|
| LCP | 読み込み。最も大きな可視要素の描画が完了するまで | 2.5秒以内 | 2.5〜4.0秒 | 4.0秒超 |
| INP | 応答性。ページ上のすべてのインタラクションが対象 | 200ミリ秒以内 | 200ミリ秒超500ミリ秒以下 | 500ミリ秒超 |
| CLS | 視覚的な安定性。予期しないずれが最も集中した区間 | 0.1以内 | 0.1超0.25以下 | 0.25超 |
2026年にCore Web Vitalsは実際に変わったのか
変わっていません。指標の構成も、しきい値も1つとして動いていません。最後の構造的な変更は2024年3月12日で、この日にInteraction to Next Paintが安定版のCore Web Vitalとなり、First Input Delayが廃止されました。web.devのINP becomes a Core Web Vitalで告知されたとおりです。それ以降は安定した3指標のままで、実験的な指標も、置き換えが予告された指標もありません。安定版のCore Web Vitalsの変更は年1回を超えないというのがGoogle自身のルールで、2025年も2026年も変更のないまま過ぎました。
動いたのは計測レイヤーのほうです。Chrome for DevelopersにあるChrome UX Reportのリリースノートには、2025年1月にLCP画像のサブパートとLCPリソースタイプがCrUX APIに追加されたこと、同じリリースでECTディメンションがBigQueryから廃止されたこと、そして旧CrUXダッシュボードが2025年11月末で提供終了となったことが記録されています。これとは別に、ソフトナビゲーションへの対応がChrome 151に到達し、シングルページアプリケーションでもLCP、INP、CLSを1つの終わらないページビューではなく個々のルート変更に紐づけられるようになりました。ただしこのドキュメントは、ソフトナビゲーションをCrUXでどう報告するかは未定だと明記しており、現時点でSearch Consoleの数値に影響するものではありません。
今年から新しい指標が入ったと言われたら、それはどの指標かと聞き返してください。そんな指標はありません。
LCPが遅いときの直し方
LCPが悪いケースは、ほぼすべてが「発見されにくさ」の問題です。web.devの主要な改善策のガイドが最初に挙げるのは3点です。LCPリソースをスクリプトで挿入するのではなくHTMLソース上に見える形で置くこと、fetchpriority="high"を付けること、そしてドキュメント自体をキャッシュするCDNでTime to First Byteを削ること。その先は、バックフォワードキャッシュや投機ルールによる即時遷移を狙い、クリックされた時点で次のページがすでに用意されている状態を目指します。
INPが高いときの直し方
INPは3つの要素に分解できます。ハンドラーが動き出すまでの入力遅延、ハンドラー自体の処理時間、そして次のフレームが描画されるまでの表示遅延です。報告されるスコアはおおむねページ上で最も遅いインタラクションで、インタラクション50回につき外れ値が1つ無視されます。推奨される対策は、長いタスクがメインスレッドを塞がないようこまめに処理を譲ること、そもそも配信するJavaScriptを減らすこと、そしてDOMを小さく保ちCSS containmentを使ってレンダリング更新を軽くすることです。タグマネージャーも監査してください。たいていはそこに原因があります。
レイアウトのずれを直す
CLSが見ているのは、ずれが最も集中した区間です。この区間は、間隔が1秒未満のずれをまとめたもので、長さは最大5秒までと定義されています。すべての画像と埋め込みに幅と高さ、またはアスペクト比を明示し、バナーや同意バーのように後から挿入される要素の場所をあらかじめ確保し、ページをバックフォワードキャッシュの対象のまま保ち、レイアウトを強制するプロパティではなくtransformでアニメーションさせてください。
Core Web Vitalsはどこで計測すべきか
常にフィールドデータが先です。ラボツールはリリース前にデグレを捕まえるためのもので、実機を使う実ユーザーの代わりにはならないとweb.devははっきり書いています。フィールドデータの実体はChrome User Experience Reportです。PageSpeed InsightsもSearch ConsoleのCore Web Vitalsレポートも、どちらもここを読んでいます。web-vitals JavaScriptライブラリを使えば、28日間のローリングウィンドウよりはるかに短い遅延で自社の数値を取得できます。ラボ側はChrome DevToolsとLighthouseが担当します。両方使ってかまいませんが、合否を決めるのはフィールドデータだけです。
Core Web Vitalsは今もGoogleの順位に影響するのか
Google検索セントラルは今もCore Web Vitalsをページエクスペリエンスの一部として文書化しており、実際のユーザー体験を測る指標であり、コアランキングシステムが評価しようとしているものと一致すると説明しています。これは「ランキング要因」より意図的に弱い言い方です。他の条件が同等のページ同士の決め手として扱い、検索がどう扱うかとは別に、コンバージョンに明確に効くものとして扱うのが妥当です。同じ考え方は技術的な土台全般にも当てはまり、そこを見るのが当サイトのAI対応度チェッカーです。
満点を追いかけている人には、ひとつ言っておくことがあります。75パーセンタイルで3つのしきい値をすべて満たした時点がゴールで、その上に上位のご褒美はありません。緑になったら、次の1時間は「そもそもクローラーがそのページに到達できるのか」に使うほうが有益です。robots.txtを見れば5分で確認できます。