公開日: 2023 年 2 月 1 日、最終更新日: 2026 年 3 月 30 日
Core Web Vitals の取り組みは、開始以来、ウェブサイトの作成方法や読み込み方法の技術的な詳細ではなく、ウェブサイトの実際のユーザー エクスペリエンスを測定することを目的としてきました。Core Web Vitals の 3 つの指標は、ユーザー中心の指標として作成されました。これは、DOMContentLoaded や load などの既存の技術指標の進化版です。これらの技術指標は、ユーザーがページのパフォーマンスをどのように認識しているかとは無関係なタイミングを測定することがよくありました。そのため、サイトのパフォーマンスが良好であれば、サイトの構築に使用されたテクノロジーがスコアに影響することはありません。
現実は理想よりも少し複雑で、一般的なシングルページ アプリケーション アーキテクチャは、Core Web Vitals で完全にサポートされたことはありません。ユーザーがサイト内を移動するたびに個別のウェブページを読み込むのではなく、これらのウェブ アプリケーションでは「ソフト ナビゲーション」と呼ばれる手法が使用されます。この手法では、JavaScript によってページ コンテンツが変更されます。このようなアプリケーションでは、URL を変更し、ブラウザの履歴に前の URL をプッシュすることで、従来のウェブページのアーキテクチャの錯覚を維持し、ユーザーが期待する動作を [戻る] ボタンと [進む] ボタンで実現しています。
多くの JavaScript フレームワークがこのモデルを使用していますが、それぞれ異なる方法で使用しています。これはブラウザが従来「ページ」として認識していたものとは異なるため、測定は常に困難でした。現在のページでのインタラクションと、新しいページでのインタラクションの境界線はどこにあるのでしょうか？
Chrome チームは、この課題についてしばらく検討を重ねてきました。そして、従来のマルチページ アーキテクチャ（MPA）で実装されたウェブサイトと同様の方法で、「ソフト ナビゲーション」の定義と、その定義に沿って Core Web Vitals を測定する方法を標準化しようとしています。
前回のオリジン トライアルでデベロッパーから寄せられたフィードバックに基づき、API にいくつかの改善を加えました。このリリースに先立ち、デベロッパーの皆様に最新のイテレーションをお試しいただき、アプローチに関するフィードバックをお寄せいただきたいと考えています。これらのイテレーションで API がどこに落ち着いたかについては、かなり確信を持っており、この最新のオリジン トライアルに関するフィードバックを踏まえて、今年後半に API をリリースすることを目指しています。
ソフト ナビゲーションとは
ソフト ナビゲーションの定義は次のとおりです。
- ナビゲーションはユーザー アクションによって開始されます。
- ナビゲーションの結果、ユーザーに表示される URL が変更されます。
- インタラクションの結果としてペイントが実行される。
一部のサイトでは、これらのヒューリスティックによって誤検出（ユーザーが「ナビゲーション」が発生したとは考えない）や誤検出（ユーザーが「ナビゲーション」が発生したと考えるが、これらの条件を満たしていない）が発生する可能性があります。ヒューリスティクスについては、ソフト ナビゲーションの仕様リポジトリでフィードバックをお待ちしています。
ソフト ナビゲーションの DevTools サポート
トレースビューの DevTools のパフォーマンス パネルに、ソフト ナビゲーションのサポートを追加しました。
ソフト ナビゲーションと LCP のマーカーが表示されます。どちらも * でマークされており、通常のハード ナビゲーション エントリと区別できます。これはデフォルトで有効になっており、次に説明するパフォーマンス API の変更とは別のものです。これは、ソフト ナビゲーションのテストがサイトで正しく機能するかどうかをすばやくテストする方法です。
現時点では、トレースビューにソフト ナビゲーションと LCP のタイムスタンプのみが表示されます。他の指標（LCP など）と [ライブ指標] ビューのサポートは、後で追加されます。
Chrome はウェブ デベロッパー向けにソフト ナビゲーションをどのように実装していますか？
ソフト ナビゲーション ヒューリスティックが有効になると（詳しくは次のセクションをご覧ください）、Chrome は一部のパフォーマンス指標のレポート方法を変更します。
- ソフト ナビゲーションが検出されるたびに、
soft-navigationPerformanceTimingイベントが発行されます。 - この
soft-navigationエントリには、navigationId、name属性の新しい URL、開始インタラクションのinteractionIdが含まれます。 - コンテンツフル ペイントを引き起こすインタラクションの後、1 つ以上の
interaction-contentful-paintエントリが発行されます。これは、インタラクションがソフト ナビゲーションを生成したときに、ソフト ナビゲーションの Largest Contentful Paint（LCP）を測定するために使用できます。 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エントリを含むlargestInteractionContentfulPaintエントリが含まれます。この値は、そのナビゲーションの初期 LCP として使用できます。その後、そのインタラクションのinteraction-contentful-paintエントリがさらに観測されると、その LCP が更新されます。- 場合によっては、ソフト ナビゲーションが行われる前に
interaction-contentful-paintエントリが発生することがあります（URL の更新がそれらのペイントの後まで行われない場合）。このような場合、最大のlargestInteractionContentfulPaintエントリは、古いエントリをバッファリングして振り返る必要がなくなります。largestInteractionContentfulPaintは最大のinteraction-contentful-paintエントリの正確なコピーであるため、そのエントリはペイントが発生した時点の以前のnavigationIdを使用していますが、これらのペイントは新しいnavigationIdに対して測定する必要があります。 soft-navigationエントリには、そのナビゲーションの FCP としてpaintTimeとpresentationTimeも含まれます。interaction-contentful-paintエントリは、その後のインタラクションの後にも出力されますが、URL の LCP は、ソフト ナビゲーションinteractionIdに一致するinteraction-contentful-paintエントリに限定して、これらを除外する必要があります。
これらの変更により、Core Web Vitals と関連する診断指標の一部をページ ナビゲーションごとに測定できるようになりますが、考慮すべきニュアンスがいくつかあります。
Chrome でソフト ナビゲーションを有効にするとどうなりますか？
この機能を有効にした後、サイト所有者が考慮する必要がある変更は次のとおりです。
soft-navigationエントリをモニタリングすることで、パフォーマンス エントリを各「ナビゲーション」に「スライス」できます。- CLS と INP の指標は、ページ ライフサイクル全体にわたって測定されるのではなく、すでに任意のスライスが可能ですが、Soft Navigation API は、使用されている基盤となるテクノロジーに関係なく、このタイミングを標準化された指標で示します。
largest-contentful-paintエントリはインタラクションで確定されるため（ソフト ナビゲーションを開始するために必要）、最初の「ハード」ナビゲーションの LCP を測定するためにのみ使用できます。つまり、ソフト ナビゲーションが測定されてもこの値は変更されないため、初期のハード ナビゲーションのページ読み込みの LCP はこれまでどおり測定できます。- インタラクションから出力される新しい
interaction-contentful-paintエントリを使用すると、ソフト ナビゲーションの LCP を測定できますが、このエントリの使用方法については考慮すべき点があります。この記事では、それについて説明します。 - このソフト ナビゲーション API は、特に古い Chrome バージョンや他のブラウザを使用しているユーザーには対応していない場合があります。一部のユーザーは、Core Web Vitals の指標を報告していても、ソフト ナビゲーションに基づく指標を報告しない場合があります。
- デフォルトで有効になっていない試験運用版の新機能であるため、サイトは意図しない副作用がないかテストする必要があります。
RUM プロバイダに、ソフト ナビゲーションによる Core Web Vitals の測定をサポートしているかどうかを確認してください。多くの企業がこの新しい基準のテストを計画しており、以前の考慮事項を考慮する予定です。それまでの間、一部のプロバイダは独自のヒューリスティックに基づいて、パフォーマンス指標の測定を限定的に許可しています。
ソフト ナビゲーションの指標を測定する方法について詳しくは、ソフト ナビゲーションごとの Core Web Vitals の測定セクションをご覧ください。
Chrome でソフト ナビゲーションを有効にするにはどうすればよいですか？
ソフト ナビゲーションは Chrome でデフォルトで有効になっていませんが、この機能を明示的に有効にすることで試験運用できます。
デベロッパーは、chrome://flags/#soft-navigation-heuristics でフラグをオンにすることで、この機能を有効にできます。または、Chrome の起動時に --enable-features=SoftNavigationHeuristics コマンドライン引数を使用して有効にすることもできます。chrome://flags/#enable-experimental-web-platform-features フラグを有効にすると、ソフト ナビゲーションも有効になります。
すべてのユーザーに影響を確認してほしいウェブサイト向けに、Chrome 147 からオリジン トライアルが実施されます。トライアルに登録し、HTML または HTTP ヘッダーにオリジン トライアル トークンを含むメタ要素を追加することで、この機能を有効にできます。詳しくは、オリジン トライアルを始めるをご覧ください。
サイト所有者は、すべてのユーザーまたは一部のユーザーに対して、ページにオリジン トライアルを含めるかどうかを選択できます。この変更が指標のレポート方法にどのように影響するかについては、特にユーザーの大部分に対してこのオリジン トライアルを有効にする場合は、前述の影響に関するセクションをご覧ください。なお、CrUX はこのソフト ナビゲーションの設定に関係なく、既存の方法で指標をレポートし続けるため、これらの影響を受けません。また、オリジン トライアルでは、試験運用版の機能を有効にできるのは、すべての Chrome ページ読み込みの最大 0.5%（14 日間の平均値）に制限されていますが、これは非常に大規模なサイトでのみ問題になります。
ソフト ナビゲーション 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 に対して指標をレポートする
ソフト ナビゲーションが検出されたら、前のページの Core Web Vitals を確定して前の URL についてレポートし、新しい URL について新しいモニタリングを開始する必要があります。
適切な soft-navigation エントリの name 属性には、指標をレポートする新しい URL が含まれます。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;
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 エントリの largestInteractionContentfulPaint エントリも処理することを検討してください。
ソフト ナビゲーションの startTime を取得する
ソフト ナビゲーションを含むすべてのパフォーマンス タイミングと、ウェブに関する主な指標の計算に使用されるエントリは、最初の「ハード」ページ ナビゲーションからの時間としてレポートされます。そのため、ソフト ナビゲーションの開始時刻をソフト ナビゲーションの読み込み指標の時刻（LCP など）から差し引いて、ソフト ナビゲーションの時刻を基準とした値をレポートする必要があります。
ナビゲーションの開始時刻も同様に、適切な soft-navigation エントリにマッピングしてその startTime を使用することで取得できます。
startTime は、ソフト ナビゲーションを開始した最初の操作（ボタンのクリックなど）の時刻です。これは「ハード ナビゲーション」とは多少異なります。ハード ナビゲーションでは、新しいページがブラウザに「コミット」され、一部のイベント ハンドラ コードが実行されたときが「開始時間」となります。ソフト ナビゲーションの開始時間には、インタラクションの開始時間から測定するため、イベント ハンドラのコードも含まれます。
ソフト ナビゲーションごとに Core Web Vitals を測定する
Core Web Vitals を測定するには、soft-navigation エントリをリッスンし、これらのエントリを受信したら指標をリセットします。FCP は presentationTime に基づいて出力でき、LCP は largestInteractionContentfulPaint に初期化できます。INP と CLS は、ページ読み込みの場合と同様に 0 に初期化する必要があります。
その後、LCP、INP、CLS を通常どおり測定してモニタリングできます（LCP に interaction-contentful-paint を使用すると interactionId が一致するという例外はあります）。interactionId と navigationId を使用して、前述のとおり、URL へのエントリに名前を付けることができます。
タイミングは、元の「ハード」ナビゲーションの開始時刻を基準として返されます。たとえば、ソフト ナビゲーションの LCP を計算するには、interaction-contentful-paint のタイミングを取得し、前述のように適切なソフト ナビゲーションの開始時間を差し引いて、ソフト ナビゲーションを基準としたタイミングを取得する必要があります。
一部の指標は、ページのライフサイクル全体で測定されてきました。たとえば、LCP はインタラクションが発生するまで変化する可能性があります。CLS と INP は、操作の有無にかかわらず、ページから移動するまで更新できます。そのため、新しいソフト ナビゲーションが発生するたびに、以前のナビゲーションの指標を確定する必要があります。つまり、ソフト ナビゲーションで Core Web Vitals を測定する場合、初期の「ハード」ナビゲーション指標が通常よりも早く確定する可能性があります。
同様に、これらの長期的な指標の新しいソフト ナビゲーションの指標の測定を開始するときに、指標を「リセット」または「再初期化」して、以前の「ページ」に設定された値を記憶しない新しい指標として扱う必要があります。つまり、「最大」のペイント、Interaction to Next Paint、レイアウト シフトの認識がリセットされ、最初から測定できるようになります。
ナビゲーション間で同じコンテンツはどのように扱うべきですか？
ソフト ナビゲーションの LCP（interaction-contentful-paint から計算）では、新しいペイントのみが測定され、ナビゲーションを引き起こしたインタラクションに関連付けられたペイントのみが測定されます。これにより、たとえば、ソフト ナビゲーションのコールド スタートの読み込みからソフトロードまで、LCP が異なる可能性があります。
たとえば、LCP 要素である大きなバナー画像を含むページで、その下のテキストがソフト ナビゲーションごとに変化する場合を考えてみましょう。ページの初回読み込み時に、バナー画像が LCP 要素としてフラグ設定され、それに基づいて LCP のタイミングが決定されます。以降のソフト ナビゲーションでは、その下に表示されるテキストがソフト ナビゲーション後にペイントされる最大の要素となり、新しい LCP 要素となります。ただし、ソフト ナビゲーション URL へのディープリンクでページが読み込まれた場合、バナー画像は新しいペイントとなるため、LCP 要素と見なされる可能性があります。
同様に、アニメーションは、ソフト ナビゲーションとは無関係に、ページの一部を継続的に更新している可能性があります。その背景アニメーションによる新しいペイントは、新しいソフト ナビゲーションの LCP の対象にはなりません。ただし、この URL からページが再読み込みされた場合は、LCP の対象となる可能性があります。
これらの例に示すように、ソフト ナビゲーションの LCP 要素は、ページの読み込み方法によって異なるレポートが生成されることがあります。これは、ページの下部にあるアンカーリンクを使用してページを読み込むと、ハード ナビゲーションの LCP 要素が異なる結果になる可能性があるのと同様です。
TTFB の測定方法
従来のページ読み込みの Time to First Byte（TTFB）は、元のリクエストの最初のバイトが返されるまでの時間を表します。
ソフト ナビゲーションの場合、これはより難しい問題です。新しいページに対する最初のリクエストを測定する必要がありますか？すべてのコンテンツがアプリにすでに存在し、追加のリクエストがない場合はどうなりますか？プリフェッチで事前にリクエストが行われた場合はどうなりますか？ユーザーの視点から見て、ソフト ナビゲーションとは関係のないリクエスト（アナリティクス リクエストなど）の場合はどうなりますか？
より簡単な方法は、ソフト ナビゲーションの TTFB を 0 としてレポートすることです。これは、バックフォワード キャッシュの復元でおすすめしている方法と同様です。これは、web-vitals ライブラリがソフト ナビゲーションに使用しているメソッドであり、現時点ではこの指標に推奨されるメソッドです。
両方の方法で Core Web Vitals を測定する必要がありますか？
このテスト期間中は、新しい実装に問題が生じたり、最終的なリリース前に変更されたりする可能性があるため、引き続き現在の方法で「ハード」ページ ナビゲーションに基づいて Core Web Vitals を測定することをおすすめします。これは、現時点での CrUX の測定値とも一致します（詳しくは後述）。
ソフト ナビゲーションは、今後どのように測定される可能性があるかを確認し、この実装が実際にどのように機能するかについて Chrome チームにフィードバックする機会を得るために、これらの測定に加えて測定する必要があります。このフィードバックは、あなたと Chrome チームが今後 API を開発していくうえで役立ちます。
LCP の場合、現在の方法では largest-contentful-paint エントリのみを考慮し、新しい方法では largest-contentful-paint エントリと interaction-contentful-paint エントリの両方を考慮します。
CLS と INP の場合、これは、現在の方法と同様にページ ライフサイクル全体でこれらの指標を測定し、ソフト ナビゲーションでタイムラインを個別にスライスして、新しい CLS と INP の値を個別に測定することを意味します。
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';
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 はインタラクション時またはページがバックグラウンドに移行したときに報告されます。これは、その時点で LCP が確定されるためです。 |
| CLS | ナビゲーション間のシフトの最大ウィンドウ。通常、CLS はページがバックグラウンドに移行したときにのみ確定します。シフトがない場合は、値 0 が報告されます。 |
| INP | ナビゲーション間の INP。通常、INP はインタラクション時、またはページがバックグラウンドに移動したときにレポートされます。これは、その時点でしか INP を確定できないためです。インタラクションがない場合、値 0 はレポートされません。 |
これらの変更は Core Web Vitals の測定の一部になりますか？
Google は、このヒューリスティクスを評価し、Core Web Vitals イニシアチブに統合するかどうかを決定する前に、ユーザー エクスペリエンスをより正確に反映しているかどうかを確認したいと考えています。最終的な目標は、実際のユーザーが体験するパフォーマンスをより適切に測定する手段を提供することです。したがって、このテストが成功した場合、すべてのツールで公開される Core Web Vitals の測定にこれらを含めることを目指しています。
Google は、このテスト、使用されたヒューリスティック、エクスペリエンスがより正確に反映されているかどうかについて、ウェブ デベロッパーの皆様からのフィードバックを重視しています。フィードバックは、ソフト ナビゲーションの GitHub リポジトリに投稿するのが最適です。ただし、Chrome の実装に関する個々のバグについては、Chrome の問題トラッカーで報告してください。
CrUX でソフト ナビゲーションはどのように報告されますか？
このテストが成功した場合に、CrUX でソフト ナビゲーションがどのように報告されるかについても、まだ決定されていません。現在の「ハード」ナビゲーションと同じように扱われるとは限りません。
一部のウェブページでは、ユーザーから見るとソフト ナビゲーションはページ全体の読み込みとほぼ同じで、シングルページ アプリケーション技術の使用は単なる実装の詳細です。他のアプリでは、追加コンテンツの部分的な読み込みに近い場合があります。
そのため、CrUX でこれらのソフト ナビゲーションを個別にレポートするか、特定のページまたはページグループのウェブに関する主な指標を計算する際に重み付けすることを検討しています。ヒューリスティックの進化に伴い、部分読み込みのソフト ナビゲーションを完全に除外できるようになる可能性もあります。
チームは、このテストの成功を判断するためのヒューリスティックと技術的な実装に注力しているため、これらの点についてはまだ決定されていません。
フィードバック
このテストに関するフィードバックは、以下の場所で積極的に募集しています。
- API に関するフィードバックは、GitHub の問題として報告してください。
- Chromium 実装のバグは、まだ既知の問題でない場合は、Chrome の問題トラッカーで報告する必要があります。
- ウェブ バイタルの一般的なフィードバックは、web-vitals-feedback@googlegroups.com までお寄せください。
どちらに投稿すべきか迷った場合は、あまり心配しないでください。どちらに投稿していただいても、Google は喜んでフィードバックを受け付け、両方の場所で問題をトリアージして、正しい場所にリダイレクトします。
変更履歴
この API は試験運用版であるため、安定版 API よりも多くの変更が加えられています。詳しくは、ソフト ナビゲーション ヒューリスティックの変更ログをご覧ください。
まとめ
ソフト ナビゲーションの試験運用機能は、Core Web Vitals イニシアチブが進化して、指標に欠けている最新のウェブの一般的なパターンを測定する可能性を示す、エキサイティングなアプローチです。このテストはまだ初期段階であり、やるべきことはたくさんありますが、これまでの進捗状況をより広範なウェブ コミュニティに公開してテストしてもらうことは、重要な一歩です。このテストからフィードバックを収集することも、テストの重要な部分です。この開発に関心をお持ちの方は、ぜひこの機会に API の形成にご協力ください。この API で測定したい内容を反映させることができます。
謝辞
サムネイル画像: Jordan Madrid（Unsplash）
この取り組みは、Yoav Weiss 氏が Google に在籍していたときに開始した取り組みの継続です。この API の開発に尽力してくれた Yoav に感謝します。