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

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

Barry Pollard

Yoav Weiss

2024 年 8 月更新: 2 つ目のソフトナビゲーションのオリジントレイルは 5 月 29 日に終了しました。Chrome チームはテストに対するフィードバックを確認し、この API の次のステップを検討しています。精度に関する問題に対処するため、この機能をリリースする前に、別のオリジントライアルが必要であると判断いたしました。それまでは、chrome://flags/#enable-experimental-web-platform-features を有効にしてこの機能をテストできます。

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

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

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

Chrome チームはこの課題について長い間検討を重ねており、従来のマルチページアーキテクチャ（MPA）で実装されたウェブサイトの測定方法と同様に、「ソフトナビゲーション」の定義と、このソフトナビゲーションの Core Web Vitals の測定方法を標準化しようとしています。まだ初期段階ではありますが、すでに実装されている機能を、サイトがテストできるように幅広く提供できるようになりました。これにより、サイトはこれまでのアプローチについてフィードバックを提供できます。

ソフトナビゲーションとは何ですか？

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

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

サイトによっては、こうしたヒューリスティックにより、誤検出（ユーザーは「ナビゲーション」が発生したとは認識されない）や偽陰性（これらの基準を満たしていないにもかかわらず「ナビゲーション」が発生したとユーザーが考える）につながる可能性があります。ヒューリスティックに関するフィードバックは、ソフトナビゲーション仕様リポジトリで受け付けています。

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

ソフトナビゲーションのヒューリスティック（詳細は次のセクションで説明）を有効にすると、一部のパフォーマンス指標のレポート方法が変わります。

ソフトナビゲーションが検出されるたびに、soft-navigation PerformanceTiming イベントが送信されます。
performance API は、soft-navigation PerformanceTiming イベントによって出力される soft-navigation タイミングエントリにアクセスできます。
最初の描画（FP）、最初のコンテンツの描画（FCP）、Largest Contentful Paint（LCP）の指標はリセットされ、次回適切なタイミングで再送信されます。（注: FP と FCP は実装されていません）。
イベントが関連付けられているナビゲーションエントリに対応するパフォーマンスタイミング（first-paint、first-contentful-paint、largest-contentful-paint、first-input-delay、event、layout-shift）に navigationId 属性が追加され、Cumulative Layout Shift（CLS）とInteraction to Next Paint（INP）を計算できるようになります。

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

Chrome でソフトナビゲーションを有効にした場合、どのような影響がありますか？

この機能を有効にしたサイト所有者は、次のような変更を考慮する必要があります。

ソフトナビゲーションに対して、追加の FP、FCP、LCP イベントが再送信される場合があります。Chrome ユーザーエクスペリエンスレポート（CrUX）では、これらの追加値は無視されますが、サイトのリアルユーザー測定（RUM）モニタリングに影響する可能性があります。これらの測定に影響するかどうかご心配な場合は、RUM プロバイダにお問い合わせください。ソフトナビゲーションのウェブに関する主な指標の測定に関するセクションをご覧ください。
パフォーマンスエントリの新しい（および省略可能な）navigationID 属性は、これらのエントリを使用するアプリコードで検討することが必要になる場合があります。
この新しいモードは、Chromium ベースのブラウザでのみサポートされます。新しい指標の多くは Chromium ベースのブラウザでのみ利用できますが、一部の指標（FCP、LCP）は他のブラウザでも利用できます。また、Chromium ベースの最新バージョンのブラウザにアップグレードしていないユーザーもいます。ユーザーによっては、ソフトナビゲーションの指標を報告しない場合があります。
デフォルトで有効になっていない試験運用版の新機能であるため、サイトは、意図しない副作用がないことを確認するために、この機能をテストする必要があります。

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

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

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

デベロッパーは、chrome://flags/#enable-experimental-web-platform-features で試験運用版のウェブプラットフォームの機能フラグを有効にするか、Chrome の起動時に --enable-experimental-web-platform-features コマンドライン引数を使用すると、この機能を有効にできます。

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

ソフトナビゲーションテストが有効になると、指標は通常どおり 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});

observe メソッドには、Chrome でソフトナビゲーション機能を有効にすることに加えて、追加の includeSoftNavigationObservations フラグが必要です。パフォーマンスオブザーバーレベルでの明示的なオプトインは、ソフトナビゲーションの Core Web Vitals を測定する際に考慮すべき追加事項があるため、既存のパフォーマンスオブザーバーがこれらの追加エントリに驚かないようにするためです。

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

new PerformanceObserver((entryList) => {
  for (const entry of entryList.getEntries()) {
    const softNavEntry =
      performance.getEntriesByType('soft-navigation').filter(
        (navEntry) => 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: 'largest-contentful-paint', buffered: true, includeSoftNavigationObservations: true});

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

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

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

ソフトナビゲーションの FP、FCP、LCP では、新しいペイントのみが測定されます。これにより、LCP が異なる場合があります（たとえば、そのソフトナビゲーションのコールド読み込みからソフト読み込みに変わる場合など）。

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

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

TTFB を測定する方法

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

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

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

将来的には、どのリクエストがソフトナビゲーションの「ナビゲーションリクエスト」であるかをより正確に知る方法をサポートし、より正確な TTFB 測定値を取得できるようにする予定です。ただし、これは現在の試験運用版には含まれません。

新旧両方を測定する方法

この試験運用中は、Core Web Vitals イニシアチブの公式データセットとして CrUX が測定してレポートする内容と一致するように、「ハード」なページナビゲーションに基づいて、現在の方法で引き続き Core Web Vitals を測定することをおすすめします。

ソフトナビゲーションもこれらの測定に加えて測定する必要があります。これにより、今後の測定方法を確認したり、この実装が実際にどのように機能するかについて Chrome チームにフィードバックを提供したりできます。ご意見は、今後の API の開発に役立てさせていただきます。

両方を測定するには、ソフトナビゲーションモード中に発生する可能性のある新しいイベント（複数の FCP イベントや追加の LCP イベントなど）に注意し、適切なタイミングでこれらの指標を確定することで適切に処理する必要があります。また、ソフトナビゲーションにのみ適用される今後のイベントは無視する必要があります。

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

すべてのニュアンスを考慮する最も簡単な方法は、web-vitals JavaScript ライブラリを使用することです。このライブラリには、別の soft-navs branch でソフトナビゲーションの試験運用版サポートが含まれています（npm と unpkg でも利用できます）。これは次の方法で測定できます（必要に応じて 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	ソフトナビゲーションの開始時間からの、2 番目に大きいコンテンツペイントの時間。前のナビゲーションから存在するペイントは考慮されません。したがって、LCP は 0 より大きくなります。通常どおり、ユーザーが操作したとき、またはページがバックグラウンドになったときに報告され、そのときにのみ LCP を確定できます。
CLS	ナビゲーション時間の差の最大値。通常どおり、ページがバックグラウンドで動作している場合にのみ、CLS が確定されます。シフトがない場合、0 値が報告されます。
INP	ナビゲーション時間間の INP。通常どおり、INP の確定は、インタラクションが発生したとき、またはページがバックグラウンドに移動したときにのみ報告されます。インタラクションが発生しなかった場合は、0 値は報告されません。

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

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

このソフトナビゲーションテストはまさにそれで、テストです。Google は、このヒューリスティクスを評価し、ユーザーエクスペリエンスをより正確に反映しているかどうかを確認してから、Core Web Vitals イニシアチブに統合するかどうかを決定したいと考えています。Google はこのテストの可能性を非常に楽しみにしていますが、このテストが現在の測定値を置き換えるかどうか、またいつ置き換えられるかについては保証できません。

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

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

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

一部のウェブページでは、ユーザーにとってソフトナビゲーションはページ全体の読み込みとほぼ同じであり、シングルページアプリケーション技術の使用は実装の詳細にすぎません。コンテンツの一部を増やしたようなものもあります。

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

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

フィードバック

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

ソフトナビゲーションのヒューリスティクスと標準化。
これらのヒューリスティクスのChrome 実装に関する問題。
ウェブに関する指標に関する一般的なフィードバック（web-vitals-feedback@googlegrouops.com）

変更履歴

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

まとめ

ソフトナビゲーションのテストは、Core Web Vitals イニシアチブが進化していく中で、現在の指標にはない、最新のウェブの一般的なパターンを測定するためのエキサイティングなアプローチです。この試験運用はまだ初期段階にあり、多くの課題が残されていますが、これまでの進展を幅広いウェブコミュニティがテストできるようにすることは、重要なステップです。この試験運用で得られたフィードバックは、試験運用の重要な要素の 1 つです。この開発にご関心をお持ちの方は、この機会に API の開発にご協力いただき、Google が測定したいと考えている内容を API で測定できるようにしてください。

謝辞

Jordan Madrid 氏による Unsplash のサムネイル画像

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

ソフト ナビゲーションとは何ですか？

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

Chrome でソフト ナビゲーションを有効にした場合、どのような影響がありますか？

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

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

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