Google uses AI technology to translate content into your preferred language. AI translations can contain errors.

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

Barry Pollard

Michal Mocny

公開日: 2023 年 2 月 1 日、最終更新日: 2026 年 6 月 24 日

2026 年 6 月の更新: Chrome チームはリリース予定の通知を送信しました。この機能は Chrome 151 からフラグなしでリリースされる予定です。デベロッパーは、chrome://flags/#soft-navigation-heuristics を有効にすることで、それよりも前にこの機能を試すこともできます。

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

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

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

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

デベロッパーからのフィードバックに基づいてプロポーザルにいくつかの改善を加え、Chrome 151 からこの問題の解決に役立つ 2 つの新しいパフォーマンス API をリリースすることを目指しています。

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

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

ナビゲーションはユーザーアクションによって開始されます。
ナビゲーションの結果、ユーザーに表示される URL が変更されます。
インタラクションの結果としてペイントが可視化されます。

一部のサイトでは、この定義により、誤検出（ユーザーが「ナビゲーション」が発生したとは考えない場合）や誤検出（ユーザーが「ナビゲーション」が発生したと考える場合でも、この条件を満たしていない場合）が発生する可能性があります。フィードバックは、ソフトナビゲーションの仕様リポジトリでお待ちしています。

ソフトナビゲーションの DevTools サポート

トレースビューの DevTools のパフォーマンスパネルに、ソフトナビゲーションのサポートを追加しました。

パフォーマンスパネルのソフトナビゲーションマーカー。youtube.com のトレースが表示されています。

ソフトナビゲーションと LCP のマーカーが表示されます。どちらも * でマークされており、通常のハードナビゲーションエントリと区別できます。これはデフォルトで有効になっており、次に説明するパフォーマンス API の変更とは異なります。これは、サイトでソフトナビゲーションの検出が正しく機能するかどうかをすばやくテストする方法です。

現時点では、トレースビューにソフトナビゲーションと LCP のタイムスタンプのみが表示されます。その他の指標（LCP など）と [ライブ指標] ビューのサポートは、後日追加される予定です。

Chrome はウェブデベロッパー向けにソフトナビゲーションをどのように実装していますか？

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

ソフトナビゲーションが検出されるたびに、soft-navigation PerformanceTiming イベントが発行されます。
この soft-navigation エントリには、navigationId、name 属性の新しい URL、開始インタラクションの interactionId が含まれます。
コンテンツフルペイントを引き起こすインタラクションの後、1 つ以上の interaction-contentful-paint エントリが発行されます。これには、ソフトナビゲーションの Largest Contentful Paint（LCP）を測定するために使用できる largestContentfulPaint エントリが含まれます。
navigationId 属性は、各パフォーマンスタイミング（first-paint、first-contentful-paint、largest-contentful-paint、interaction-contentful-paint、first-input-delay、event、layout-shift）に追加されます。これは、イベントが発行されたナビゲーションエントリに対応します。これらのエントリがソフトナビゲーションにまたがる場合、エントリが発行されたタイミングに応じて、前の navigationId または次の navigationId が含まれることがあります。詳しくは、適切な URL に対して指標をレポートするをご覧ください。
soft-navigation には、そのナビゲーションの最大の interaction-contentful-paint エントリを取得する getLargestInteractionContentfulPaint() 関数が含まれます。これはそのナビゲーションの最初の LCP として使用され、そのインタラクションの interaction-contentful-paint エントリがさらに観測されると、その LCP が更新されます。これは、以前のオリジントライアルで利用可能だった largestInteractionContentfulPaint 属性に代わるものです。
URL の更新がペイント後まで行われない場合、ソフトナビゲーションの前に interaction-contentful-paint エントリが発生する可能性があります。このような場合、getLargestInteractionContentfulPaint() 関数を使用すると、ソフトナビゲーションの完了後に古いエントリをバッファリングして振り返る必要がなくなります。getLargestInteractionContentfulPaint() から返されるエントリは、出力された時点での最大の interaction-contentful-paint エントリの正確なコピーであることに注意してください。そのため、そのエントリはペイントが発生した時点の以前の navigationId を使用している可能性がありますが、これらのペイントは新しい navigationId に対して測定する必要があります。
soft-navigation エントリには、そのナビゲーションの FCP として paintTime と presentationTime も含まれます。
interaction-contentful-paint エントリは、その後の操作の後にも出力されますが、URL の LCP は、ソフトナビゲーション interactionId に一致する interaction-contentful-paint エントリに限定して、それらを除外する必要があります。また、その中の largestContentfulPaint プロパティに限定する必要があります。

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

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

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

soft-navigation エントリをモニタリングすることで、パフォーマンスエントリを各「ナビゲーション」に「スライス」できます。
CLS と INP の指標は、ページライフサイクル全体にわたって測定されるのではなく、すでに任意でスライスできますが、ソフトナビゲーション機能を使用すると、使用されている基盤となるテクノロジーに関係なく、このタイミングを標準化された指標で把握できます。
largest-contentful-paint エントリはインタラクションで確定されるため（ソフトナビゲーションを開始するために必要）、最初の「ハード」ナビゲーションの LCP を測定するためにのみ使用できます。つまり、ソフトナビゲーションが測定されてもこの値は変更されないため、最初のハードナビゲーションのページ読み込みの LCP をこれまでどおり測定できます。
インタラクションから出力される新しい interaction-contentful-paint エントリを使用すると、その中の largestContentfulPaint プロパティを確認することで、ソフトナビゲーションの LCP を測定できます。ただし、このエントリの使用方法については考慮すべき点があります。この記事では、それについて説明します。
すべてのユーザーがこのソフトナビゲーション機能をサポートしているわけではありません。特に、古い Chrome のバージョンや他のブラウザを使用しているユーザーはサポートしていません。一部のユーザーは、Core Web Vitals の指標を報告していても、ソフトナビゲーションに基づく指標を報告しない場合があります。

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

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

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

ソフトナビゲーション機能は、Chrome 151 でデフォルトで有効になる予定ですが、この機能を明示的に有効にすることで、それ以前にテストできます。

デベロッパーは、chrome://flags/#soft-navigation-heuristics でフラグをオンにすることで、この機能を有効にできます。または、Chrome の起動時に --enable-features=SoftNavigationHeuristics コマンドライン引数を使用して有効にすることもできます。chrome://flags/#enable-experimental-web-platform-features フラグを有効にすると、ソフトナビゲーションも有効になります。

一部のウェブサイト所有者は、オリジントライアルプロセスを通じて、リリース前にサイトでこの機能を有効にしています。API の形状は機能の開発を通じて変更されており、最終的にリリースされた機能は、ソフトナビゲーションの変更履歴で説明されているように、以前のオリジントライアルとは異なります。

ソフトナビゲーション 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 について新しいモニタリングを開始する必要があります。

適切な soft-navigation エントリの name 属性には、指標をレポートする新しい URL が含まれます。navigationId は、このナビゲーションの一意の参照になります（同じ URL がシングルページアプリケーションのライフサイクル中に複数回アクセスされる可能性があるため）。

これは各 soft-navigation エントリとして設定され、次の soft-navigation エントリが受信されるまで指標のレポートに使用されます。

警告: getEntriesByType を使用して指定された soft-navigation エントリを検索することはできますが、バッファリングされた最初のエントリ 50 個に制限されます。そのため、パフォーマンスオブザーバーを使用して受信したすべてのエントリをモニタリングする方法をおすすめします。また、50 回を超えるソフトナビゲーションを行う長時間実行アプリでは、この方法が必須となります。

`interaction-contentful-paint` の正しい URL を報告する

すべての interaction-contentful-paint エントリを navigationId を使用してマッピングし、その URL の LCP として報告する必要はないため、interaction-contentful-paint エントリから LCP を計算するには、追加の考慮事項が必要です。

1 つ目の問題は、URL の更新前にペイントが発生した場合、ソフトナビゲーションが発生する前に interaction-contentful-paint エントリが発行される可能性があることです。この場合、navigationId は古い URL のものになります。URL が先に更新された場合、ペイントはソフトナビゲーションを完了します。この場合、soft-navigation エントリが最初に発行され、interaction-contentful-paint には新しい URL が含まれます。
2 つ目の問題は、このパフォーマンス指標の範囲がソフトナビゲーションの LCP を超えて拡張されているため、新しいインタラクションに対して interaction-contentful-paint エントリが引き続き出力されることです。LCP では、ソフトナビゲーションの読み込みのペイントのみを考慮し、その後のインタラクションのペイントは考慮しません。

したがって、正しい URL を取得するには、navigationId ではなく interactionId を使用して interaction-contentful-paint エントリを soft-navigation-entries にマッピングする必要があります。これにより、古い navigationId を含むエントリが処理され、LCP の対象とすべきでない interaction-contentful-paint エントリがフィルタで除外されます。

また、soft-navigation entries が出力される前に発生する interaction-contentful-paint エントリをより簡単に処理するために、soft-navigation エントリの getLargestInteractionContentfulPaint() 関数も処理することを検討してください。

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

ソフトナビゲーションを含むすべてのパフォーマンスタイミングと、ウェブに関する主な指標の計算に使用されるエントリは、最初の「ハード」ページナビゲーションからの時間としてレポートされます。そのため、ソフトナビゲーションの開始時刻をソフトナビゲーションの読み込み指標の時刻（LCP など）から差し引いて、このソフトナビゲーションの時刻を基準にレポートする必要があります。

ナビゲーションの開始時刻も同様に、適切な soft-navigation エントリにマッピングしてその startTime を使用することで取得できます。

startTime は、ソフトナビゲーションを開始した最初の操作（ボタンのクリックなど）の時刻です。これは「ハードナビゲーション」とは多少異なります。ハードナビゲーションでは、「開始時間」は新しいページがブラウザに「コミット」され、一部のイベントハンドラコードが実行されたときです。ソフトナビゲーションの開始時間には、インタラクションの開始時間から測定するため、イベントハンドラコードも含まれます。

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

Core Web Vitals を測定するには、soft-navigation エントリをリッスンし、これらのエントリを受信したら指標をリセットします。FCP は presentationTime に基づいて出力でき、LCP は getLargestInteractionContentfulPaint() エントリに初期化できます。INP と CLS は、ページ読み込みの場合と同様に 0 に初期化する必要があります。

その後、LCP、INP、CLS を通常どおり測定してモニタリングできます（LCP に interaction-contentful-paint を使用して interactionId の一致を取得する場合を除く）。interactionId を使用して、前述のように URL のエントリに名前を付けることができます。

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

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

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

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

ソフトナビゲーションの LCP（interaction-contentful-paint から計算）では、新しいペイントのみが測定され、ナビゲーションを引き起こしたインタラクションに関連付けられたペイントのみが測定されます。これにより、ソフトナビゲーションのコールドスタートの読み込みからソフトロードまで、LCP が異なる可能性があります。

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

同様に、アニメーションは、ソフトナビゲーションとは無関係に、ページの一部を継続的に更新している可能性があります。その背景アニメーションによる新しいペイントは、新しいソフトナビゲーションの LCP の対象にはなりません。ただし、この URL からページが再読み込みされた場合は、LCP の対象となる可能性があります。

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

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

TTFB の測定方法

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

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

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

両方の方法で Core Web Vitals を測定する必要がありますか？

これらの新しい API は Chromium ベースのブラウザでのみ利用できますが、サイトではソフトナビゲーションでスライスし、ハードナビゲーションでスライスし続けることで、両方を測定したい場合があります。これにより、ブラウザ間での比較や過去の傾向の比較が可能になります。

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

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

指標はビーコンで送信され、分析のために 2 回保存される必要があります。

`web-vitals` ライブラリを使用してソフトナビゲーションの Core Web Vitals を測定する

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

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

function doTraditionalProcessing(callback) {
  ...
}

function doSoftNavProcessing(callback) {
  ...
}

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});

web-vitals ライブラリは、コールバックに提供されるエントリに navigationId と navigationURL の両方が含まれているため、前述のとおり、指標が正しい URL に対して報告されることも保証します。

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

指標	詳細
TTFB	0 として報告されます。
FCP	ソフトナビゲーションをトリガーしたインタラクションから、ソフトナビゲーションの開始時間までの First Contentful Paint の時間。前のナビゲーションから存在するペイントや、インタラクションに関連付けられていないペイントは考慮されません。
LCP	ソフトナビゲーションをトリガーしたインタラクションから、ソフトナビゲーションの開始時刻を基準とした Largest Contentful Paint の時刻。前のナビゲーションから存在する既存のペイントは、インタラクションに関連付けられていないため、考慮されません。通常どおり、ページ（またはソフトナビゲーション）から移動するまで更新を続けることができます。LCP を確定できるのは、そのときだけです。
CLS	ナビゲーション時間間のシフトの最大ウィンドウ。通常どおり、ページ（またはソフトナビゲーション）から移動するまで更新を続けることができます。CLS はその時点で確定します。
INP	ナビゲーション間の INP。通常どおり、ページ（またはソフトナビゲーション）から移動するまで更新を続けることができます。INP が確定するのは、そのときだけです。インタラクションがない場合、値 0 は報告されません。

警告: web-vitals の実装は現在も開発中であり、安定版リリースバージョンにはまだ含まれていません。web-vitals JavaScript ライブラリを使用している場合は、この点に注意し、ブランチの変更をモニタリングする必要があります。この変更は、機能のリリース後に安定版ブランチにマージされる予定です。

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

最終的な目標は、実際のユーザーエクスペリエンスとしてのパフォーマンスをより適切に測定する手段を提供することです。API のリリース後、すべてのツールで公開されるウェブに関する主な指標の測定に、これらの指標を含めることを目指しています。

API に関するウェブデベロッパーの皆様からのフィードバックや、API がユーザーエクスペリエンスをより正確に反映しているかどうかについてのご意見をお待ちしております。このフィードバックは、ソフトナビゲーションの GitHub リポジトリに投稿するのが最適です。ただし、Chrome の実装に関する個々のバグについては、Chrome の問題トラッカーで報告する必要があります。

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

この機能がリリースされたときに、CrUX でソフトナビゲーションがどのように報告されるかについても、まだ決定されていません。CrUX の変更については、詳細がわかり次第、こちらでお知らせします。

フィードバック

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

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

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

変更履歴

この API は開発中に、安定版 API よりも多くの変更が加えられました。詳しくは、ソフトナビゲーションの変更ログをご覧ください。

まとめ

ソフトナビゲーション機能は、Core Web Vitals イニシアチブが進化して、指標に欠けている最新のウェブの一般的なパターンを測定する可能性を示すエキサイティングなアプローチです。Google は、ウェブコミュニティ全体から多くのフィードバックを集めてきました。この開発に関心をお持ちの方は、この機会に API の形成にご協力いただき、この API で測定したい内容を確実に反映させることを強くおすすめします。

謝辞

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

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

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

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

ソフト ナビゲーションの DevTools サポート

Chrome はウェブ デベロッパー向けにソフト ナビゲーションをどのように実装していますか？

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

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

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

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

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

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

interaction-contentful-paint の正しい URL を報告する

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

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

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

TTFB の測定方法

両方の方法で Core Web Vitals を測定する必要がありますか？

web-vitals ライブラリを使用してソフト ナビゲーションの Core Web Vitals を測定する

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

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

フィードバック

変更履歴

まとめ

謝辞

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

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

ソフトナビゲーションの DevTools サポート

Chrome はウェブデベロッパー向けにソフトナビゲーションをどのように実装していますか？

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

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

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

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

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

`interaction-contentful-paint` の正しい URL を報告する

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

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

`web-vitals` ライブラリを使用してソフトナビゲーションの Core Web Vitals を測定する

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