表示速度の指標として広く使われている Core Web Vitals には、長いあいだ埋まらない空白があった。JavaScript で画面の中身だけを差し替えるタイプのサイトでは、アドレスバーの URL が変わっても「新しいページを読み込んだ」とは扱われず、最初の読み込み時に測った数値がそのまま残り続けていた。その空白を埋める仕組みが Chrome に入り、解析サービス側の対応もこの夏から動き出している。

操作とURLと描画がそろった瞬間を区切りとみなす

Chrome の開発者向け資料では、この仕組みは「ソフトナビゲーション」と呼ばれている。何をもって画面の切り替わりとみなすかについて、ユーザーの操作が起点になっていること、ユーザーから見える形で URL が変わること、その操作の結果として実際に描画が起きること、という三つの条件が示された。この三つがそろったときにはじめて、ブラウザは新しい時間の起点を置く。

これが長らく難しかった理由も、あわせて説明されている。web.dev の解説によると、画面の一部だけを差し替える作りには標準的な型がなく、URL を更新するタイミングも、中身を読み込む順序も、サイトごとにばらばらだという。ちょっとした表示状態の変化でも URL を書き換えるサイトがある一方、まとまった単位でしか書き換えないサイトもある。この差を無視して一律に数え始めると、かえって実態から離れた数字になってしまう。だからこそ、フレームワークの違いに左右されない共通の線引きが必要だった。

二種類の記録が時系列に追加された

実装は Chrome 151 に入り、既定で有効になっている。パフォーマンスの時系列に、soft-navigation と interaction-contentful-paint という二種類の記録が追加された。前者は操作をきっかけにした同一文書内の履歴変化を報告し、そこから先の計測を最初の URL ではなく現在の画面に結びつける。後者は、操作によって書き換えられた部分に新しく描かれた内容を報告するもので、非同期の読み込みをまたいだ待ち時間も追える。

この二つがあると、切り替え後の画面についても LCP や INP、CLS を区切って測れるようになる。ただし細かい扱いには注意点が多い。同じ画像を出し続けている箇所は再描画されないため LCP の対象から外れ、通常の読み込みと切り替え後とで最大要素が変わることがある。最初のバイトが返るまでの時間にあたる TTFB は、切り替え時には便宜的にゼロとして扱うのが現在の推奨だ。こうした処理を自前で書かずに済むよう、公式の計測ライブラリ web-vitals は v6.0.0 でこの仕組みに対応している。

解析サービス側の数字が動くことがある

ブラウザが対応しても、実際に数値を見るのは解析サービスの画面だ。そちらの動きも出てきている。Cloudflare は 8 月 21 日に Web Analytics の計測改善を告知し、その変更履歴では 9 月 4 日に展開が完了したとしている。従来の全画面遷移に加えて、新しい API が使える環境での切り替えと、使えない環境で履歴の書き換えから推測した切り替えを、それぞれ別の種類として記録するようになった。後者では LCP は取れないが、ほかの指標は取得できるという。

注意したいのは、告知のなかで、ページビューや訪問の集計値、そして LCP の数値が変動しうると明記されている点だ。サイトの作りによって振れ幅は変わる。数字が動いたときにサイト側の不調を疑う前に、計測方法が変わったのではないかと一度立ち止まれるかどうかで、無駄な調査時間はかなり変わってくる。

手元のサイトで気にしておきたいこと

中小企業のサイトの多くは、ページごとに読み込み直す普通の作りなので、この話が直接効いてくる場面は限られる。とはいえ、商品の絞り込み、予約や見積もりの入力画面、地図や一覧の切り替えなど、部分的に画面を差し替えている箇所は珍しくない。そこがどれくらい待たされているかは、これまで数字として残りにくかった部分だ。

現時点で対応しているのは Chromium 系のブラウザだけで、検索まわりで参照される実測データにいつ反映されるかも、まだ示されていない。順位のために慌てて何かを変える話ではない。それでも、開発者ツールの計測画面ではすでに切り替えの区切りが見えるようになっている。自社サイトで JavaScript による画面の差し替えを使っているなら、その部分の待ち時間を一度自分の目で確かめておくと、次に改善に手をつけるときの判断材料になる。