Chrome 151のSoft Navigations APIにより、シングルページアプリケーション（SPA）はアプリ内のすべてのナビゲーションに対してCore Web Vitalsを報告できるようになりました。しかし、GoogleのCrUXデータセットは依然として最初のハードロードのみを記録しているため、開発者は2つの異なるパフォーマンス状況に直面することになります。

なぜSPAのメトリクスは遅れていたのか

Core Web Vitals（Largest Contentful Paint (LCP)、Interaction-to-Next-Paint (INP)、Cumulative Layout Shift (CLS)）は、ハードナビゲーションを基準に定義されました。ハードナビゲーションとは、新しいドキュメントを取得し、前のページのステートを破棄する動作を指します。

React、Vue、Next.jsなどのフレームワークで構築されたSPAは、ハードナビゲーションを発生させることがほとんどありません。リンクをクリックすると、History APIを介してURLが更新され、バックグラウンドでデータを取得し、ページ全体をリロードすることなくコンテンツを入れ替えます。既存のPerformance APIは初期のページロードしかキャプチャできないため、ユーザーがルート間を移動する際に感じるレイテンシがLCPやINPに反映されません。

この死角が、Performance TimelineやGoogleのChrome User Experience Report（CrUX）からデータを取得するダッシュボードを歪めています。ダッシュボードは「シェル」ページのLCPは非常に優れていると表示する一方で、アプリの深い階層での低速なロードを無視してしまい、パフォーマンスが健全であるという誤った感覚を与えてしまいます。

ChromeのSoft Navigations API

Chrome 151では、特定のSPAインタラクションを実際のナビゲーションとして扱うヒューリスティック（経験則）のセットであるSoft Navigations APIが導入されました。このAPIは、以下の3つのシグナルを監視します：

  • ユーザーによるインタラクション（クリック、タップ、キーボードイベント）
  • History APIによるURLの変更
  • 新しいコンテンツを描画するその後のペイントイベント

これら3つが揃うと、ChromeはPerformance Timelineにソフトナビゲーションを記録し、ハードナビゲーションと同様に、その遷移に対してCore Web Vitalsが計算されます。オープンソースの web-vitals ライブラリは7月21日にサポートを追加したため、開発者はすでに使用しているものと同じAPIを使ってこれらの数値を取得し始めることができます。

実際には、ルート変更ごとのLCP値、最後のユーザー入力の真のレイテンシを反映したINP、そしてソフトナビゲーション後のレイアウトシフトを捉えるCLSを確認できるようになります。

データの乖離：Chrome vs. CrUX

GoogleのCrUX（Chrome User Experience Report）は、PageSpeed InsightsやSearch Console、そして間接的にはランキングシグナルの基盤となっています。しかし、CrUXは依然としてハードナビゲーションのデータのみを集計しています。

その結果、一貫してはいるものの、異なる2つのデータストリームが存在することになります：

  • 内部ツール：Performance Timelineを読み取るツールは、ルートレベルのLCP、INP、CLSを表示するようになり、SPAにおけるユーザー体験を現実的に把握できます。
  • Googleの公開データセット：最初のページロードのみのメトリクスを表示し続けており、これはSearch ConsoleのレポートやGoogleのランキングアルゴリズムが参照するものです。

どちらも正しいのですが、測定しているタイミングが異なるだけです。Search Consoleのみに頼ると、初期ロード後に発生するパフォーマンスの低下を見逃す可能性があります。一方で、内部ダッシュボードだけでは、GoogleがSEOに使用する基準値を反映できません。

開発者が注意すべき点

  • ブラウザのサポート – Soft Navigations APIは、現在Chromiumベースのブラウザでのみ利用可能です。SafariやFirefoxには同等の機能がないため、一部のユーザーに対してフォールバックのロジックを維持する必要があります。
  • ヒューリスティックの限界 – このAPIは、一連の手がかりに基づいてソフトナビゲーションを判断します。URLを変更せずにコンテンツを更新する場合（例：モーダルオーバーレイや無限スクロール）、APIがそれらの遷移を見逃し、データに欠落が生じる可能性があります。
  • 信頼する前のテスト – 検知はヒューリスティックに基づいているため、アプリ上で実際のインタラクションのスイートを実行し、報告されたメトリクスを手動のタイミング（例：performance.mark を使用）と比較してください。正確性を確認した上で、初めて新しい数値に基づいて最適化の決定を下すべきです。

まとめ

Chrome 151は、SPA開発者にアプリ内のすべてのルート変更に対してLCP、INP、CLSを測定するという、待ち望んでいた機能を提供しました。しかし、Googleのランキングデータは依然として最初のハードロードのみを反映しています。CrUXが追いつくまでは、チームは2つの並行するデータセットを使い分ける必要があります。一つは真のユーザー体験を伝えるもの、もう一つは検索ランキングを左右するもの。競争の激しいウェブエコシステムにおいて、パフォーマンスを最優先するSPAを維持するためには、その両方のバランスを取り、より広範なブラウザサポートに備えることが鍵となるでしょう。