WEBサイトCrUXがソフトナビゲーション込みの実験的な3指標を公開した。ページ全体を読み込み直すサイトは変化を見込まなくてよいと公式は書く ── 自分のサイトが影響を受ける側かを確かめる13項目（2026年10月時点）
CrUXがソフトナビゲーション込みの実験的な3指標を公開した。ページ全体を読み込み直すサイトは変化を見込まなくてよいと公式は書く ── 自分のサイトが影響を受ける側かを確かめる13項目（2026年10月時点）
目次
01 何が起きたか — 2026年10月13日、CrUXが「ソフトナビゲーション込み」の実験的な指標を3つ公開した
引用について
この記事の「" "」で囲んだ英語の文は、公式の資料からの引用で、日本語訳は記事の筆者が付けたものである。原文は各出典のページで確認できる。
web.devのブログに書かれたこと
Chrome UX Report（略称CrUX）は、Chromeを使う実際の利用者の体験を集めた公開データである。2026年10月13日、web.devのブログが「Experimental soft navigation metrics now available in CrUX」（訳: ソフトナビゲーションの実験的な指標がCrUXで使えるようになった）という記事を載せた。
「ソフトナビゲーション」は、ページ全体を読み込み直さずに、JavaScriptで画面の中身とURLを入れ替える画面の移り方のことである。記事の核になる文は次のとおりである。
"Today, following the launch of the Soft Navigations web platform API in Chrome 151, Chrome is publishing experimental versions of the Core Web Vitals metrics in the Chrome User Experience Report (CrUX) dataset that include soft navigations."
（訳: 本日、Chrome 151でのSoft Navigations Webプラットフォーム APIの公開に続いて、Chromeは、ソフトナビゲーションを含むCore Web Vitals指標の実験的な版を、Chrome User Experience Report（CrUX）のデータセットで公開している。）
もうひとつ、読み違えやすい点が同じ記事に書かれている。
"While these metrics measure the same speed, responsiveness, and visual stability dimensions as Core Web Vitals, Google's stable Core Web Vitals scores remain unchanged while these experimental versions are evaluated alongside them."
（訳: これらの指標は、Core Web Vitalsと同じ速さ・反応・見た目の安定を測るが、Googleの安定版のCore Web Vitalsのスコアは、これらの実験的な版が並べて評価されている間は変わらない。）
つまり、今回公開されたのは追加の数字であり、今ある安定版の数字は置き換えられていない。
3つの新しい指標を表にまとめる
新しい指標は、LCP・INP・CLSの3つのそれぞれに「ソフトナビゲーション込み」の版が付いた形である。ブログと、CrUX APIの文書に書かれた名前を並べる。
| 指標 | CrUX APIでの名前 | 公式の説明の要点 |
|---|---|---|
| LCP | experimental_largest_contentful_paint_with_softnavs | ハードとソフトの両方のナビゲーションにわたって、最大コンテンツの表示を測る |
| INP | experimental_interaction_to_next_paint_with_softnavs | セッション全体を最初のページ読み込みに帰さず、1回ごとのソフトナビゲーションごと、およびハードナビゲーションごとに分けて、操作への反応を測る |
| CLS | experimental_cumulative_layout_shift_with_softnavs | ハードとソフトの両方のナビゲーションにまたがって、画面ごと・URLごとに見た目のずれを評価する |
BigQueryのCrUXのデータセットでは、同じ3つが「experimental」の欄に、largest_contentful_paint_with_softnavsなどの名前で並んでいる。要約用の表では、末尾に「_sn」が付く列（例: p75の値）になる。
いつから、どこで見られるか
公式のブログは、見られる場所を「CrUX BigQuery dataset, CrUX API, and CrUX History API」（訳: CrUXのBigQueryのデータセット、CrUX API、CrUX History API）と書き、2026年10月の公開分から使えると説明している。見える化の画面「CrUX Vis」にも、新しい指標を見る機能が加わった。
CrUXのリリースノートの該当の項目は、見出しが「September 2026」で、公開日が2026年10月13日である。9月分のデータが、10月の公開として出た、ということである。BigQueryの文書は「CrUX data on BigQuery is released on the second Tuesday of the following month.」（訳: BigQueryのCrUXのデータは、翌月の第2火曜日に公開される。）と書いており、2026年10月13日はその10月の第2火曜日に当たる。
2026年9月分のデータで、数字はどれくらい動いたか
CrUXのリリースノートの「September 2026」の項目には、新旧の指標を並べた数字が載っている。追跡しているオリジンは18,376,044件（前月比で0.4%増）である。ソフトナビゲーションを含めない従来の数字と、含めた数字は次のとおりである。
"72.1% of origins had good LCP (↑ 5.6% from when soft navs are not included)"
（訳: 良好なLCPのオリジンは72.1%だった（ソフトナビゲーションを含めない場合から5.6%の上昇）。）
この「5.6%」は、ポイントの差ではなく、割合の増え方である。リリースノートの従来の値68.3%から計算すると、72.1%との差は3.8ポイントで、増え方は約5.6%になる。CLSは81.7%が85.1%（差3.4ポイント）、INPは85.4%が87.4%（差2.0ポイント）、3つ全部が良好のオリジンは55.9%が59.5%（差3.6ポイント）である。ポイントの差は、筆者がリリースノートの数字から計算した。
実験の終わりと、次の追加
ブログには、この先の予定も書かれている。
"We aim to graduate from experimental in May of 2027, subject to feedback. Once graduated, Search Console will switch to use the new data."
（訳: 私たちは、フィードバックしだいで、2027年5月に実験の段階を終えることを目指している。終えたあとは、Search Consoleが新しいデータを使うように切り替わる。）
また、11月のCrUXの公開では、ナビゲーションの種類とFCPの、ソフトナビゲーション込みの指標を追加する見込み、と書かれている。2027年5月は「目標」であって、確定した日付ではない。
02 なぜ・背景 — 画面を切り替えずに変える作りは、これまで1つのページとして測られていた
SPAは、URLが変わってもページが1つに見える
ブログは、Core Web Vitalsの取り組みについて、こう書いている。
"However, Single-Page Applications (SPAs) have been a gap for the initiative."
（訳: しかし、シングルページアプリケーション（SPA）は、この取り組みの穴だった。）
SPAは、ページを開いたまま、リンクを押すと画面の中身とURLをJavaScriptで書き換える作りのサイトである。ブラウザの側から見ると、アドレス欄のURLが変わっても、新しいページの読み込みは起きていない。ここが、従来の指標が測りにくかった理由である。
ブログが示す、これまでの測り方
ブログによれば、これまでのCrUXは、SPAを閲覧したとき、利用者が最初に入ってきた「ハード」な読み込みだけを記録していた。その後の画面の切り替えは、別の読み込みとして数えず、セッション全体の操作や見た目のずれを、最初に着いたページにまとめていた。
今回の新しい指標では、ページの内容とURLの両方が変わる画面の切り替えを、それぞれ1つのナビゲーションとして測る。CrUX APIでは、ソフトナビゲーションの数字は、最初に着いたページではなく、移った先のURLのもとに出る（通常の対象となる条件を満たす場合）、と書かれている。
Chromeが「ソフトナビゲーション」と見なす3つの条件
Chrome for Developersの文書は、ソフトナビゲーションの定義を3つの条件で書いている。
- ナビゲーションが、利用者の操作で始まる
- 利用者に見える形でURLが変わる
- その操作で、見える画面の描画が起きる
文書は、この定義が一部のサイトでは誤検出（利用者が移ったとは思わない動きを移動と数える）や検出漏れを起こしうる、と認めている。この機能は、Chrome 151から既定で有効になっている。
3つの指標は、それぞれ別の理由で数字が動く
公式のブログは、画面の切り替えが多いサイトについて、指標ごとの理由を分けて書いている。
- LCP — 2回目以降の切り替えは、最初に読み込んだコードや素材を再利用するため、速くなる。
- INP — 反応を、セッション全体で最も遅い操作ではなく、画面の切り替えごとに測るようになる。
- CLS — 見た目のずれを、長いセッションの合計ではなく、画面ごとに分けて測るようになる。
INPについての公式の文は次のとおりである。
"You'll likely see better INP scores because responsiveness is now measured per page view rather than taking the slowest interaction across an entire browsing session, roughly doubling the Android pass rate for sites with mostly soft navigations."
（訳: 閲覧のセッション全体で最も遅い操作を取るのではなく、反応を1回の画面表示ごとに測るようになったため、INPのスコアはよくなるだろう。ほとんどがソフトナビゲーションのサイトでは、Androidの合格率がおよそ2倍になる。）
03 この記事に出てくる用語
ソフトナビゲーションとハードナビゲーション
用語
ソフトナビゲーション（soft navigation）—ページ全体を読み込み直さず、JavaScriptで画面の内容とURLを書き換えて移る画面の移り方。反対に、サーバーから新しいHTMLを読み込む通常の移り方をハードナビゲーションと呼ぶ。
ブログや多くの記事サイト、ふつうの複数ページのサイトは、リンクを押すたびにサーバーから新しいHTMLを読み込む。この記事では、こうしたサイトの作りを「複数ページ型」と呼ぶ。公式の用語では、MPA（multi-page application）である。
SPAとMPA
用語
SPAとMPA—SPAは、1つのページを開いたまま画面の内容を書き換えていく作り。MPAは、画面の移動ごとに別のHTMLを読み込む作り。公式のFAQは、SPAとMPAのどちらも質の高い体験を届けられると書き、Googleはどちらの作りにも好みはない、と説明している。
実験的・保留・安定という段階
Core Web Vitalsの指標には、公開までの段階がある。web.devの文書は、次のように書いている。
"Metrics on the Core Web Vitals track go through a lifecycle consisting of three phases: experimental, pending, and stable."
（訳: Core Web Vitalsの流れにある指標は、実験的・保留・安定の3つの段階からなる流れを通る。）
今回の3つの指標は、いちばん最初の「実験的」の段階にある。同じ文書は、保留の段階の指標が、少なくとも6か月その段階に置かれる、とも書いている。つまり、実験的の段階の数字は、今後の検証で定義そのものが変わりうる。
オリジンと「良好」の割合
用語
オリジン—「https://example.com」のように、プロトコル・ホスト名・ポート番号をまとめたサイトの単位。CrUXのリリースノートの「良好のオリジンの割合」は、そのオリジンのデータが基準の「良好」に入っているサイトが、追跡している全サイトの何%かを表す。
この記事に出てくる割合の多くは、「利用者の何%」ではなく「サイト（オリジン）の何%」である。割合を読むときは、何の何%かを先に確かめる。数字を借りるときの注意は、「+28%」と「+9%」は、同じ調査の、同じプラットフォームの数字だった ── 他人が測った数字を自分のサイトに当てはめる前に確かめる3点にまとめてある。
04 型別 — 適用範囲・この発表が測っていないこと・確かめる順番
🅰 適用範囲 — 数字が変わるサイトは、少数である
ブログは、どのサイトで数字が変わるかを、割合で示している。
"Across all origins in CrUX, around 70% have little to no soft navigation traffic (fewer than 5% of page views are "soft"), and only about 7–11% of origins use soft navigations for more than half of their page views."
（訳: CrUXのすべてのオリジンのうち、およそ70%はソフトナビゲーションの通信がほとんどない（画面表示の5%未満が「ソフト」）。画面表示の半分より多くでソフトナビゲーションを使うオリジンは、約7〜11%にとどまる。）
反対に、変化が集まるのは「SPAとして作られていて、移動の回数が多いサイト」である。ブログは、これらが全体に占める割合は小さい一方、上位1,000サイトでは、AndroidとDesktopのどちらでも35〜42%に当たる、と書いている。
複数ページ型のサイトについて、ブログは次のように書いている。
"If your site doesn't use JavaScript to dynamically swap out page content and update the URL without a full browser reload, you shouldn't expect to see any changes in your metrics."
（訳: あなたのサイトが、ブラウザの読み込み直しなしに、JavaScriptでページの内容を動的に入れ替えてURLを更新する作りでないなら、指標に何の変化も見込まなくてよい。）
🅱 この発表が測っていないこと
ブログとリリースノートからは、自分のサイトの結果は分からない。書かれていないことを3つに分ける。
- 自分のサイトの数字。ブログの割合は、サイト全体の分布である
- Chrome以外のブラウザの結果。FAQは、Chromium以外のエンジンは新しいAPIにまだ対応していない、と書く
- 2027年5月以降に、新しい数字が検索の評価にどう使われるか。ブログは、Search Consoleが新しいデータに切り替わる、とだけ書いている
この3つめの点は、Core Web Vitalsが順位に与える影響についての公式の言い方とは別の話である。順位の側の公式の整理は、Core Web Vitalsは、クロールやリンク評価に影響するのか ── 公式ドキュメントを確認する（2026年8月時点）にある。
🅲 手順 — 確かめる5段
手順は、「作りを確かめる」「CrUX Visで見る」「APIで取る」「差を判定する」「RUMとSearch Consoleを照らす」の5段である。05章のチェックリストは、この順番に並べてある。
手順1 — 画面の移り方を、ページの種類ごとに確かめる
まず、サイトの主なページの種類（トップ・一覧・詳細・会員画面・購入の流れ）ごとに、リンクを押したとき、ブラウザの読み込み表示が出て画面が切り替わるか、画面の一部だけが入れ替わるかを書く。種類ごとに違うことがある。トップは複数ページ型でも、会員画面だけが画面の書き換えで作られている例がある。
手順2 — CrUX Visで、新しい3つの指標を見る
CrUX Visに自社のオリジンを入れ、新しい3つの指標が出るかを見る。訪問者が少ないサイトでは、CrUXにデータが出ないことがある。出ない場合は、その旨と、出なかった範囲（オリジン・個別のURL）を書き留める。
手順3 — CrUX APIで、3つの項目を取る
データを機械で取りたいときは、CrUX APIで、記事の表にある3つの名前を含むリクエストを出す。History APIにも、新しい指標が含まれる、とブログは書いている。一方、History APIの文書（最終更新は2025年4月11日）には、新しい指標の記述が見つからなかった。使えるかどうかは、実際にリクエストを出して応答を見て確かめる。
手順4 — 従来の指標との差を、ポイントで判定する
従来のLCP・INP・CLSの「良好」の割合と、新しい3つの割合を並べ、差をポイントで書く。この記事の目安では、差が1ポイント未満なら「ほぼ同じ」、それ以上なら「差がある」と書く。この目安は公式のものではなく、判定を揃えるための筆者の基準である。
手順5 — RUMとSearch Consoleの数字は、別に扱う
自社でRUM（実際の利用者の計測）を入れている場合は、提供元がソフトナビゲーションに対応しているかを聞く。Chrome for Developersの文書も、RUMの提供元が対応しているかを確かめるよう促している。Search Consoleの「ウェブに関する主な指標」は、今の時点では従来の数字のままである。画面の日付と値を保存して、今後の変化と比べる。
実務のヒント
「新しい指標が出る＝自社に影響がある」とは限らない。複数ページ型のサイトでは、新しい指標は従来の指標と同じか、ほぼ同じ数字になる、と公式は書いている。差が出たときだけ、原因を調べる順番にすると、手が空く。
05 明日、自社のサイトで確認できることチェックリスト
以下は、CrUXの新しい3つの指標が、自社のサイトに関係するかを確かめる項目である。1〜4番目は画面の移り方、5〜8番目はCrUX Visと数字の判定、9〜10番目はAPI、11〜12番目はSearch ConsoleとRUM、13番目は記録と再確認である。チェックの状態はブラウザに保存され、サーバーには送られない。
- 自社のトップページと、そこから移る先のページ3つで、リンクを押したときに読み込み表示が出て画面全体が切り替わるか、一部だけが入れ替わるかを書き留める
- 主なページの種類（トップ・一覧・詳細・会員画面・購入の流れ）ごとに、画面の移り方を1行ずつ表に書く
- 主なページ5つで、ページのソースと、ページが読み込む自社のJavaScriptのファイルを開き、「pushState」と「replaceState」の出現数を数える
- 開発の担当者に、画面の移り方を「ページ全体の読み込み」と「JavaScriptでの書き換え」のどちらで作っているか、ページの種類ごとに聞く
- CrUX Visに自社のオリジンを入れ、新しい3つの指標が表示されるか確認する
- 表示されたら、LCP・INP・CLSの「良好」の割合を、従来の値と並べて書き留める
- 従来の値との差をポイントで書き出し、差が1ポイント未満のものと以上のものに分けて印を付ける
- 差があるものは、スマートフォンとパソコンに分けて、それぞれの割合を書き留める
- CrUX APIを使える担当者に、3つの項目を含むリクエストを1回出してもらい、応答に3つが入っているか確認する
- CrUX History APIでも同じ3つが取れるか、1回リクエストを出して応答を確認する
- Search Consoleの「ウェブに関する主な指標」を開き、画面の日付と値を1枚保存する
- 自社が使っているRUMの提供元に、ソフトナビゲーションへの対応の予定を聞き、返答を日付つきで書き留める
- 11月のCrUXの公開後と、2027年5月の目標の時期に、手順5〜8を同じ表でやり直す日をカレンダーに入れる
06 代替・他の選択肢 — 新しい数字を見る道具の使い分け
道具ごとに、見える範囲が違う
CrUXの新しい数字と、自社で測る数字を見る道具には、それぞれ得意な範囲がある。
| 道具 | 何が分かるか | 使いどころ |
|---|---|---|
| CrUX Vis | オリジンまたはURLの、新旧の指標の並び | 手順2。画面で素早く差を見る |
| CrUX API | オリジンまたはURLの、新しい指標の分布 | 手順3。機械で取り、記録に残す |
| CrUX History API | 過去の週ごとの推移（ブログは新しい指標も含むと説明） | 手順3。推移を見る |
| BigQuery | 月ごとの全体のデータ。experimentalの欄に新しい指標 | SQLを書ける担当者が、多数のサイトを比べる |
| web-vitalsライブラリ | 自社の利用者の画面ごとの指標（v6.0.0からソフトナビゲーションに対応） | 手順5。自社のRUMを作る |
| DevTools | 手元で操作したときの、画面ごとの指標 | 再現と原因の絞り込み |
DevToolsでの測り方は、Chrome DevToolsのPerformanceパネルがソフトナビゲーションの測定に全面で対応し、Applicationパネルに広告の画面が加わった ── 1画面で切り替わるページと広告タグを自分の手で測る13項目（2026年10月時点）に書いた。この記事では操作を繰り返さない。
当サイトの無料ツールとの使い分け
当サイトには、ページの表示の速さを測る無料のツールがある。🔧 Lighthouseで最大3ページを監査するツール（利用には無料の会員登録が必要）は、決まった条件の機械で測る「ラボデータ」の側のツールである。CrUXの数字は、実際の利用者の「フィールドデータ」である。2つは別のものを測っているので、数字が合わないのが普通である。ページ全体の状態は🔧 サイト総合分析・レポートのツールで確認できる。
注意
Lighthouseなどのラボの測定が、新しい3つの指標に対応しているかは、この記事では確かめていない。新しい3つは、CrUXのフィールドデータで見るものとして手順を組んだ。
全体の傾向と自社を切り分ける
新しい指標が出て、従来との差が出たとき、自社の数字が動いた理由の切り分けは、CrUXの2026年8月分でもINPの悪化が続き、原因は公式にも分かっていない ── 自社の悪化を全体の傾向と切り分けて確認する13項目（2026年10月時点）と同じ考え方で整理できる。LCPとINPの段階の見方は、Cloudflareの実ユーザー計測が、LCPを4段階・INPを3段階に分けて見せるようになった。直す前に、いちばん長い段階を決める ── 自社の遅さがどの段階で起きているかを確認する13項目（2026年10月時点）に書いた。
07 当サイトの例 — 複数ページ型で、画面の書き換えのコードは見つからなかった
2026年10月16日に、6ページのソースを数えた
当サイトは、リンクを押すと新しいHTMLを読み込む複数ページ型で作られている、と考えている。この記事の手順1と、05章の3番目に当たる確認を、ソースの語を数える形でやった。トップ・解説記事・運営者ブログの記事・無料ツール・サイト紹介・解説記事の一覧の6ページを取得し、HTMLのコメントの中を除いて数えた。
| 数えたもの | 数えた範囲 | 結果 |
|---|---|---|
| pushState・replaceState | 6ページのHTML本体 | 6ページとも0件 |
| pushState・replaceState | 各ページが読み込む当サイトのJavaScript（1ページあたり9〜18本） | 6ページとも0件 |
URLを書き換える語が1件も見つからなかったので、画面の中身とURLを入れ替える作りではないと考えられる。公式のブログが書くとおりなら、当サイトの新しい指標は、従来の指標と同じか、ほぼ同じ数字になるはずである。
確かめられていないこと
この確認で分かったのは、当サイトの自前のコードに、URLを書き換える語が無いことだけである。次のことは確かめていない。
- 外部から読み込むスクリプトの中身。数えたのは当サイトのスクリプトだけである
- 実際にブラウザでリンクを押したとき、画面全体が切り替わるか
- CrUX Visでの、当サイトの新旧の数字の差
- 6ページ以外のページ（会員画面など）の作り
実務のヒント
「語が0件」は、「画面の書き換えをしていない」の証明ではない。数えた範囲の中で0件だった、ということである。数えた範囲を、結果と一緒に書く。この考え方は、「0件」に、探した数を書いていなかった ── 9種類で確かめた5日後、73種類で確かめ直したに書いた。
数字の確認は、CrUX Visで改めてやる
当サイトのCrUXの数字は、訪問者の数によっては出ないことがある。出るかどうかを含めて、05章の5〜8番目を、当サイトでもあとでやる。結果が出たら、この記事の末尾に、日付つきで追記する。ページの表示の測り方の見直しは、警告1,440件の中に、本物は2件だけだった ── 「報告は大げさ」は正しかったのに、記事ページは本当に遅かったにも書いている。
08 このテーマの、これまで
2020年5月 — Web Vitalsの取り組みが始まった
web.devのFAQには、Web Vitalsの取り組みを2020年5月に始めた、と書かれている。そのあと、SPAでのCore Web Vitalsの測り方は、最も多く質問を受けた話題のひとつだった、と同じFAQは書く。
2021年9月14日と2023年2月1日 — FAQと、ソフトナビゲーションの提案
web.devの「SPAのCore Web Vitals」のFAQは、2021年9月14日に公開された。ソフトナビゲーションを説明する文書は、2023年2月1日に公開されている。FAQの最終更新は2026年10月13日、ソフトナビゲーションの文書は2026年9月2日である。
2026年10月 — Chrome 151のAPIと、CrUXの実験的な指標
Chrome 151が、SPAのCore Web Vitalsを測る2つの新しいAPI（ソフトナビゲーションと、操作のあとの描画）を出した。そして2026年10月13日に、CrUXが、ソフトナビゲーション込みの実験的な3指標を公開した。FAQは、この実験的な指標を「2027年5月に実験の段階から卒業させることを目指す」と書いている。
INPが、保留の段階を通った前例
web.devの文書は、INPが2023年に実験的から保留の段階へ進んだことを例に挙げている。FIDを置き換える意図があった、と書かれている。今回の指標も、同じ道をたどるとは限らない。ブログは「フィードバックしだいで」と書き、毎月の変動もありうると説明している。
この記事の説明は、2026年10月16日に確認した時点のものである
この記事の説明は、2026年10月16日に、web.devのブログ、CrUXのリリースノート、CrUXの文書を開いて確認した時点のものである。11月の公開で、ナビゲーションの種類とFCPが加わったときに見直し、変わった点があれば01章に追記する。
現在の貴方のIPアドレス
このサイトで書いている人
