Core Web Vitalsの歴史

• ウェブサイトの性能を測定する Core Web Vitals は、2014年から Google の複数チームが協力し、AMP プロジェクトの限界を克服して、あらゆるウェブサイトに適用できる オープン標準の性能指標 を定義しようとする取り組みから始まった
• 2020年5月に 3つの中核指標（読み込み速度の LCP、インタラクション応答性の FID、視覚的安定性の CLS）が正式発表され、実際のユーザー体験を反映する フィールド計測可能な指標 として設計された
• 2021年には Google Search の Page Experience アップデート を通じて検索順位シグナルとして導入され、Top Stories での AMP 独占要件が削除されて オープンウェブの競争環境 が整えられた
• Chrome ブラウザの最適化、WordPress など主要 CMS の改善、JavaScript フレームワークとの協業を通じて、2023年時点でユーザー待ち時間を 累計1万年以上削減 し、2024年には 3万年削減 を達成
• 2024年には FID を INP に置き換え、SPA 向けの Soft Navigation API を導入するなど継続的に進化し、ユーザー中心の高速で安定したウェブ エコシステムの構築に貢献している

---

背景と動機: AMP からオープンウェブ指標へ

• Google は長年にわたり、速度とユーザー体験をウェブの中核原則として強調してきたが、依然として多くのサイトが 遅い体験 を提供していた
• 2010年、Google Search は サイト速度を検索順位シグナル として使い始め、これは性能を SEO に組み込んだ初期の試みだった
• 2015年ごろに AMP(Accelerated Mobile Pages) プロジェクトが導入され、高速読み込みのために最適化されたページを提供したが、Google キャッシュから配信される閉鎖的な環境であるという オープン性と柔軟性の問題 が生じた
• 2018年の Speed Update でモバイル検索順位にページ速度が適用され、Google Ads もモバイルランディングページ速度スコアを導入し、速い体験がより良いコンバージョン率 をもたらす点を強調した
• AMP 専用アプローチから脱却するため、Chrome と Search のチームが協力し、特別なフレームワークなしですべてのページに適用できるオープンウェブ性能指標 の定義を開始
  • 数百万のページを分析して、高速でユーザーフレンドリーなウェブページの公開標準 を定義
  • 実際のユーザー体験を反映する フィールド計測可能な指標 を目標に設定
  • ユーザーエンゲージメントのような結果と相関する指標を見つけようとした

Core Web Vitals の定義: ユーザー体験の3本柱

• 2020年5月、Google が Web Vitals イニシアティブ を正式発表し、「すべてのウェブページに適用されるユーザー体験の中核的側面」に焦点を当てた Core Web Vitals を導入

• 初期の Core Web Vitals は 3つの中核指標 で構成された

  • Largest Contentful Paint(LCP): 主要コンテンツがレンダリングされる時点を測定する 読み込み速度指標 で、First Contentful Paint や onload を超えて、ユーザーが実際に意味のあるコンテンツを見る時点に焦点を当てる
  • First Input Delay(FID): ユーザーの最初のインタラクションとブラウザ応答の間の遅延を測定する インタラクション応答性指標 で、ページが即座に反応するか、あるいは重いスクリプトによって遅延するかを捉える
  • Cumulative Layout Shift(CLS): 読み込み中にページレイアウトがどれだけ移動するかを測定する 視覚的安定性指標 で、予期しないレイアウト移動を合算し、低い CLS は安定的で快適な体験を意味する

• 指標の選定は広範な研究と実験に基づいて進められた

  • Amar Sagoo、Annie Sullivan、Vivek Sekhar らが 人間とコンピュータの相互作用研究 を通じて、客観的な性能数値とユーザー認識の相関関係を発見
  • 読み込み時間は 2〜3秒以内、入力応答は 100ms 以内、レイアウト移動は 最小化 が理想的
  • 実際のユーザーデータを分析して 実用的なしきい値目標 を設定: LCP 2.5秒未満、FID 100ms 未満、CLS 0.1 未満（75パーセンタイル基準）
  • このしきい値を満たすページは、ユーザーの 離脱確率が24%低い

• Google はこれらの指標を 標準化され、オープンなもの にするために取り組んだ

  • WICG およびウェブ性能標準グループを通じて ウェブ仕様ドラフト を公開
  • Chrome および他のブラウザが PerformanceObserver API を通じて計測できるよう実装
  • 2020年5月、開発者がサイトに組み込んで実際のユーザーの LCP、FID、CLS を測定できる オープンソースの web-vitals JavaScript ライブラリ を公開
  • Addy Osmani が指標をリアルタイムで表示する Core Web Vitals 拡張機能 を開発
  • エコシステム全体でアクセス可能かつ有用なものにしようとする幅広い取り組みを反映している

Page Experience: Google Search の順位における Core Web Vitals

• Google Search チームは Core Web Vitals を Page Experience アップデート の一部として迅速に採用した

• 2020年5月28日、Google Search Central はこれらの指標を順位アルゴリズムに組み込む予定だと発表

  • コンテンツ関連性が似ている2つのページがある場合、より良いユーザー体験を提供するページ を上位にランク付け
  • Page Experience シグナル は Core Web Vitals と既存の UX 関連シグナル（モバイルフレンドリー、HTTPS セキュリティ、煩わしいインタースティシャルの回避）を組み合わせる
  • 優れたコンテンツが依然として最重要であり、高速なサイトが単に速度だけを理由に、より関連性の高いサイトを上回ることはない
  • 同点や僅差の場合には 良好な Web Vitals が決定要因 になり得る

• 最も注目すべき発表は Top Stories カルーセルからの AMP 要件の撤廃 だった

  • 以前はモバイルで Google News/Top Stories が AMP を要求していたが、Page Experience アップデート後は AMP でないページでも Core Web Vitals とその他の基準を満たせば掲載可能 になった
  • 「AMP はもはやモバイル Top Stories の必須条件ではなく、良好なページ体験を持つすべてのページに開かれている」
  • オープンウェブが AMP フレームワークに流入しなくても改善される よう促したいという Google の自信を示している

• Google はエコシステムに十分な事前通知を提供した

  • 2020年が COVID-19 パンデミックにより困難な年であることを認識し、順位変更は 2021年まで適用されない と発表して最低6か月の警告を約束
  • 2020年11月の更新で、Page Experience の順位変更が 2021年5月から開始 されると案内
  • 最終的に Page Experience アップデート は 2021年6月中旬にロールアウトが開始され、8月末までに完全適用された（モバイル検索）
  • デスクトップ検索向けの類似アップデートは 2022年2〜3月に実施された

• アップデートが適用されると、Google の順位アルゴリズムは Core Web Vitals を数百あるシグナルの1つとして使い始めた

  • 3つの CWV 指標すべてで「良好」のしきい値を満たすページは、良好なページ体験 を持つものと見なされる
  • Google は Google Search Console に Page Experience レポート を作成し、サイト所有者が Chrome UX Report データを使って、しきい値を通過するページの割合を確認できるようにした
  • ウェブマスターや SEO 専門家に、ページ体験シグナルの観点からサイトがどう機能しているかについて直接的なフィードバックを提供

• Google は検索結果で良好なページ体験を持つページへの バッジ表示 も検討したが、恒久的なバッジアイコンは追加されなかった

  • 報酬は主に明示的なラベルではなく、順位上昇 という形で提供された
  • しばらくの間、Google は Search Console と検索結果の実験で一時的な「Page Experience」インジケーターを表示した
  • 要点: Google は性能と UX を公然とインセンティブ化しており、優れた Core Web Vitals の達成はユーザーを満足させるだけでなく、検索でのページ可視性の向上 にもつながり得る

ツールとデータ: Chrome UX Report と性能測定

• Google は Web Vitals のためにツールとデータへの大規模な投資を実施

• Chrome UX Report（CrUX） がその取り組みの中核

  • 2017年から存在する実ユーザー体験指標の公開データセットで、数百万の Chrome ユーザーから数百万サイトに関する匿名化されたパフォーマンスデータを収集
  • Core Web Vitals の公開時に、CrUX はデータセット内のすべてのオリジン URL について直ちにLCP、FID、CLS のレポートを開始
  • 誰でもフィールドパフォーマンスデータをクエリ可能
  • BigQuery 経由でのアクセス提供後、CrUX API と CrUX Dashboard を公開し、開発者や SEO 担当者が自社サイト（または競合サイト）が実環境で CWV 指標においてどうなっているかを簡単に確認可能に
  • CrUX History API の導入により、これらの指標の時系列データを提供し、数か月にわたる進捗の追跡が可能に

• 開発者ツール面でも迅速な統合が進行

  • 2020年末までに Google の大半のパフォーマンスツールがCore Web Vitals を強調するよう更新
  • Lighthouse（Chrome DevTools および PageSpeed Insights で使われるオープンソースの監査ツール）が CWV 関連の診断とスコアを統合
    • 「Largest Contentful Paint は X 秒でした（目標は 2.5 秒未満）」のような監査を追加し、改善提案も提供
  • Chrome DevTools に Core Web Vitals パネルとタイムラインマーカーを追加し、ページ読み込み中に LCP 要素やレイアウトシフトを確認可能に
  • PageSpeed Insights（PSI） も CWV を中心に据える形で全面改修
    • CrUX から取得した LCP、FID（後に INP）、CLS のフィールドデータを上部に目立つ形で表示
  • Google Search Console は、各指標についてページを「良好」「改善が必要」「不良」のバケットにグループ化する専用の Core Web Vitals レポートを提供し、サイト所有者が問題領域を正確に把握できるようにした
  • Elizabeth Sweeny、Paul Irish、Addy Osmani らがツール開発を主導

• Web 開発コミュニティもサードパーティーツールで対応

  • Real User Monitoring（RUM）サービスの提供事業者が Core Web Vitals を迅速に統合
  • Akamai の mPulse、New Relic の Browser エージェント、Dynatrace、Datadog、SpeedCurve などが LCP、FID、CLS を第一級の指標として即座にサポート
  • Cloudflare も、スクリプトを挿入して Web Vitals を収集できる Browser Insights サービスを導入
  • web-vitals JS ライブラリの存在により、あらゆる分析ツールがこれらの指標を容易に収集可能に
  • 2021年までにCore Web Vitals は Web パフォーマンス監視ツールのダッシュボードで一般化
  • この広範な利用可能性により認知が広がり、開発者がパフォーマンス改善を主導できるデータが提供された

• Chrome User Experience Report のデータは、Web 全体の進捗追跡にも不可欠

  • 2021年から2022年にかけて「良好な」CWV を持つトラフィックの比率は着実に増加
  • HTTP Archive の年次 Web Almanac や Google 自身のブログ更新でたびたび報告
  • 測定可能で公開可視な指標を持つことが、一種の好循環的な競争を生み出した
  • サイト所有者やプラットフォーム提供者は Core Web Vitals を誇り、改善しようと努め始めた

影響と改善: Web をより高速で安定したものにする

Chrome ブラウザの最適化

• Core Web Vitals が定着すると、Web エコシステム全体でこれらの指標を改善するための大規模かつ多面的な取り組みが促発された

• Google Chrome エンジニアリングチームはブラウザを詳細に見直し、Chrome が Web ページを読み込み・レンダリングする方法を最適化

  • Chrome の巨大なユーザーベースを考えると、ブラウザレベルの小さな改善でもWeb 全体に利益をもたらす
  • 2020〜2023年の間に Chrome でリリースされた主な最適化が含まれる

• LCP のためのコンテンツ優先順位付け

  • Chrome が重要なコンテンツの読み込みを優先するよう変更
  • HTML 内の最初の数枚の画像（しばしば LCP 画像を含む）を識別し、より高いネットワーク優先度を付与
  • 最初の 5 枚の画像をこのように優先すると、一部のページで LCP が 3.1 秒から 2.5 秒に改善
  • fetchpriority 属性（Priority Hints の仕組み）のような新しい Web 標準を導入し、開発者が画像や iframe を LCP のために高優先度として指定できるようにした

• Back/Forward Cache（BFCache）

  • Chrome は技術的な複雑さのため、歴史的にはページを完全に BFCache していなかったが、ここ数年で多くのページに対して BFCache を有効化
  • 2023年までにデスクトップと Android の両方で顕著な BFCache ヒット率の増加を達成
  • ページに「戻る」ユーザーは即座に表示できるようになった（LCP はゼロ、入力遅延もゼロ。ページがアンロードされていないため）
  • Amazon のような大規模プラットフォームが Chrome の BFCache の恩恵を受け、Chrome の改善（バージョン M112）後にback/forward キャッシュ利用が 22.7 ポイント増加したと報告

• Prerendering（NoState Prefetch/Prerender2）

  • Chrome は、ブラウザがバックグラウンドでページを完全に読み込み・レンダリングし、その後ユーザーが遷移したときに即座に切り替えられる新しいプリレンダラー（Prerender2）を公開
  • 当初は Google Search（上位結果のプリレンダリング）や入力 URL の予測に使われ、LCP を劇的に短縮可能に
  • Chrome は、omnibox 検索のプリレンダリングがその遷移で中央値 LCP を 500〜700ms（約 15〜25%）改善すると報告
  • Chrome はこれを慎重にロールアウト中（誤予測やプライバシー上の問題を避けるため）

• ネットワークおよびスケジューリングの最適化

  • Chrome チームは入力応答性におけるさまざまな小さな遅延を特定して解消
  • pointerdown 時の事前接続機能を導入し（タップ/クリック開始時、離す前に）、リンク遷移の接続確立で数ミリ秒短縮
  • クロスオリジン遷移で平均約 6〜10ms 高速な LCP を実現
  • 複数タブが開いているときのブラウザのメインスレッドのタスク処理方法を改善し、競合を低減
  • タスクスケジューリングの調整や、バックグラウンドタブに Windows 11 の EcoQOS のような仕組みを使うことで、Chrome は高負荷シナリオでINP を約 5%、LCP を約 2%改善

• レンダリングおよび JavaScript エンジンの改善

  • Chrome の RenderingNG アーキテクチャ刷新（2021年ごろ完了）により、レンダリングはより効率的になった
  • 画像読み込み優先度の引き上げ（LCP 画像が重要度の低い他作業の後ろでブロックされないようにする）や、V8 のより賢いガベージコレクションのタイミング調整（アイドル時間中に実行）により、より滑らかな体験を実現
  • Chrome 開発者は、マルチプロセスブラウザで Cookie にアクセスする方法が jank を引き起こしていることを発見
    • すべての document.cookie 呼び出しが別プロセスから同期的に取得される必要があった
    • Cookie に対する共有メモリベースのバージョン管理を導入して Chrome の Cookie アクセスを最適化し、多くの不要なプロセス間往復を削減
    • サイトがすべての操作で Cookie 読み取りを過剰に送っている場合の入力遅延を低減

• これらすべての Chrome 最適化は、測定可能な差をもたらした

  • 2023年末までに Google は、Chrome の平均ページ読み込みが Core Web Vitals 登場前より 166ms 速くなったと報告した
  • ウェブ全体にわたる影響は非常に大きく、削減された時間を合計すると、Chrome チームは 2023年だけでも速度改善によって、ユーザーがページ読み込みを待つ累積時間を1万年以上、さらにページが入力に応答するのを待つ時間を1,200年以上節約したと試算している
  • CWV の「良好」基準を満たすトラフィックの割合も大きく上昇した
  • 初回発表時にはページ読み込みの約 3 分の 1 が CWV 基準で良好だったが、2023年までに Chrome のデスクトップページ訪問の約 68%、モバイルでは約 64% が 3 つの CWV 閾値すべてを満たした

広範なウェブエコシステムの改善

• 改善は Google 側だけの話ではなく、より広範なウェブ開発者コミュニティ、フレームワーク、プラットフォームベンダーも、Core Web Vitals が特定した性能問題の解決に乗り出した

• 画像最適化と遅延読み込み

  • 画像がしばしば最大コンテンツであり、LCP の一般的な原因でもあると認識され、ウェブフレームワークや CMS はより賢いデフォルト設定を実装した
  • オフスクリーン画像向けのネイティブ HTML loading="lazy" が標準化され（Chrome や Yoav Weiss、Addy Osmani などのウェブ標準への貢献者の支援により）、WordPress やその他のプラットフォームで採用され、不要な画像読み込みを劇的に減らした
  • WordPress は 2020年に画像の遅延読み込みをデフォルトで有効化した後、LCP が遅れないよう、最初のヒーロー画像を遅延読み込みしないよう改善した
  • 新しい <img fetchpriority="high"> 属性もフレームワークで素早く活用され、より高速な読み込みのためにメイン画像を優先表示するようになった

• WordPress Performance Team

  • WordPress は全ウェブサイトの約 40% を占めており、その性能は非常に大きな影響力を持つ
  • 当初、WordPress サイトは CWV スコアで後れを取っており、2021年のレポートでは WordPress サイトの通過率が他の一部エコシステムより低いことが示され、警鐘を鳴らした
  • これに対し、コミュニティは WordPress コアの速度を体系的に改善するため、Google や他社の貢献者を含む専任の Core Performance Team を結成した
  • 近年のリリースでは、その取り組みが成果を上げている
    • WordPress 6.3（2023） にはテーマレンダリングやアセット読み込みに関する多数の最適化が含まれ、LCP 指標ベースで WordPress 6.2 と比べ、ブロックテーマは27%高速、クラシックテーマは18%高速に読み込まれるコアテーマを提供した
    • 実際、数百万のサイトが WordPress をアップグレードするだけで高速化した
  • WordPress チームは画像処理を最適化し、特定のコストの高い処理にキャッシュを追加し、性能を新機能と同等の優先事項にした
  • その結果、良好な CWV スコアを持つ WordPress サイトの割合は劇的に増加し、いくつかのデータでは、すべての CWV を満たす WP サイトの割合が 2020年から 2022年の間に4倍以上増加したことが示されている

• Wix とウェブサイトビルダー

  • Wix、Squarespace、Duda のような他のホスティング型ウェブサイトプラットフォームも、Core Web Vitals を性能改善のきっかけとして活用した
  • Wix は主要インフラの刷新（キャッシュ、高速なサーバー、より良いクライアントサイドコード）を実施し、良好な CWV スコアを達成する Wix サイトの割合を数倍に増やした
  • 事例研究では、Wix は「良好」な CWV を持つサイトの割合を約 1 年で4% から 33% 以上へ引き上げたと報告している
  • これは、プラットフォームにおける性能重視の文化への転換が、膨大な数のユーザーに利益をもたらし得ることを証明した
  • Duda のような他のビルダーも、多くの場合、顧客サイトの大多数が良好な CWV に到達していると宣伝しているが、これはそのプラットフォームがベストプラクティスを標準搭載している（レスポンシブ画像、CDN 配信、効率的なテンプレートなど）ためだ
  • こうした競争圧力により、個々のサイト所有者が性能の専門家でなくても、利用するプラットフォームが内部的な改善を推進するようになった

• JavaScript フレームワーク（Chrome Aurora）

  • Chrome Aurora チームは、人気の JavaScript フレームワークと協力するための Chrome 内の特別タスクフォースとして 2020年半ばに発足した
  • Aurora のメンバー（Addy Osmani、Kara Erickson、Houssein Djirdeh など）は、React/Next.js、Angular、Nuxt、Gatsby などのフレームワーク作者と緊密に協力し、共通のボトルネックを特定して解決策を提供した
  • この協業により、次のような機能が提供された
    • Next.js の next/script コンポーネント（サードパーティースクリプトをメインスレッド外でより効率的に読み込む）
    • Angular の組み込み NgOptimizedImage ディレクティブ（画像を自動的に遅延読み込みし、適切なサイズと優先順位を設定）
    • Nuxt の Google Fonts 最適化モジュール
  • 影響は大きく、2022年にはこれらのフレームワークで構築されたサイトの Core Web Vitals 中央値スコアが目に見えて改善した
    • Next.js サイトの CWV 通過率は**20.4% から 27.3%**へ
    • Angular は**7.6% から 13.2%**へ
    • Nuxt は**15.8% から 20.2%**へ改善した
  • 個別の成功事例も豊富だ
    • EC サイト Land's End は Angular の画像最適化を採用した後、モバイルでLCP を 40% 改善した（ラボテスト）
    • CareerKarma は Next.js の改善されたスクリプト読み込みを使い、LCP を 24% 削減した

• 実際のビジネス指標

  • 最終的に、より良い Core Web Vitals は単に Google を満足させるためのものではなく、実際のユーザー満足度やビジネス成果と相関する
  • 多くの企業が、CWV 改善をユーザーエンゲージメントと結び付ける事例研究を共有している
    • ニュースサイト Economic Times はスクリプト処理を最適化して INP を改善し、ページビュー 42% 増加、直帰率 49% 減少を達成した
    • 旅行予約サイト RedBus は INP を改善し、コンバージョン率 7% 増加を確認した
    • インドのオンラインマーケットプレイス Meesho は LCP を 6.9 秒から 2.5 秒へ短縮し、直帰率を約 17% 減少、コンバージョン率を 3% 増加させた
  • これらの例は、性能が単なる技術指標ではなく、ユーザーが滞在し、より多く読み、より多く購入することにつながることを改めて示している
  • こうした成功事例は、開発者やプロダクトチームが Web Vitals を優先する動機をさらに強めた

エコシステム全体の改善成果

• ブラウザチーム、フレームワーク作者、CMS 開発者、そして無数の個々のウェブ開発者による結集した努力が、ウェブの状態を劇的に改善した
• 明確で実行可能な指標を確立することで、Core Web Vitals は誰もが追従できる共通目標を生み出した
• 重要なのは、これがエコシステムを独自技術に閉じ込めることなく、オープン標準とデータを活用して達成された点である
• 2023年時点で、約 40% のウェブサイト（そして適切に運用された商用サイトではさらに高い割合）が、現在ではすべての Core Web Vitals 閾値を通過している一方、2020年初頭には通過していたのはごく一部だった
• 完全に通過していないサイトでも、一般に以前より速く、より滑らかになっている
• 性能意識の文化も広がっており、開発者はますます CWV 指標を監視するようになっている（調査によれば、約 51% の開発者が Web Vitals を積極的に追跡・最適化している）
• Google は、こうした速度改善を推進したにもかかわらず、ウェブプラットフォームに対する開発者満足度は高く維持されたと述べている
  • これは、指針が開発者を絶望させるのではなく、達成可能だったことを示している
  • このバランスは重要であり、もし CWV 目標が不可能だったりツールが不十分だったりすれば、開発者の反発を招いたかもしれないが、実際にはコミュニティはウェブをより良くするために結集した

指標の進化: INP、Soft Navigation など

• Google は当初から、Core Web Vitals が時間とともに進化していくことを認めていた
• 2020年の3つの指標セットは、固定的または完全なものとして意図されていなかった
• ユーザー体験の別の側面（滑らかなスクロールやページ後半での長いタスクなど）は、当初は扱われていなかった
• Chrome Web Platform チームは、新しい指標や既存指標の改善についての研究を継続している

Interaction to Next Paint(INP)

• 元の CWV における明確なギャップは、最初のクリックを超えたインタラクティブ性だった
• FID は_最初の_入力遅延しか測定しないため、第一印象には重要だが、その後の多くのユーザー操作中にページが応答しなくなる可能性がある
• これに対処するため、Annie Sullivan や Michal Mocny といった Google の担当者が INP を提案した
  • ページ上の_すべて_（または少なくとも多くの）ユーザー操作を見て、ある種の最悪ケース（または98パーセンタイル）の遅延を報告する
  • 「ユーザーが任意の時点でページと対話したとき、応答として次のフレームが描画されるまでにどれくらいかかるのか？」という問いを立て、イベント処理とレンダリングの遅延を捉える
• INP は 2022年に実験的なフィールド指標として導入され、CrUX に収集された
• 2023年初頭までに、Google は INP が FID よりも全体的な応答性の問題をより適切に予測することを発見した
• そのため 2024年3月に INP が FID を Core Web Vital として置き換えると発表した
  • この変更は開発者に十分前もって伝えられた
  • Lighthouse や PageSpeed Insights のようなツールが INP の表示を開始し（「まもなく CWV として提供予定」と表示）
  • Web.dev は INP 改善のためのガイダンスを提供し、これは多くの場合、一般的なパフォーマンス改善策と同じ実践に行き着く。長いタスクの分割、重い計算のための Web Worker の使用など
• FID から INP への移行は、より重要なものをより適切に扱うために指標を反復していく CWV チームの哲学を強調している
  • この場合、ページ読み込みだけでなく、ユーザーの訪問全体を通した一貫した応答性を確保する

滑らかさとアニメーション

• Chrome チームが調査したもう1つの側面は、アニメーションのフレームレートやスクロールの jank のような視覚的な滑らかさだった
• まだ公式な CWV 指標ではないが、この領域では作業が進行中である
• Chrome チームは RUM ツールにSmoothness 指標を提供し（CrUX では「Jankiness」として報告されることもある）、途切れがちなアニメーションのようなものを定量化している
• ブラウザには jank を減らすためのヒューリスティクスも導入された
  • たとえば、タッチイベントをディスプレイフレームと同期させる方法を調整することで、Android における Chrome 自身のスクロールの滑らかさを2倍に高めた（2023年8月の Fast and Curious 投稿で詳しく説明されている）
• 将来的には、公式な「smoothness」Web Vital が登場する可能性や、INP が特定のアニメーション遅延を扱うよう拡張される可能性がある
• 重要なのは、Google がこうした側面を認識し、積極的に実験していることだ

Soft Navigation(SPA)

• 初期の CWV 定義の1つの限界は、完全なページ読み込み（いわゆる「ハードナビゲーション」）に重点を置いていたことだった
• しかし現代の Single-Page Application(SPA) は、多くの場合一度読み込まれた後、完全な再読み込みなしにコンテンツやルートを動的に更新する
• このような_soft navigation_（リンクをクリックしても完全なブラウザナビゲーションは行われず、JavaScript によってコンテンツが変更されること）は、元の実装では LCP や CLS の測定に捉えられなかった
  • ブラウザの観点では依然として同じページであるため、大きな DOM 更新が新しい LCP を引き起こさない
• これは SPA の場合、開発者がアプリ内で「ページ遷移」を評価するためにカスタム計測に依存しなければならず、CrUX（フィールド）データもそうした後続ナビゲーションについては見えていなかったことを意味する（記録されるのは初回ページ読み込みの CWV のみ）
• これを修正するため、Chrome は Soft Navigation API を提案した
  • この作業の功績はすべて Yoav Weiss にある
  • 2023年半ばに Chrome は SPA ナビゲーションをヒューリスティクスで検出する実験を開始した
  • 2025年半ばまでに Soft Navigations API のOrigin Trialが開始された
• Chrome エンジニアの Barry Pollard と Michal Mocny の説明によれば、soft navigation とは「JavaScript がナビゲーションを横取りし（例: History API やフレームワークルーターを通じて）、完全な再読み込みなしに history.pushState によって URL を更新しつつ、既存ページのコンテンツを更新すること」である
• 新しい API により、ブラウザ（および開発者）はこうしたイベントをマークし、本質的に新しいページビューのように扱うことが可能になる
• 決定的なのは、これによって soft なルート変更をページ読み込みのように扱い、SPA で Core Web Vitals を測定できるようになることだ
• この API を使うと、LCP のような指標は soft navigation ごとにリセットされ、新しいビューの最大コンテンツを捉えられる（Performance Timeline の_"interaction-to-next-paint"_エントリの概念を使用）
• 同様に、CLS はナビゲーションごとに分割でき、INP は現在のビューに関連付けられる
• これはクライアントサイドルーティングアプリの世界に CWV を持ち込む大きな前進であり、こうしたアプリは非常に一般的だ
• 2025年後半時点で、Soft Nav API は試験運用中であり、開発者はオプトインしてフィードバックを送ることができる
• 時間の経過とともに、Chrome は soft nav 指標を完全にサポートし、フィールドデータ（CrUX）もそれを統合すると予想される
• こうした進化は、ユーザージャーニーが複数の段階で構成されており、ランディングページの読み込みだけではないことを認めるものであり、Web プラットフォームがその全体の流れを測定し最適化すべきことを示している

今後の進化

• Google は指標を毎年継続的に改善していくことを示している
• 新しいしきい値のような調整が見られる可能性がある
  • たとえば、Web が全体としてさらに高速になれば、将来的に「良好な」LCP の目標が 2.5秒 より厳しくなるかもしれない
  • あるいは、明確なギャップが見つかれば、まったく新しい指標が登場する可能性もある
• すべての追加事項は公開プロセスを経る（Web パフォーマンス標準の策定、他のブラウザベンダーとの議論など）。INP の場合と同様だ
• Google は時間の経過とともに、より多くのページ体験シグナルを統合する計画である
  • たとえば、サイトが良い実践を用いている場合に、Chrome を通じて「高速なページ」バッジを表示することのような、プライバシーやセキュリティに関する実験がある
• ただし検索順位の文脈では、Google は最近メッセージングを単純化している
  • 2023年までに、個別シグナルを超える明示的な「ページ体験」ランキングブースターは存在しないと述べた
  • 本質的には、ページ体験に関する考慮事項をコアランキングアルゴリズムにより微妙な形で統合している
  • しかし、サイト所有者の観点では何も変わっていない
  • 高速で、応答性が高く、安定したページは、ユーザー満足度と良好な SEO の両方にとって根本的に重要である

まとめ

• Core Web Vitals の歴史は、Web プラットフォームが課題に応えてきた物語である
  • ユーザー体験の質は測定可能であり、報われるべきだという洞察から始まり、指標、ブラウザ、検索順位、ツール、フレームワーク、ホスティングプラットフォームにまで及ぶ広範な運動へと発展した
  • わずか数年という短い期間で、Web パフォーマンス全体にわたって大きな改善を促した
  • 旅はまだ続いている。SPA のための_soft navigation_測定や、指標の継続的な改善といった今後の革新により、高速で快適な Web 体験に対する業界の取り組みは今なお強力である
• Core Web Vitals は単なる指標セットではなく、より健全で高速、そしてユーザー中心の Web のための触媒であることを証明した
  • それは多くの人々の協力によって築かれた遺産であり、Web を使うすべての人に利益をもたらす遺産である