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

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

Barry Pollard

Yoav Weiss

2024 年 4 月更新: ソフトナビゲーションのオリジントレイルは 5 月 29 日に終了します。その後、Chrome チームがテストのフィードバックとこの API の次のステップについて検討します。Google は精度に関するいくつかの問題に対処するため、この機能の開発を進めるには別のオリジントライアルが必要になると考えています。それまでの間、デベロッパーは chrome://flags/#enable-experimental-web-platform-features を有効にすることで、引き続きこの機能を試すことができます。

Core Web Vitals イニシアチブでは、リリース以来、ウェブサイトの作成や読み込みの背後にある技術的詳細ではなく、ウェブサイトの実際のユーザーエクスペリエンスを測定することを目標としてきました。Core Web Vitals の 3 つの指標は、ユーザー中心の指標として作成されました。これらは既存の技術的指標（DOMContentLoaded や load など）を進化させたもので、ページのパフォーマンスに対するユーザーの感じ方とは無関係であることが多い時間を測定したものです。そのため、サイトのパフォーマンスが良好であれば、サイトの構築に使用されるテクノロジーがスコアに影響することはありません。

現実は理想的よりも常に少し複雑で、人気のあるシングルページアプリケーションアーキテクチャがウェブに関する主な指標の指標で完全にサポートされていることは一度もありません。このようなウェブアプリケーションは、ユーザーがサイト内を移動する際に個別のウェブページを読み込むのではなく、いわゆる「ソフトナビゲーション」を使用します。この場合、ページのコンテンツは JavaScript によって変更されます。このようなアプリケーションでは、URL を変更し、ブラウザの履歴に以前の URL を push することで、従来のウェブページアーキテクチャを装いながら、戻るボタンと進むボタンがユーザーの期待どおりに動作できるようにします。

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

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

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

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

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

一部のサイトでは、こうしたヒューリスティックが原因で誤検出（ユーザーは「ナビゲーション」が発生したと見なされない）や、偽陰性（これらの条件を満たしていないにもかかわらず「ナビゲーション」が発生したと見なす）が発生する可能性があります。ヒューリスティックについてのフィードバックは、ソフトナビゲーション仕様リポジトリまでお寄せください。

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

ソフトナビゲーションヒューリスティックを有効にすると（これについては次のセクションで詳しく説明します）、Chrome で一部のパフォーマンス指標を報告する方法が変更されます。

soft-navigation の PerformanceTiming イベントは、ソフトナビゲーションが検出されるたびに発生します。
パフォーマンス API は、soft-navigation PerformanceTiming イベントで出力される soft-navigation タイミングエントリへのアクセスを提供します。
First Paint（FP）、First Contentful Paint（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）を計算できるようになります。

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

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

サイト所有者様は、この機能を有効にした後に、次の点を考慮する必要があります。

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

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

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

Chrome のデフォルトではソフトナビゲーションは有効になっていませんが、Chrome 110 以降で明示的に有効にすると、試験運用版として利用できるようになります。

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

すべての訪問者にこの機能を有効にして影響を確認したい場合は、Chrome 117 からオリジントライアルを実施できます。トライアルに登録すると、オリジントライアルトークンを含むメタ要素を HTML または HTTP ヘッダーに含めることで有効にできます。詳細については、オリジントライアルのスタートガイドをご覧ください。

サイト所有者は、すべてのユーザーまたは一部のユーザーを対象に、オリジントライアルをページに追加できます。特に大部分のユーザーに対してオリジントライアルを有効にする場合は、上記の影響セクションに注意してください。特に、このオリジントライアルを有効にする場合は、指標のレポート方法がどのように変わるかについて注意してください。なお、CrUX はソフトナビゲーションの設定に関係なく、引き続き既存の方法で指標を報告するため、これらの影響の影響を受けません。また、オリジントライアルでは、Chrome の全ページの読み込みの 0.5%（14 日間の中央値）で試験運用版機能を有効にすることが制限されていますが、これは非常に大規模なサイトでのみ問題となります。

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

ソフトナビゲーションテストを有効にすると、通常どおり 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 イニシアチブの公式データセットとして測定およびレポートする項目に合わせて、「ハード」なページナビゲーションに基づいて引き続き Core Web Vitals を測定することをおすすめします。

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

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

`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';

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	現在、`web-vitals` ライブラリによって報告されるのは、そのページの最初の FCP のみです。
LCP	ソフトナビゲーションの開始時間に対する、次に大きい Contentful Paint の時間。前のナビゲーションに存在する既存のペイントは考慮されません。したがって、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 Issue Tracker で報告する必要があります。

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

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

ウェブページによっては、ユーザーにとっては、ソフトナビゲーションはページ全体の読み込みとほぼ同じであり、シングルページアプリケーションテクノロジーの使用は実装の詳細にすぎません。また、部分的な追加コンテンツのように見える場合もあります。

そのため、そのようなソフトナビゲーションを CrUX で個別に報告することや、特定のページやページグループについて Core Web Vitals を計算する際に重み付けすることを決定できます。ヒューリスティックの進化に伴い、部分的な負荷がかかったソフトナビゲーションを完全に除外することもできる可能性があります。

現在、チームはヒューリスティックな実装と技術的な実装に注力しており、この実装によってテストの成否を判断できるため、この点についてはまだ決定を下していません。

フィードバック

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

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

変更履歴

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

おわりに

ソフトナビゲーションのテストは、ウェブに関する主な指標のイニシアチブを進化させ、現在 Google の指標にない最新のウェブの共通パターンを測定するための優れたアプローチです。この試験運用はまだ初期の段階であり、まだやるべきことはまだたくさんありますが、これまでの進歩を幅広いウェブコミュニティが利用できるようにすることは、重要なステップです。このテストからフィードバックを収集することは、テストのもう一つの重要な部分です。この開発に関心をお持ちの方は、ぜひこの機会に API を改善し、今回のテストで測定できる対象を正確に反映するように API を形作ることを強くおすすめします。

謝辞

サムネイル画像（作成者: Jordan Madrid、出典: Unsplash）

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

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

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

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

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

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

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