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

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

Barry Pollard

Yoav Weiss

2024 年 8 月更新: 2 つ目の Soft Navigations のオリジントレイルは 5 月 29 日に終了しました。Chrome チームでテストに関するフィードバックを確認し、この API の次のステップを検討しています。Google は精度の問題に対処しており、機能を利用できるようにするには、別のオリジントライアルが必要になると考えています。それまでの間、デベロッパーは chrome://flags/#enable-experimental-web-platform-features を有効にしてこの機能を試すことができます。

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

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

多くの 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://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 の測定方法

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

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

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

将来的には、どのリクエストがソフトナビゲーションの「ナビゲーションリクエスト」であるかをより正確に把握する方法をサポートする可能性があります。より正確な TTFB 測定値が得られます現在のテストではそのようなことはありません。

新旧両方を測定する方法

このテスト中も、Core Web Vitals を「ハード」という基準に基づいて引き続き現在の方法で測定することをおすすめします。CrUX が Core Web Vitals イニシアチブの公式データセットとして測定、報告する内容に合わせてページナビゲーションを調整しました。

ソフトナビゲーションの測定は、これらに加えて測定する必要があります。これにより、これらのナビゲーションが今後どのように測定されるかを確認し、この実装の実際の仕組みについて Chrome チームにフィードバックを提供する機会を得ることができます。これにより、Chrome チームで今後の API の改善につなげることができます。

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

`web-vitals` ライブラリを使用して、ソフトナビゲーションの Core 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	ソフトナビゲーションの開始時間と比較して、次に大きい Contentful Paint の時刻。前のナビゲーションからの既存のペイントは考慮されません。したがって、LCP は >= 0 になります。通常どおり、ユーザーが操作を行ったとき、またはページがバックグラウンドになったときに報告され、そのときにのみ LCP を確定できます。
CLS	ナビゲーション時間間のシフトの最大ウィンドウ。通常どおり、ページがバックグラウンドで動作している場合にのみ、CLS を確定できます。シフトがない場合、値 0 が報告されます。
INP	ナビゲーション時間間の INP。通常どおり INP の確定は、インタラクションが発生したとき、またはページがバックグラウンドに移動したときにのみ報告されます。インタラクションがない場合、値は 0 として報告されません。

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

これらの変更は Core Web Vitals の測定結果に含まれますか？

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

ウェブデベロッパーのテストに関するフィードバック、使用されたヒューリスティック、エクスペリエンスがより正確に反映されていると感じているかどうか。フィードバックを送信するには、ソフトナビゲーションの GitHub リポジトリが最適ですが、Chrome の実装に関する個々のバグは Chrome Issue Tracker で報告してください。

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

このテストが成功した場合、CrUX でソフトナビゲーションが正確にどのように報告されるかも未定です。現在の「難しい」ものと同じように扱われるからといって、必ずしもそうとは限らないナビゲーションが処理されます。

一部のウェブページでは、ユーザーが懸念する限り、ソフトナビゲーションはページ全体の読み込みとほぼ同じであり、Single Page Application テクノロジーの使用は実装の詳細にすぎません。コンテンツの一部を増やしたようなものもあります。

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

チームはこのテストの成否を判断できるヒューリスティック技術の実装に重点を置いているため、これらの点については決定は行われていません。

フィードバック

現在、以下の場所でこの試験運用に関するフィードバックをお待ちしています。

ソフトナビゲーションのヒューリスティックと標準化。
そうしたヒューリスティックの Chrome の実装に関する問題。
ウェブに関する指標に関する一般的なフィードバックは、web-vitals-feedback@googlegrouops.com までお寄せください。

変更履歴

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

まとめ

ソフトナビゲーションのテストは、Core Web Vitals イニシアチブが、Google の指標にはない最新のウェブにおける一般的なパターンの測定へとどのように進化していくのかを示すエキサイティングなアプローチです。このテストはまだ初期段階であり、まだ改善の余地がたくさんありますが、これまでの進展をウェブコミュニティ全般に広めて実験的に展開することは、重要なステップです。このテストからフィードバックを収集することも、テストの重要な部分です。この開発に関心をお持ちの方は、この機会を利用して、Google が測定可能なものを代表する API を開発できるよう、ぜひこの機会をご利用ください。

謝辞

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

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

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

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

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

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

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

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