このページは Cloud Translation API によって翻訳されました。

ソフトナビゲーションの測定実験

Barry Pollard

Michal Mocny

公開日: 2023 年 2 月 1 日、最終更新日: 2025 年 9 月 15 日

2025 年 7 月の更新: 新しい Soft Navigations オリジントライアルが Chrome 139（7 月 30 日より安定版にリリース）から開始されます。デベロッパーは、Chrome 139 以降で chrome://flags/#soft-navigation-heuristics を有効にすることで、この機能を試すこともできます。

ウェブに関する主な指標の取り組みは、開始以来、ウェブサイトの作成方法や読み込み方法の技術的な詳細ではなく、ウェブサイトの実際のユーザーエクスペリエンスを測定することを目的としてきました。ウェブに関する主な指標の 3 つの指標は、ユーザー中心の指標として作成されました。これは、DOMContentLoaded や load などの既存の技術指標の進化版です。これらの技術指標は、ユーザーがページのパフォーマンスをどのように認識しているかとは無関係なタイミングを測定することがよくありました。そのため、サイトのパフォーマンスが良好であれば、サイトの構築に使用されたテクノロジーがスコアに影響することはありません。

実際には、理想どおりにはいかないことが多く、一般的なシングルページアプリケーションアーキテクチャは、ウェブに関する主な指標の指標で完全にサポートされたことはありません。ユーザーがサイト内を移動するたびに個別のウェブページを読み込むのではなく、これらのウェブアプリケーションでは「ソフトナビゲーション」と呼ばれる手法が使用されます。この手法では、JavaScript によってページコンテンツが変更されます。このようなアプリケーションでは、URL を変更し、ブラウザの履歴に前の URL をプッシュすることで、従来のウェブページのアーキテクチャの錯覚を維持し、ユーザーが期待する動作を [戻る] ボタンと [進む] ボタンで実現しています。

多くの JavaScript フレームワークがこのモデルを使用していますが、それぞれ異なる方法で使用しています。これはブラウザが従来「ページ」として認識していたものとは異なるため、測定は常に困難でした。現在のページでのインタラクションと、これを新しいページと見なす場合との境界線はどこにあるのでしょうか？

Chrome チームは、この課題についてしばらく検討を重ねてきました。そして、従来のマルチページアーキテクチャ（MPA）で実装されたウェブサイトが測定されるのと同様の方法で、「ソフトナビゲーション」の定義と、この定義に沿ってウェブに関する主な指標を測定する方法を標準化しようとしています。

前回のオリジントライアル以降、API の改善に尽力してまいりました。このたび、リリース前に最新のイテレーションを試していただき、アプローチに関するフィードバックをお寄せいただきたく、デベロッパーの皆様にお願いする次第です。

ソフトナビゲーションとは

ソフトナビゲーションの定義は次のとおりです。

ナビゲーションはユーザーアクションによって開始されます。
ナビゲーションの結果、ユーザーに表示される URL が変更され、履歴も変更されます。
ナビゲーションの結果、DOM が変更されます。

一部のサイトでは、これらのヒューリスティックによって偽陽性（ユーザーが「ナビゲーション」が発生したとは考えない）または偽陰性（ユーザーが「ナビゲーション」が発生したと考えるが、これらの条件を満たしていない）が発生する可能性があります。ヒューリスティックについては、ソフトナビゲーション仕様リポジトリでフィードバックをお待ちしています。

Chrome はソフトナビゲーションをどのように実装していますか？

ソフトナビゲーションヒューリスティックが有効になると（詳しくは次のセクションをご覧ください）、Chrome は一部のパフォーマンス指標のレポート方法を変更します。

ソフトナビゲーションが検出されるたびに、soft-navigation PerformanceTiming イベントが発行されます。
意味のあるペイントを引き起こすインタラクションの後、新しい interaction-contentful-paint が出力されます。これは、ソフトナビゲーションにまたがるペイントがある場合に、ソフトナビゲーションの Largest Contentful Paint（LCP）を測定するために使用できます。なお、このリセットの元の実装では largest-contentful-paint 指標がリセットされ、再送信が可能になっていましたが、簡素化と将来的な拡張性を考慮して、この代替アプローチを採用しました。
イベントに関連付けられたナビゲーションエントリに対応するパフォーマンスタイミング（first-paint、first-contentful-paint、largest-contentful-paint、interaction-contentful-paint、first-input-delay、event、layout-shift）ごとに navigationId 属性が追加され、Largest Contentful Paint（LCP）、Cumulative Layout Shift（CLS）、Interaction to Next Paint（INP）を計算して正しい URL に帰属させることができます。

これらの変更により、ウェブに関する主な指標と関連する診断指標の一部をページナビゲーションごとに測定できるようになりますが、考慮すべきニュアンスがいくつかあります。

Chrome でソフトナビゲーションを有効にするとどうなりますか？

この機能を有効にした後、サイト所有者が考慮する必要がある変更は次のとおりです。

CLS と INP の指標は、ページライフサイクルの期間全体で測定されるのではなく、ソフトナビゲーション URL でスライスされる場合があります。
largest-contentul-paint エントリはインタラクションで既に確定しているため、最初の「ハード」ナビゲーション LCP の測定にのみ使用されます。そのため、測定方法を変更するための追加のロジックは必要ありません。
新しい interaction-contentful-paint 指標はインタラクションから出力されます。これは、ソフトナビゲーションの LCP を測定するために使用できます。
ソフトナビゲーションを正しい URL に関連付けるには、パフォーマンスエントリの新しい navigationID 属性を、これらのエントリを使用するアプリケーションコードで考慮する必要がある場合があります。
すべてのユーザーがこのソフトナビゲーション API をサポートしているわけではありません。特に、古いバージョンの Chrome や他のブラウザを使用しているユーザーはサポートしていません。Core Web Vitals 指標を報告していても、ソフトナビゲーション指標を報告しないユーザーもいることに注意してください。
デフォルトで有効になっていない試験運用版の新機能であるため、サイトは意図しない副作用がないかテストする必要があります。

RUM プロバイダに、ソフトナビゲーションによるウェブに関する主な指標の測定をサポートしているかどうかを確認してください。多くの企業がこの新しい基準のテストを計画しており、以前の考慮事項を考慮する予定です。それまでの間、一部のプロバイダは独自のヒューリスティックに基づいて、パフォーマンス指標の測定を限定的に許可しています。

ソフトナビゲーションの指標を測定する方法については、ソフトナビゲーションごとの Core Web Vitals の測定セクションをご覧ください。

Chrome でソフトナビゲーションを有効にするにはどうすればよいですか？

ソフトナビゲーションは Chrome でデフォルトで有効になっていませんが、この機能を明示的に有効にすることで試験運用できます。

デベロッパーは、chrome://flags/#soft-navigation-heuristics でフラグをオンにすることで、この機能を有効にできます。「Enabled Advanced Paint Attribution (Eager Cached Pre-Paint Walk)」オプションは推奨オプションであり、まもなくデフォルトになります。また、Chrome の起動時に --enable-features=SoftNavigationHeuristics:mode/advanced_paint_attribution コマンドライン引数を使用して有効にすることもできます。

すべてのサイト訪問者に影響を確認してほしいウェブサイト向けに、Chrome 139 からオリジントライアルが実施されます。トライアルに登録し、HTML または HTTP ヘッダーにオリジントライアルトークンを含むメタ要素を追加することで、このトライアルを有効にできます。詳しくは、オリジントライアルを使ってみるをご覧ください。

サイト所有者は、すべてのユーザーまたは一部のユーザーに対して、ページに元の試用版を含めるかどうかを選択できます。この変更が指標のレポート方法にどのように影響するかについては、特にユーザーの大部分に対してこのオリジントライアルを有効にする場合は、前述の影響に関するセクションをご覧ください。なお、CrUX はこのソフトナビゲーションの設定に関係なく、既存の方法で指標をレポートし続けるため、これらの影響を受けません。オリジントライアルでは、14 日間の平均で Chrome のページ読み込みの最大 0.5% で試験運用版の機能を有効にできるという制限もありますが、これは非常に大規模なサイトでのみ問題になる可能性があります。

ソフトナビゲーション API のサポートを検出する機能

次のコードを使用して、API がサポートされているかどうかをテストできます。

if (PerformanceObserver.supportedEntryTypes.includes('soft-navigation')) {
  // Monitor Soft Navigations
}

supportedEntryTypes は初回使用時にフリーズされるため、ページに挿入されたオリジントライアルトークンによってソフトナビゲーションのサポートが動的に追加された場合、この機能が有効になる前の元の値が返されることがあります。

この場合、ソフトナビゲーションがデフォルトでサポートされておらず、この移行状態にある間は、次の代替手段を使用できます。

if ('SoftNavigationEntry' in window) {
  // Monitor Soft Navigations
}

ソフトナビゲーションを測定するにはどうすればよいですか？

ソフトナビゲーションの試験運用が有効になると、他の指標と同様に PerformanceObserver API を使用して指標がレポートされるようになります。ただし、これらの指標については、考慮すべき点がいくつかあります。

ソフトナビゲーションを報告する

PerformanceObserver を使用して、ソフトナビゲーションを観察できます。次のコードスニペットは、buffered オプションを使用して、このページの以前のソフトナビゲーションを含むソフトナビゲーションエントリをコンソールに記録する例です。

const observer = new PerformanceObserver(console.log);
observer.observe({ type: "soft-navigation", buffered: true });

これは、前のナビゲーションのライフサイクル全体にわたるページ指標を最終決定するために使用できます。

適切な URL に対して指標をレポートする

ソフトナビゲーションは発生後にしか確認できないため、一部の指標はこのイベントで確定し、前の URL について報告する必要があります。現在の URL には新しいページの更新された URL が反映されるためです。

適切な PerformanceEntry の navigationId 属性を使用して、イベントを正しい URL に関連付けることができます。これは、PerformanceEntry API で検索できます。

const softNavEntry =
  performance.getEntriesByType('soft-navigation').filter(
    (>entry) = entry.navigationId === navigationId
  )[0];
const hardNavEntry = performance.getEntriesByType('navigation')[0];
const navEntry = softNavEntry || hardNavEntry;
const pageUrl = navEntry?.name;

この pageUrl は、過去に使用した可能性のある現在の URL ではなく、正しい URL に対して指標をレポートするために使用する必要があります。

ソフトナビゲーションの `startTime` を取得する

ナビゲーションの開始時刻も同様の方法で取得できます。

const softNavEntry =
  performance.getEntriesByType('soft-navigation').filter(
    (>entry) = entry.navigationId === navigationId
  )[0];
const hardNavEntry = performance.getEntriesByType('navigation')[0];
const navEntry = softNavEntry || hardNavEntry;
const startTime = navEntry?.startTime;

startTime は、ソフトナビゲーションを開始した最初の操作（ボタンのクリックなど）の時刻です。

ソフトナビゲーションのタイミングを含め、すべてのパフォーマンスタイミングは、最初の「ハード」ページナビゲーションからの時間として報告されます。そのため、ソフトナビゲーションの読み込み指標（LCP など）の時間を、このソフトナビゲーションの時間に対して相対的に基準化するには、ソフトナビゲーションの開始時間が必要です。

ソフトナビゲーションごとに Core Web Vitals を測定する

ソフトナビゲーションの指標エントリを含めるには、パフォーマンスオブザーバーの observe 呼び出しに includeSoftNavigationObservations: true を含める必要があります。

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    console.log('Layout Shift time:', entry);
  }
}).observe({type: 'layout-shift', buffered: true, includeSoftNavigationObservations: true});

API の最新の変更により、includeSoftNavigationObservations フラグは不要になり、将来削除される可能性がありますが、現時点では、Chrome でソフトナビゲーション機能を有効にするだけでなく、パフォーマンスオブザーバーレベルで明示的にオプトインする必要があります。

タイミングは、元の「ハード」ナビゲーションの開始時刻を基準として返されます。たとえば、ソフトナビゲーションの LCP を計算するには、interaction-contentful-paint タイミングを取得し、前述のように適切なソフトナビゲーションの開始時間を差し引いて、ソフトナビゲーションを基準としたタイミングを取得する必要があります。たとえば、LCP の場合:

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const softNavEntry =
      performance.getEntriesByType('soft-navigation').filter(
        (nav>Entry) = navEntry.navigationId === entry.navigationId
      )[0];
    const hardNavEntry = performance.getEntriesByType('navigation')[0];
    const navEntry = softNavEntry || hardNavEntry;
    const startTime = navEntry?.startTime;
    console.log('LCP time:', entry.startTime - startTime);
  }
}).observe({type: 'interaction-contentful-paint', buffered: true, includeSoftNavigationObservations: true});

一部の指標は、ページのライフサイクル全体で測定されてきました。たとえば、LCP はインタラクションが発生するまで変化する可能性があります。CLS と INP は、ページから移動するまで更新できます。そのため、新しいソフトナビゲーションが発生するたびに、各「ナビゲーション」（元のナビゲーションを含む）で前のページの指標を確定する必要がある場合があります。つまり、最初の「ハード」ナビゲーション指標は通常よりも早く確定する可能性があります。

同様に、これらの長期的な指標の新しいソフトナビゲーションの指標の測定を開始するときに、指標を「リセット」または「再初期化」して、以前の「ページ」に設定された値を記憶しない新しい指標として扱う必要があります。

ナビゲーション間で同じコンテンツはどのように扱うべきですか？

ソフトナビゲーションの LCP（interaction-contentful-paint から計算）は、新しいペイントのみを測定します。これにより、たとえば、ソフトナビゲーションのコールドロードからソフトロードまで、LCP が異なる可能性があります。

たとえば、LCP 要素である大きなバナー画像を含むページで、その下のテキストがソフトナビゲーションごとに変化する場合を考えてみましょう。ページの初回読み込みでは、バナー画像が LCP 要素としてフラグ設定され、それに基づいて LCP のタイミングが決定されます。以降のソフトナビゲーションでは、その下に表示されるテキストがソフトナビゲーション後にペイントされる最大の要素となり、新しい LCP 要素となります。ただし、ソフトナビゲーション URL へのディープリンクで新しいページが読み込まれた場合、バナー画像は新しいペイントになるため、LCP 要素と見なされる可能性があります。

この例に示すように、ソフトナビゲーションの LCP 要素は、ページの読み込み方法によって異なるレポートが生成されることがあります。これは、ページの下部にあるアンカーリンクを使用してページを読み込むと、LCP 要素が異なる場合があるのと同様です。

ヒント:: RUM データを収集する際は、ソフトナビゲーションの LCP（INP と CLS も同様）を異なる特性を持つ可能性があるため、異なる方法でセグメント化できるように navigationType を含める必要があります。

TTFB の測定方法

従来のページ読み込みの Time to First Byte（TTFB）は、元のリクエストの最初のバイトが返されるまでの時間を表します。

ソフトナビゲーションの場合、これはより難しい問題です。新しいページに対する最初のリクエストを測定する必要がありますか？すべてのコンテンツがアプリにすでに存在し、追加のリクエストがない場合はどうなりますか？プリフェッチで事前にリクエストが行われた場合はどうなりますか？ユーザーから見てソフトナビゲーションに関係のないリクエスト（アナリティクスリクエストなど）の場合はどうなりますか？

より簡単な方法は、ソフトナビゲーションの TTFB を 0 としてレポートすることです。これは、バックフォワードキャッシュの復元でおすすめしている方法と同様です。これは、web-vitals ライブラリがソフトナビゲーションに使用するメソッドです。

今後、どのリクエストがソフトナビゲーションの「ナビゲーションリクエスト」であるかをより正確に把握する方法をサポートし、TTFB をより正確に測定できるようになる可能性があります。ただし、これは現在の実装には含まれていません。

古いユーザーと新しいユーザーの両方を測定するにはどうすればよいですか？

このテスト期間中は、CrUX がウェブに関する主な指標イニシアチブの公式データセットとして測定し、レポートする内容と一致するように、「ハード」ページナビゲーションに基づいて、現在の方法でウェブに関する主な指標を測定し続けることをおすすめします。

ソフトナビゲーションも測定して、将来的にどのように測定される可能性があるかを確認し、この実装が実際にどのように機能するかについて Chrome チームにフィードバックする機会を得る必要があります。このフィードバックは、あなたと Chrome チームが今後 API を開発していくうえで役立ちます。

LCP の場合、古い方法では largest-contentful-paint エントリのみを考慮し、新しい方法では largest-contentful-paint エントリと interaction-contentful-paint エントリの両方を考慮します。

CLS と INP の場合、これは、古い方法と同様にページライフサイクル全体で測定し、ソフトナビゲーションでタイムラインを個別にスライスして、新しい CLS と INP の値を個別に測定することを意味します。

`web-vitals` ライブラリを使用してソフトナビゲーションのウェブに関する主な指標を測定する

すべてのニュアンスを考慮する最も簡単な方法は、別の soft-navs branch（npm と unpkg でも利用可能）でソフトナビゲーションの試験運用サポートがある web-vitals JavaScript ライブラリを使用することです。これは次のように測定できます（doTraditionalProcessing と doSoftNavProcessing は適宜置き換えてください）。

import {
  onTTFB,
  onFCP,
  onLCP,
  onCLS,
  onINP,
} from 'https://unpkg.com/web-vitals@soft-navs/dist/web-vitals.js?module';

onTTFB(doTraditionalProcessing);
onFCP(doTraditionalProcessing);
onLCP(doTraditionalProcessing);
onCLS(doTraditionalProcessing);
onINP(doTraditionalProcessing);

onTTFB(doSoftNavProcessing, {reportSoftNavs: true});
onFCP(doSoftNavProcessing, {reportSoftNavs: true});
onLCP(doSoftNavProcessing, {reportSoftNavs: true});
onCLS(doSoftNavProcessing, {reportSoftNavs: true});
onINP(doSoftNavProcessing, {reportSoftNavs: true});

指標が正しい URL に対してレポートされていることを確認します（前述のとおり）。

web-vitals ライブラリは、ソフトナビゲーションについて次の指標をレポートします。

指標	詳細
TTFB	0 として報告されます。
FCP	ページで最初に FCP が発生したときのみがレポートされます。
LCP	ソフトナビゲーションの開始時間に対する、次の Largest Contentful Paint の時間。前のナビゲーションから存在する既存のペイントは考慮されません。したがって、LCP は 0 以上になります。通常、LCP はインタラクション時またはページがバックグラウンドに移行したときに報告されます。これは、その時点で LCP が確定されるためです。
CLS	ナビゲーション間のシフトの最大ウィンドウ。通常、これはページがバックグラウンドに移行したときです。CLS はそのときにのみ確定できます。シフトがない場合は、値 0 が報告されます。
INP	ナビゲーション間の INP。通常、INP はインタラクション時またはページがバックグラウンドに移行したときにレポートされます。これは、その時点でしか INP を確定できないためです。インタラクションがない場合、値 0 はレポートされません。

警告: web-vitals の実装は現在開発中であり、変更される可能性があります。新しい変更は、そのブランチに公開されます。ソフトナビゲーションでの FCP はサポートされていません。これは、Chrome での基盤となる作業がさらに必要になるためです。web-vitals JavaScript ライブラリを本番環境のサイトで使用する場合は、この点に注意し、ローカルコピーを作成してそのバージョンをテストし、ブランチの変更をモニタリングする必要があります。

これらの変更は Core Web Vitals の測定の一部になりますか？

このソフトナビゲーションのテストは、まさにテストです。Google は、このヒューリスティクスを評価し、Core Web Vitals イニシアチブに統合するかどうかを決定する前に、ユーザーエクスペリエンスをより正確に反映しているかどうかを確認したいと考えています。このテストの可能性に期待していますが、このテストが現在の測定に取って代わるかどうか、またいつ取って代わるかについては保証いたしかねます。

Google は、このテスト、使用されたヒューリスティック、エクスペリエンスがより正確に反映されているかどうかについて、ウェブデベロッパーの皆様からのフィードバックを重視しています。フィードバックは、ソフトナビゲーションの GitHub リポジトリに投稿するのが最適です。ただし、Chrome の実装に関する個々のバグについては、Chrome の問題トラッカーで報告してください。

CrUX でソフトナビゲーションはどのように報告されますか？

このテストが成功した場合に、CrUX でソフトナビゲーションがどのように報告されるかについても、まだ決定されていません。現在の「ハード」ナビゲーションと同じように扱われるとは限りません。

一部のウェブページでは、ユーザーから見るとソフトナビゲーションはページ全体の読み込みとほぼ同じで、シングルページアプリケーション技術の使用は単なる実装の詳細です。他のアプリでは、追加コンテンツの部分的な読み込みに近い場合があります。

そのため、CrUX でこれらのソフトナビゲーションを個別にレポートするか、特定のページまたはページグループの Core Web Vitals を計算する際に重み付けすることを検討しています。ヒューリスティックの進化に伴い、部分読み込みのソフトナビゲーションを完全に除外できるようになる可能性もあります。

チームは、このテストの成功を判断するためのヒューリスティックと技術的な実装に注力しているため、これらの点についてはまだ決定されていません。

フィードバック

このテストに関するフィードバックは、以下の場所で積極的に募集しています。

API に関するフィードバックは、GitHub の問題として報告してください。
Chromium 実装のバグは、まだ既知の問題でない場合は、Chrome の問題トラッカーで報告する必要があります。
ウェブバイタルの一般的なフィードバックは、web-vitals-feedback@googlegroups.com までお寄せください。

どちらにすべきか迷った場合は、あまり心配しないでください。どちらの場所でもフィードバックをお寄せいただければ、両方の場所で問題をトリアージし、正しい場所に問題をリダイレクトいたします。

変更履歴

この API は試験運用版であるため、安定版 API よりも多くの変更が加えられています。詳しくは、ソフトナビゲーションヒューリスティックの変更ログをご覧ください。

まとめ

ソフトナビゲーションの試験運用は、Core Web Vitals の取り組みが進化して、指標に欠けている最新のウェブの一般的なパターンを測定するようになる可能性を示す、エキサイティングなアプローチです。このテストはまだ初期段階であり、やるべきことはたくさんありますが、これまでの進捗状況をより広範なウェブコミュニティに公開してテストしてもらうことは、重要な一歩です。このテストからフィードバックを収集することも、テストの重要な部分です。この開発に関心をお持ちの方は、ぜひこの機会に API の形成にご協力ください。この API で測定したい内容を反映させることができます。

謝辞

サムネイル画像: Jordan Madrid（Unsplash）

この取り組みは、Yoav Weiss 氏が Google に在籍していたときに開始した取り組みの継続です。この API の開発に尽力してくれた Yoav に感謝します。

ソフト ナビゲーションの測定実験 コレクションでコンテンツを整理 必要に応じて、コンテンツの保存と分類を行います。

ソフト ナビゲーションとは

Chrome はソフト ナビゲーションをどのように実装していますか？

Chrome でソフト ナビゲーションを有効にするとどうなりますか？

Chrome でソフト ナビゲーションを有効にするにはどうすればよいですか？

ソフト ナビゲーション API のサポートを検出する機能

ソフト ナビゲーションを測定するにはどうすればよいですか？

ソフト ナビゲーションを報告する

適切な URL に対して指標をレポートする

ソフト ナビゲーションの startTime を取得する

ソフト ナビゲーションごとに Core Web Vitals を測定する

ナビゲーション間で同じコンテンツはどのように扱うべきですか？

TTFB の測定方法

古いユーザーと新しいユーザーの両方を測定するにはどうすればよいですか？

web-vitals ライブラリを使用してソフト ナビゲーションのウェブに関する主な指標を測定する

これらの変更は Core Web Vitals の測定の一部になりますか？

CrUX でソフト ナビゲーションはどのように報告されますか？

フィードバック

変更履歴

まとめ

謝辞

ソフトナビゲーションの測定実験

ソフトナビゲーションとは

Chrome はソフトナビゲーションをどのように実装していますか？

Chrome でソフトナビゲーションを有効にするとどうなりますか？

Chrome でソフトナビゲーションを有効にするにはどうすればよいですか？

ソフトナビゲーション API のサポートを検出する機能

ソフトナビゲーションを測定するにはどうすればよいですか？

ソフトナビゲーションを報告する

ソフトナビゲーションの `startTime` を取得する

ソフトナビゲーションごとに Core Web Vitals を測定する

`web-vitals` ライブラリを使用してソフトナビゲーションのウェブに関する主な指標を測定する

CrUX でソフトナビゲーションはどのように報告されますか？