2026年版 Webパフォーマンス・Core Web Vitals トレンドと実務への影響

2026年10月8日にweb.devのWeb Vitals・INP移行・LCP/INP/CLS最適化、PageSpeed Insights、Google page experience、MDNのimgとScheduler.yieldを再確認した。LCP 2.5秒、INP 200ms、CLS 0.1は良好値の参考で、端末別75パーセンタイル、現場とラボ、直近28日・URL/Origin・データ不足の読み方を分ける。良好値は順位や事業成果を保証せず、画像の寸法、遅延、優先度、メインスレッド、CLS原因、feature detectionをサイト実測で確認する。

30秒で要点

2026年のWebパフォーマンス改善では、新しい技術名を増やす前に、実際の利用者が「表示を待つ」「操作が反応しない」「読んでいる場所が動く」のどこで困っているかを分けます。

• 2026年10月4日に確認したCore Web Vitalsの良好基準は、LCPが2.5秒以下、INPが200ミリ秒以下、CLSが0.1以下です。
• INPがFIDに代わったのは2024年3月12日です。2026年にこれから移行する指標ではありません。
• 実利用者の集計と、条件を固定したラボ測定を使い分けます。画像形式の変更、コード分割、AIの提案だけで改善や検索順位の上昇を保証しません。

この記事では、公表された現在の基準、改善作業への影響、2026年以降の情報を追う方法を整理します。数値例は架空で、実サイトのLighthouse、CrUX、ブラウザ操作を計測した結果ではありません。

現在の基準と、過去の変更を混ぜない

web.devのWeb Vitalsが示す3指標は、読み込み、操作への応答、表示の安定性を扱います。ページのすべての品質を一つの点数で表すものではありません。

表が収まらない場合は、横にスクロールできます

基本となる確認は、モバイルとデスクトップを分けた75パーセンタイル（p75）です。小さい値から並べたとき、75%付近に位置する値を見る考え方で、平均値が基準内というだけでは足りません。

LCPを社内目標として2.0秒以下にすることはできますが、それをGoogleが2026年の新しい共通基準として定めたと説明するのは不正確です。公式基準と、自社で厳しく設定した目標は区別します。

INPの正式移行に関する発表では、2024年3月12日にFIDから置き換わったことが確認できます。古い監視や社内資料にFIDが残っている場合は、単にラベルをINPに変えるのではなく、集めている測定値、計算、可視化、通知条件を確認します。

PageSpeed Insightsでは、二つの測定を分けて読む

PageSpeed Insightsの公式説明は、CrUXによる実利用者データと、Lighthouseによるラボ診断を区別しています。画面の上と下に異なる値があっても、それだけでどちらかが間違っているとは言えません。

表が収まらない場合は、横にスクロールできます

URL単位のデータが足りない場合、PSIはオリジン単位へ切り替えることがあります。オリジンも不足していれば実利用データを表示できません。オリジンは同じスキーム・ホスト・ポートに属する範囲であり、見ている1ページだけの値とは限りません。

データがない状態を「速いから問題なし」と判断しないようにします。新しいページ、利用が少ないページなどでは、まずラボで問題を探し、必要な範囲で自前の実利用計測（RUM）を検討します。収集項目、同意、送信先、保持期間を定め、URLに個人情報が含まれる場合はそのまま送らない設計が必要です。

PSIの総合判定にはデータ不足時の扱いもあります。3指標が十分ある場合は各p75が良好なら合格ですが、INPが不足する場合にはLCPとCLSで判定する条件があります。画面の合否だけで「すべての操作が良好」と解釈せず、各指標の有無まで記録します。

通常のページ読み込み型Lighthouseでは利用者の操作がないため、INPの代わりにTBTなどを診断に使います。TBTが下がったことと実利用のINP改善は同一ではありません。操作を含む調査と公開後の観測で確かめます。

改善する場所は、指標ごとに切り分ける

LCP：画像容量だけに原因を決めつけない

LCPは、最初の応答までの時間、主要リソースの取得開始の遅れ、取得時間、取得後の描画の遅れに分けて調べられます。LCPの最適化ガイドは、圧縮しても別の待ち時間へ移るだけで、LCPが変わらない例も示しています。

架空の例として、600＋400＋800＋500＝2,300ミリ秒とします。画像の取得時間だけが200ミリ秒減り、他が不変なら2,100ミリ秒になります。しかし、描画を待つ処理が同じだけ延びれば、全体は2,300ミリ秒のままです。「画像20%削減だからLCPも20%改善」とは計算できません。

まず実際のLCP要素を特定します。画像なら、初期HTMLから見つけられるか、遅延読み込みにしていないか、必要な寸法より極端に大きくないかを確認します。サーバー応答が遅ければ、DB、キャッシュ、リダイレクトなど別の層も調べます。

次のHTMLは、同じ内容の画像を640×360と1280×720で用意した場合の例です。images/hero-640.webpとimages/hero-1280.webpを同じ配下に置きます。実際の絵柄に合わせてaltを変更してください。画面先頭のLCP候補を想定しているので、lazyは付けていません。

<!doctype html>
<html lang="ja">
<meta charset="utf-8">
<meta name="viewport" content="width=device-width, initial-scale=1">
<title>主要画像の確認例</title>
<style>
  body { margin: 0; }
  main { max-width: 1280px; margin: auto; }
  img { display: block; width: 100%; height: auto; }
</style>
<main>
  <h1>サービスの紹介</h1>
  <img src="images/hero-1280.webp"
       srcset="images/hero-640.webp 640w, images/hero-1280.webp 1280w"
       sizes="(max-width: 1280px) 100vw, 1280px"
       width="1280" height="720" fetchpriority="high"
       alt="作業台に並ぶ制作道具">
</main>
</html>

MDNのimg要素の説明では、fetchpriorityは優先度のヒントです。すべての画像をhighにするのではなく、必要なものへ絞ります。下方の画像には遅延読み込みを検討できますが、本文の役割や端末ごとの表示位置を確認します。AVIFやWebPも、画質、寸法、変換時間、配信設定を比較して選びます。

INP：操作の直前・処理中・描画待ちを調べる

操作が遅いときは、イベント処理そのものが重いとは限りません。その前に別のJavaScriptが動いていたり、処理後のレイアウト計算が重かったりします。INPの改善ガイドに沿って、どこで時間を使っているかを調べます。

初期読み込みのJavaScriptを減らす、使う場面まで分割する、不要な第三者タグを削る、といった選択肢があります。ただし、分割しすぎると操作後の追加取得が待ち時間になります。ツリーシェイキングも、ビルド設定や副作用のあるモジュールに影響されるため、配信物と実際の操作で確認します。

重い処理を小分けにする場合、scheduler.yieldはすべての主要ブラウザで一様に使える機能ではありません。次は対応する環境ではyieldし、未対応ならタイマーへ渡す小例です。yield-demo.mjsとしてNode.jsで実行すると分岐と集計を確認できますが、Nodeの実行結果からブラウザの描画やINP改善を証明することはできません。

import assert from 'node:assert/strict';

export async function sumInChunks(values, environment = globalThis) {
  if (!Array.isArray(values) || !Array.from(values).every(Number.isFinite)) {
    throw new TypeError('有限の数値の配列を指定してください');
  }
  let total = 0;
  for (let i = 0; i < values.length; i++) {
    total += values[i];
    if ((i + 1) % 100 === 0 && i + 1 < values.length) {
      if (typeof environment.scheduler?.yield === 'function') {
        await environment.scheduler.yield();
      } else {
        await new Promise(resolve => environment.setTimeout(resolve, 0));
      }
    }
  }
  return total;
}
const input = Array.from({ length: 250 }, (_, i) => i + 1);
let yields = 0, timers = 0;
const supported = { scheduler: { yield: async () => { yields++; } } };
const fallback = { setTimeout: callback => { timers++; callback(); } };
assert.equal(await sumInChunks(input, supported), 31375);
assert.equal(await sumInChunks(input, fallback), 31375);
assert.equal(yields, 2);
assert.equal(timers, 2);
assert.equal(await sumInChunks([], fallback), 0);
await assert.rejects(sumInChunks([NaN], fallback), TypeError);
console.log('分岐と計算を確認しました。描画時間は測定していません。');

この100件という区切りは説明用で、適切なタスク時間を保証する値ではありません。前段の入力検証自体も同期処理なので、巨大な配列や重い1件の処理にそのまま適用しません。実務では入力規模、キャンセル、結果の途中表示、処理失敗、Web Workerへ移す必要性を検討します。タイマーによる代替はschedulerと同じ優先度制御ではありません。

CLS：読み込み後の変化も含めて場所を確保する

画像や動画には寸法かアスペクト比を設定し、広告、埋込み、遅れて届く内容にも必要な領域を確保します。CLSの改善ガイドが説明するように、初期読み込みのラボ結果だけでは、その後の移動を見落とすことがあります。

スクロール後、フォントの切替後、埋込みの読込み後などを確認します。動いた要素が原因とは限らず、その上へ新しい内容が挿入された結果という場合もあります。動きをすべて禁止するのではなく、予期しない移動を引き起こす箇所を特定します。

実務では、予算・回帰確認・責任をセットにする

改善の優先度は、悪い数値の順だけでは決まりません。対象の利用者数、重要な操作、影響の大きさ、変更の危険、担当できる範囲を合わせて考えます。モバイルの比率も、一律の世間の数字ではなく自サイトの条件で確認します。

表が収まらない場合は、横にスクロールできます

配信JavaScript量や画像サイズに社内予算を設けることもできます。以下は、架空の圧縮後JavaScript量を検査する完結したNode.js例です。budget.mjsとして保存して実行します。250 KiBはこの例だけの上限で、Googleの閾値でも、CWV合格の代わりでもありません。

import assert from 'node:assert/strict';

function withinBudget(bytes, limit) {
  if (!Number.isSafeInteger(bytes) || bytes < 0 ||
      !Number.isSafeInteger(limit) || limit < 0) {
    throw new RangeError('バイト数は非負の安全な整数にしてください');
  }
  return bytes <= limit;
}
const before = 300 * 1024, after = 225 * 1024, limit = 250 * 1024;
assert.equal(withinBudget(before, limit), false);
assert.equal(withinBudget(after, limit), true);
assert.equal(withinBudget(limit, limit), true);
assert.throws(() => withinBudget(-1, limit), RangeError);
const reducedBytes = before - after;
const reductionPercent = reducedBytes / before * 100;
assert.equal(reducedBytes, 76800);
assert.equal(reductionPercent, 25);
console.log({ reducedBytes, reductionPercent });

実プロジェクトでは、どのルートを対象にするか、圧縮方式、共有チャンク、遅延取得分を含めるかを固定し、ビルド出力から実際の値を読み込みます。予算を通っても機能が壊れたり、操作後の待ち時間が増えたりしていれば採用できません。

2026年以降の情報は、正式仕様と仮説を分けて追う

新しいブラウザAPIや画像形式、AIによる改善提案は検討材料です。採用時は、対象ブラウザでの対応、フォールバック、導入費、保守、セキュリティと機能の回帰を確認します。自動化する場合も、測定、変更案、承認、公開、戻す判断を一つにまとめないようにします。

「来年は完全自動最適化になる」「指標の重要度が一律に上がる」といった予測を、現在の公式要件として扱いません。指標の変更はweb.devのライフサイクルと公式の変更履歴で、検索への影響はGoogleのページエクスペリエンス説明で確認します。CWVはランキングに使われますが、良いスコアが上位表示を保証するわけではありません。

まず、重要な1ページと1操作を選び、測定条件、現在の課題、変更案、再確認する日を残します。Webパフォーマンス完全ガイドで全体を整理し、応答開始までの時間や性能の監視へ、見つかった原因に沿って進みます。