表示速度の指標であるCore Web Vitalsには、長いあいだ測りきれない領域がありました。ページ全体を読み直さず、JavaScriptで中身だけを入れ替えて画面を切り替えるサイト、いわゆるシングルページアプリケーション(SPA)の二枚目以降の画面です。10月13日に公開されたChrome UX Report(CrUX)の9月分データで、この領域を含めた実験的な指標が加わりました。ブラウザ、開発ツール、計測ライブラリ、公開データの四つがそろって動いた形なので、何が変わったのかを順に整理してみます。
読み直さない画面遷移はなぜ測れなかったのか
通常のウェブサイトでは、リンクを押すとサーバーから新しいHTMLを受け取り、ブラウザはそこを新しいページの始まりとして扱います。これをハードナビゲーションと呼びます。一方、ReactやVue、Angularなどで作られたSPAは、最初に一枚のHTMLとアプリ全体のコードを読み込み、その後はHistory APIでアドレスバーのURLだけを書き換えながら画面を差し替えます。こちらはソフトナビゲーションと呼ばれます。
見た目は新しいページに移ったように見えても、ブラウザから見れば同じページの中で表示が変わっただけです。そのためCore Web Vitalsは事実上、最初の読み込みだけを表し、その後の操作で起きたことは最初に開いたURLの成績にまとめて計上されるか、そもそも測られていませんでした。DebugBearの解説によると、何を画面遷移とみなすかはフレームワークごとに考え方が違い、URLを書き換える時機も中身を読み込む順番もまちまちだったことが、標準的な計測を難しくしていたとされています。
Chromeがソフトナビゲーションとみなす条件
この問題に対してChromeは、各フレームワークのルーターに入り込むのではなく、ブラウザ側の判定ルールで見分ける方法を選びました。利用者の操作がきっかけでURLが書き換わり、その結果として画面の表示が変わった場合に、それをソフトナビゲーションとして扱います。2026年8月に出たChrome 151で、この判定とCore Web Vitalsの計測が正式に入りました。
条件を絞っているぶん、作る側が画面遷移のつもりでも数えられない場面が出てきます。たとえば一定時間でアプリが自動的に別の画面へ切り替わるような処理は、利用者の操作が起点になっていないため対象外です。仕様はW3Cの標準化の手前の段階にあたるWICGで草案として扱われており、実装が出たことで仕様が固まったわけではない点も押さえておきたいところです。現時点で実装しているのはChromium系だけで、SafariとFirefoxでは測れません。
指標ごとに変わる数字の意味
ソフトナビゲーションが検出されると、各指標の集計はそこで区切られ、新しい画面の分として測り直されます。サーバーとのやり取りが発生しないため、最初の1バイトまでの時間(TTFB)は常に0になります。最大の要素が描画されるまでの時間(LCP)は直前の画面の描画を含まず、画面の差し替えで大きな要素が新たに現れたときだけ正の値になります。レイアウトのずれ(CLS)と操作への反応(INP)も、直前の遷移以降に起きたものだけを数えます。一回の滞在をまるごと表していた成績が、画面ごとの小さな単位に分かれるわけです。
開発ツールと計測ライブラリはどこまで対応したか
Chromeの開発者向けツール(DevTools)では、Chrome 152でPerformanceパネルのリアルタイム計測とトレース表示がソフトナビゲーションに対応し、Chrome 153と154では分析結果をまとめるInsightsにも対応が広がりました。公式ブログはこれで計測から分析までが一通りつながったと説明しています。タイムライン上ではソフトナビゲーション由来の項目にアスタリスクが付き、Nav*やLCP*のように表示されるので、通常の読み込みと見分けがつきます。
実際の利用者のデータを集める側では、Googleが公開しているweb-vitalsライブラリに、別系統で開発されていた対応が本体へ取り込まれました。各計測関数にオプションを一つ渡すだけで、画面ごとの値が報告されるようになります。
import { onLCP, onINP, onCLS } from 'web-vitals';
onLCP(console.log, { reportSoftNavs: true });
onINP(console.log, { reportSoftNavs: true });
onCLS(console.log, { reportSoftNavs: true });このオプションを付けなければ、従来どおり最初の読み込みの分だけが報告されます。自社の計測をCrUXの数字と突き合わせたいときは付けない、画面ごとの体感を詳しく追いたいときは付ける、という使い分けになります。
CrUXの実験的な指標で何がわかったか
今回のCrUXでは、LCP、INP、CLSのそれぞれにソフトナビゲーションを含めた実験的な版が追加され、BigQueryのデータセットとCrUXのAPIの両方から取得できるようになりました。サイトごとの影響を確かめられるよう、可視化ツールのCrUX Visも更新されています。
公開された集計を見ると、従来の基準で三つの指標すべてが良好だったオリジンは55.9%でした。ソフトナビゲーションを含めて数え直すと、この割合は59.5%に上がります。指標別では、LCPが良好なオリジンが68.3%から72.1%へ、CLSが81.7%から85.1%へ、INPが85.4%から87.4%へと、いずれも上向いています。最初の読み込みで重いコードをまとめて受け取るSPAは、その後の軽い画面切り替えが評価に入っていなかったぶん、実際の体感より厳しく見えていたことがうかがえます。
注意したいのは、これがあくまで実験的な版として別に用意されたデータだという点です。従来のCore Web Vitalsの数字は、引き続き最初の読み込みを基準にしたものとして公開されています。DebugBearの解説も、検索の観点では当面は最初の読み込みを重視し、利用者のためにはその後の画面遷移も速く保つべきだと整理しています。
WordPressや一般的な企業サイトへの影響
中小企業のコーポレートサイトや、WordPressのテーマで組んだ一般的なサイトの多くは、リンクのたびにHTMLを読み直すつくりです。こうしたサイトは、そもそも従来の計測で全ページがきちんと測られていたので、今回の変更で数字が大きく動くことは考えにくいでしょう。
影響が出やすいのは、WordPressを管理画面として使い、表側をReactなどの別アプリで作る構成や、ページの切り替えをなめらかに見せるためにJavaScriptで中身だけを差し替える仕組みを入れたサイトです。こうしたサイトでは、これまで最初の一枚の成績で全体が語られていました。画面ごとに数字が分かれると、どの画面への移動で表示が遅れているのか、どの操作で反応が鈍っているのかを個別に追えるようになります。逆に言えば、最初の読み込みの重さに隠れていた特定画面の問題が表に出てくる可能性もあります。
計測の仕組みが変わったことで、これまでSPAの採用をためらう理由の一つだった「表示速度の評価が見えにくい」という点は、少しずつ解消に向かっています。ただしSafariとFirefoxでは測れないため、スマートフォンの利用者が多いサイトでは、iPhoneでの体感を別の方法で確かめる必要は残ります。
制作の現場でいま確かめておきたいこと
まず、自分たちが担当しているサイトが読み直し型なのか、中身の差し替え型なのかを把握しておくことです。テーマやプラグインの中に画面遷移を差し替える機能が含まれている場合もあるので、DevToolsのPerformanceパネルで記録し、Nav*の表示が出るかどうかを見れば判断の材料になります。
差し替え型のサイトであれば、CrUX Visで実験的な指標と従来の指標の差を見比べておくと、今後の評価の変化に備えられます。自前で計測している場合は、web-vitalsライブラリのオプションを付けた計測を別枠で取り、CrUXと合わせる計測と分けて管理しておくと混乱しにくくなります。また、利用者の操作を起点にしない自動の画面切り替えは数えられないことを踏まえ、計測したい画面遷移がきちんとリンクやボタンの操作から始まっているかも確認しておきたいところです。
私たちRESONIXも、読み直し型と差し替え型の両方のサイトに関わってきましたが、差し替え型の表示速度は手元の感覚に頼る部分が大きかったのが正直なところです。仕様はまだ草案で、実装もChromium系に限られますが、測れなかったものが測れるようになる流れははっきりしてきました。数字が正式な評価に組み込まれる前に、手元のサイトで一度眺めておくだけでも、次の改修の判断材料が一つ増えるはずです。
