このページは 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});

Chrome でソフトナビゲーション機能を有効にするに加えて、observe メソッドに追加の 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 の測定の一部になりますか？

このソフトナビゲーションのテストは、まさにテストです。ヒューリスティクスを評価し、ユーザーエクスペリエンスをより正確に反映しているかどうかを確認してから、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 で測定できるようにしてください。

謝辞

サムネイル画像: Unsplash の Jordan Madrid

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

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

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

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

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

ソフト ナビゲーションを測定する方法

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