コアWebバイタルを測定するための詳細ガイド

Googleは、2021年5月から（編集：日付は2021年6月に移動されました）、Core Web Vitalsと呼ばれる一連の指標で測定される検索ランキングの一部として、「ページエクスペリエンス」の検討を開始すると発表しました。 その日付はすぐに近づいており、私たちの多くはコアWebバイタルを確実に通過するように求められていると確信していますが、あなたが通過しているかどうかをどうやって知ることができますか？

その質問に答えるのは実際にはあなたが想像するよりも難しく、多くのツールがこれらのコアWebバイタルを公開していますが、理解すべき多くの重要な概念と微妙な点があります。 PageSpeedInsightsやGoogleSearchConsoleのCoreWebVitalsレポートなどのGoogleツールでさえ、紛らわしい情報を提供しているようです。

それはなぜですか。また、修正が実際に機能したことをどのように確認できますか？ サイトのコアWebバイタルの正確な画像を取得するにはどうすればよいですか？ この投稿では、ここで何が起こっているのかについてもう少し説明し、これらのツールの微妙な違いや誤解について説明しようと思います。

コアWebバイタルとは何ですか？

Core Web Vitalsは、Webサイトがユーザーにとって速いか遅いかという「コア」エクスペリエンスを測定するために設計された、3つのメトリックのセットであり、優れたエクスペリエンスを提供します。

ランキングの向上を最大限に活用するには、3つのコアWebバイタルすべてのWebページがグリーン測定の範囲内にある必要があります。 良好な範囲外では、2つのページ間でCore Web Vitalメトリックの値が異なると、ページエクスペリエンスのランキングが異なる可能性があります。

1.最大のコンテンツフルペイント（LCP）

このメトリックは、おそらくこれらの中で最も理解しやすいものです。ページに最大のアイテムが描画されるまでの時間を測定します。これは、おそらくユーザーが関心を持っているコンテンツの一部です。これは、バナー画像、テキスト、またはなんでもいい。 それがページ上で最大のコンテンツ要素であるという事実は、それが最も重要な部分であることを示す良い指標です。 LCPは比較的新しく、同様の名前のFirst Contentful Paint（FCP）を測定していましたが、LCPは、訪問者が見たいと思われるコンテンツが描画されるタイミングのより良い指標と見なされています。

LCPは読み込みパフォーマンスを測定することになっており、パフォーマンスコミュニティで使用していたすべての古い指標（つまり、最初のバイトまでの時間（TTFB）、読み込み中のDOMコンテンツ、レンダリングの開始、速度インデックス）の優れたプロキシですが、経験からユーザーの。 これらのメトリクスでカバーされるすべての情報を網羅しているわけではありませんが、ページの読み込みを適切に示すことを目的とした、より単純な単一のメトリクスです。

2.最初の入力遅延（FID）

この2番目の指標は、ユーザーがページを操作してから、たとえばリンクやボタンをクリックしてから、ブラウザがそのクリックを処理するまでの時間を測定します。 ページの双方向性を測定するためにあります。 すべてのコンテンツが読み込まれているのにページが応答しない場合、それはユーザーにとって苛立たしい経験です。

重要な点は、このメトリックは、ユーザーが実際にページをクリックしたり操作したりするタイミングと、それが実行されるまでにかかる時間に実際に依存するため、シミュレートできないことです。 Total Blocking Time（TBT）は、ユーザーが直接操作せずにテストツールを使用する場合のFIDの優れたプロキシですが、FIDを確認する場合はTime to Interactive（TTI）にも注意を払ってください。

3.累積レイアウトシフト（CLS）

非常に興味深い指標です。これまでにさまざまな理由で登場した他の指標とはまったく異なります。 これは、ページの視覚的な安定性を測定するように設計されています。基本的には、新しいコンテンツが所定の位置に挿入されたときにどれだけジャンプするかを測定します。 私たちは皆、記事をクリックして読み始め、画像、広告、その他のコンテンツが読み込まれるときにテキストをジャンプさせたと確信しています。

これはユーザーにとって非常に不快で煩わしいので、最小限に抑えるのが最善です。 さらに悪いのは、クリックしようとしていたボタンが突然移動し、代わりに別のボタンをクリックした場合です。 CLSは、これらのレイアウトの変化を考慮に入れようとします。

ラボとRUM

Core Web Vitalsについて理解するための重要なポイントの1つは、フィールドメトリックまたはReal User Metrics（RUM）に基づいていることです。 Googleは、Chromeユーザーからの匿名化されたデータを使用して指標をフィードバックし、Chromeユーザーエクスペリエンスレポート（CrUX）で利用できるようにします。 そのデータは、検索ランキングのこれら3つの指標を測定するために使用しているものです。 CrUXデータは、サイトのGoogle検索コンソールを含む多くのツールで利用できます。

RUMデータが使用されるという事実は、これらのメトリックの一部（FIDを除く）が、過去に多くのWebパフォーマンス監視の定番であったLighthouseのような合成または「ラボベース」のWebパフォーマンスツールで利用できるため、重要な違いです。 。 これらのツールは、シミュレートされたネットワークとデバイスでページの読み込みを実行し、そのテスト実行のメトリックを示します。

したがって、強力な開発者マシンでLighthouseを実行して優れたスコアを取得した場合、それはユーザーエクスペリエンスを実際の世界で反映していない可能性があり、GoogleがWebサイトのユーザーエクスペリエンスを測定するために使用するものです。

LCPは、ネットワークの状態と使用されているデバイスの処理能力に大きく依存します（そして、多くのユーザーが、あなたが思っているよりも低電力のデバイスを使用している可能性があります！）。 ただし、対位法として、少なくとも多くの欧米のサイトでは、モバイルモードのLighthouseなどのツールが示唆するほど低電力ではない可能性があります。これは、これらがかなり抑制されているためです。 したがって、モバイルでのフィールドデータは、この提案でテストするよりも優れていることに気付くかもしれません（Lighthouseモバイル設定の変更についてはいくつかの議論があります）。

同様に、FIDは多くの場合、プロセッサの速度と、送信するすべてのコンテンツをデバイスがどのように処理できるかに依存します。処理する画像、ページ上のレイアウトの要素、そしてもちろん、送信するのが大好きなすべてのJavaScriptです。ブラウザに移動します。

CLSは、理論的には、ネットワークやハードウェアの変動の影響を受けにくいため、ツールでより簡単に測定できます。したがって、最初は明らかではないかもしれないいくつかの重要な考慮事項を除いて、LABとRUMの違いの影響を受けないと思うでしょう。 ：

• これは、一般的なツールのようにページの読み込みだけでなく、ページの存続期間を通じて測定されます。これについては、この記事の後半で詳しく説明します。 これは、ラボでシミュレートされたページの読み込みのCLSが非常に低い場合に多くの混乱を引き起こしますが、テストツールが通常測定する初期読み込み後のスクロールまたはその他の変更によって引き起こされるCLSのため、フィールドのCLSスコアははるかに高くなります。
• ブラウザウィンドウのサイズによって異なります。通常、PageSpeed Insightsなどのツールは、モバイルとデスクトップを測定しますが、モバイルが異なれば画面サイズも異なり、デスクトップはこれらのツールセットよりもはるかに大きいことがよくあります（Webページテストでは最近、デフォルトの画面サイズが大きくなりました）。使用法をより正確に反映しようとするため）。
• ユーザーが異なれば、Webページで見るものも異なります。 Cookieバナー、プロモーション、アドブロッカー、A / Bテストなどのカスタマイズされたコンテンツですが、異なる可能性のあるいくつかのアイテムはすべて、描画されるコンテンツに影響を与え、CLSユーザーが体験する可能性があります。
• それはまだ進化しており、ChromeチームはCLSにカウントされるべきではない「目に見えない」シフトなどの修正に忙しくしています。 CLSの実際の測定方法に対する大きな変更も進行中です。 これは、実行されているChromeのバージョンに応じて異なるCLS値を表示できることを意味します。

ラボベースのテストツールでメトリクスに同じ名前を使用すると、実際のバージョンが正確に反映されない場合が混乱し、Lighthouseでこれらのメトリクスの一部またはすべての名前を変更して、これらのシミュレートされたメトリクスをGoogleのランキングを強化する実際のRUM指標。

以前のWebパフォーマンスメトリクス

もう1つの混乱点は、これらのメトリックは新しく、Webパフォーマンスを測定するためにこれまで従来使用していたメトリックとは異なり、無料のオンライン監査ツールであるPageSpeedInsightsなどのツールによって表示されることです。 監査するURLを入力し、[分析]をクリックするだけで、数秒後に、豊富な情報を含む2つのタブ（1つはモバイル用、もう1つはデスクトップ用）が表示されます。

一番上にあるのは、100点満点の大きな灯台パフォーマンススコアです。これは、しばらくの間Webパフォーマンスコミュニティでよく知られており、多くのメトリックの複雑さを単純なものに要約することを目的とした主要なパフォーマンスメトリックとして引用されることがよくあります。 、わかりやすい番号。 これは、Core Web Vitalsの目標と一部重複していますが、3つのCore Web Vitals（ラボベースのバージョンでさえ）の要約ではなく、さまざまなメトリックの要約です。

現在、6つのメトリックがLighthouseパフォーマンススコアを構成しています。これには、いくつかのCoreWebVitalsと他のいくつかのメトリックが含まれます。

• First Contentful Paint（FCP）
• SpeedIndex（SI）
• 最大のコンテンツフルペイント（LCP）
• インタラクティブまでの時間（TTI）
• 総ブロッキング時間（TBT）
• 累積レイアウトシフト（CLS）

複雑さを増すために、これら6つのそれぞれのパフォーマンススコアとCLSの重み付けは異なりますが、コアWeb Vitalsの1つであるにもかかわらず、現在、Lighthouseパフォーマンススコアの5％にすぎません（これはすぐに増加することに賭けます） CLSの次のイテレーションがリリースされます）。 つまり、非常に高い緑色のLighthouseパフォーマンススコアを取得し、Webサイトは正常であると考えることができますが、それでもCoreWebVitalsのしきい値を超えることはできません。 したがって、これらの3つの主要な指標を確認するために、今すぐ努力を集中する必要があるかもしれません。

そのスクリーンショットの大きな緑色のスコアを超えて、フィールドデータに移動すると、別の混乱が生じます。コアWebの一部ではないにもかかわらず、最初のコンテンツフルペイントが他の3つのコアWebバイタルとともにこのフィールドデータに表示されます。 Vitalsと、この例のように、他のすべてが通過している間でも、警告としてフラグが立てられることがよくあります。 （おそらく、このためのしきい値を少し調整する必要がありますか？）FCPは、コアWeb Vitalであることをわずかに見逃していましたか、それとも4つのメトリックとのバランスが取れているように見えますか？ このフィールドデータセクションは重要であり、後で戻ってきます。

テスト対象の特定のURLで使用できるフィールドデータがない場合は、代わりにドメイン全体のオリジンデータが表示されます（上記のように、その特定のURLでフィールドデータが使用できる場合、これはデフォルトで非表示になります）。

フィールドデータの後に、ラボデータを取得し、パフォーマンススコアを構成する6つのメトリックを上部に表示します。 右上のトグルをクリックすると、これらの指標の説明がもう少し表示されます。

ご覧のとおり、LCPとCLSのラボバージョンがここに含まれています。これらはCore Web Vitalsの一部であるため、特別に重要であることを示す青いラベルが付けられています。 PageSpeed Insightsには、これらのスコアが上部の合計スコアに与える影響を確認するための便利な計算機リンクも含まれています。これらのスコアを調整して、各メトリックがスコアにどのように影響するかを確認できます。 しかし、私が言っているように、Core Web Vitalsが現時点ですべての注目を集めている間、Webパフォーマンススコアは少し後回しになる可能性があります。

Lighthouseは、追加のオポチュニティと診断についても50近くのチェックを実行します。 これらはスコアにもCoreWebVitalsにも直接影響しませんが、Web開発者がサイトのパフォーマンスを向上させるために使用できます。 これらは、すべてのメトリックの下のPageSpeed Insightsにも表示されるため、上のスクリーンショットではショットから外れています。 これらは、必然的に対処する必要のある特定の問題ではなく、パフォーマンスを改善する方法に関する提案と考えてください。

診断では、コアWebバイタルを最適化するときに非常に役立つ情報である、CLSスコアに貢献したLCP要素とシフトが表示されます。

したがって、過去のWebパフォーマンスの支持者は、Lighthouseのスコアと監査に重点を置いていたかもしれませんが、少なくとも次の期間は、3つのコアWebVitalメトリックに焦点を当てています。 他のLighthouseメトリック、および全体的なスコアは、サイトのパフォーマンスを最適化するのに引き続き役立ちますが、Core Web Vitalsは現在、新しいWebパフォーマンスとSEOブログ投稿のほとんどを占めています。

あなたのサイトのコアWebバイタルを表示する

個々のURLおよびオリジン全体のコアWebバイタルをすばやく確認する最も簡単な方法は、上記のようにPageSpeedInsightsにURLを入力することです。 ただし、Googleがサイト全体のコアWebバイタルをどのように認識しているかを確認するには、Google検索コンソールにアクセスしてください。 これはGoogleが作成した無料の製品で、サイトのコアWebバイタルを含むサイト全体をGoogleがどのように「認識」しているかを理解できます（ただし、ここでデータが更新される頻度に「フラストレーション」があります。 ）。

Google Search ConsoleはSEOチームによって長い間使用されてきましたが、サイト開発者がCore Web Vitalsに対処する必要があるという意見があれば、開発チームはまだこのツールにアクセスできない場合でも実際にアクセスできるはずです。 アクセスするには、Googleアカウントが必要です。次に、さまざまな方法（Webサーバーにファイルを配置する、DNSレコードを追加するなど）でサイトの所有権を確認する必要があります。

Google検索コンソールのコアウェブバイタルレポートは、過去90日間にサイトがコアウェブバイタルをどのように満たしているかをまとめたものです。

理想的には、Core Web Vitalsを完全に通過していると見なされるには、すべてのページを緑で、琥珀や赤を含まないようにする必要があります。 琥珀色はあなたが合格に近づいている良い指標ですが、それは実際には完全な利益を得るために数えられるのは緑だけなので、2番目に良いものに落ち着かないでください。 すべてのページを渡す必要があるか、重要なページだけを渡す必要があるかはあなた次第ですが、多くの場合、多くのページで同様の問題が発生します。サイトのページを修正すると、渡されないURLの数をより管理しやすくすることができます。あなたがそれらの決定をすることができるレベル。

当初、GoogleはCore Web Vitalsランキングをモバイルにのみ適用する予定ですが、それがデスクトップにも展開されるのは時間の問題なので、ページを確認して修正している間はデスクトップを無視しないでください。

レポートの1つをクリックすると、どのWebバイタルが満たされていないかについての詳細が表示され、影響を受けるURLのサンプルが表示されます。 Google Search Consoleは、 URLをバケットにグループ化して、理論的には、類似したページをまとめてアドレス指定できるようにします。 次に、URLをクリックしてPageSpeed Insightsを実行し、特定のURLでクイックパフォーマンス監査を実行できます（そのページのコアWebバイタルフィールドデータが利用可能な場合はそれを表示することも含まれます）。 次に、強調表示された問題を修正し、PageSpeed Insightsを再実行してラボの指標が正しいことを確認してから、次のページに進みます。

ただし、そのCore Web Vitalsレポート（私たちの一部にとっては執拗に！）を見始めると、このレポートがあなたの努力を反映して更新されていないように見えることに不満を感じているかもしれません。 グラフが移動するにつれて毎日更新されるように見えますが、修正をリリースした後でもほとんど変更されないことがよくあります。なぜですか。

同様に、PageSpeed Insightsのフィールドデータは、そのURLとサイトが失敗していることを頑固に示しています。 それでは、ここでの話は何ですか？

Chromeユーザーエクスペリエンスレポート（CrUX）

Web Vitalsの更新が遅い理由は、フィールドデータがChromeユーザーエクスペリエンスレポート（CrUX）の過去28日間のデータに基づいており、その中で、そのデータの75パーセンタイルのみに基づいているためです。 28日分のデータを使用し、データの75パーセンタイルは、分散や極端な値を削除して、解釈が難しい多くのノイズを発生させることなく、サイトのパフォーマンスをより正確に反映するという点で優れています。

パフォーマンスメトリクスはネットワークとデバイスの影響を非常に受けやすいため、ほとんどのユーザーのWebサイトのパフォーマンスを実際に把握するには、このノイズを平滑化する必要があります。 ただし、その反面、更新がイライラするほど遅く、修正の結果が反映されるまで、問題の修正から非常に遅いフィードバックループが作成されます。

特に75パーセンタイル（またはp75）は興味深いものであり、それによって生じる遅延はよく理解されていないと思います。 コアWebバイタルごとに、28日間の訪問者のページビューの75％を測定します。

したがって、これはページビューの75％の最高のコアWebバイタルスコアです（または逆に、ページビューの75％よりも少ないコアウェブバイタルスコアです）。 したがって、これはページビューのこの75％の平均ではなく、そのユーザーセットの最悪の値です。

これにより、パーセンタイルに基づかない移動平均では報告されないという報告が遅れます。 ここでは少し数学を習得する必要があります（最小限に抑えるようにします）が、簡単にするために、先月は全員が10秒のLCPを取得したので、修正しました。たった1秒で、毎日まったく同じ数の訪問者がいて、全員がこのLCPを獲得したとします。

その過度に単純化されたシナリオでは、次のメトリックが得られます。

したがって、CrUXスコアの大幅な改善は22日目まで見られず、突然新しい低い値にジャンプすることがわかります（28日間の平均の75％を超えると、偶然ではありません！）。 それまでは、ユーザーの25％以上が変更前に収集されたデータに基づいていたため、古い値の10を取得しているため、p75​​の値は10のままでした。

したがって、長い間まったく進歩がなかったように見えますが、平均（使用された場合）はすぐに開始する段階的なティックダウンを示し、実際に進歩を見ることができます。 プラス面として、過去数日間の平均は、p75が定義上、極値を完全に除外するため、実際にはp75値よりも高くなっています。

上記の表の例は、大幅に簡略化されていますが、多くの人が以下のようなWeb Vitalsグラフを表示する理由のひとつを説明しています。これにより、ある日、すべてのページがしきい値を超えて、良好になります（ woohoo！ ）：

これは、ページの問題を処理するときに、また一部のページが他のページよりも頻繁にアクセスされるため、より段階的な（そして瞬間的な）変更を期待している人にとっては驚くべきことかもしれません。 関連する注意点として、修正とそれらがしきい値に与える影響に応じて、検索コンソールのグラフが琥珀色の期間を経てから、その甘い甘い緑色に達することも珍しくありません。

Dave Smartは、検索コンソールのレポートコアWebバイタルデータの変更を追跡する魅力的な実験を実行しました。そこでは、グラフの更新にどれだけの時間がかかったかを調べたいと考えていました。 彼はCrUXの75パーセンタイル部分を考慮していませんでしたが（グラフの一部に動きがないことがより理にかなっています）、それでもこのグラフがどのように更新され、読む価値があるかについての魅力的な実際の実験です！

私自身の経験では、この28日間のp75方法論では、Core Web Vitalsレポートの遅延を完全には説明していません。他のいくつかの潜在的な理由については、後ほど説明します。

それで、CrUXが修正を価値があると見なし、SearchConsoleとPageSpeedInsightsのグラフを更新するまで、できる限りの修正を行い、辛抱強く待って指をタップしますか？ そして、修正が十分でなかったことが判明した場合は、サイクル全体を再開しますか？ 私たちの渇望を満たすためのインスタントフィードバックと、開発者が生産性を向上させるためのタイトなフィードバックループのこの日では、それはまったく満足のいくものではありません！

それまでの間、修正によって意図した効果が得られるかどうかを確認するためにできることがいくつかあります。

Cruxデータをより詳細に掘り下げる

測定の中核はCrUXデータであるため、それをさらに掘り下げて、他に何がわかるかを見てみましょう。 PageSpeed Insightsに戻ると、サイトのp75値だけでなく、下のカラーバーに表示されている緑、琥珀、赤の各バケットのページビューの割合も表示されていることがわかります。

上のスクリーンショットは、CLSがコアWebバイタルのスコアリングに失敗していることを示しています。p75値は0.11で、これは0.1の合格制限を上回っています。 ただし、フォントの色が赤であるにもかかわらず、これは実際には琥珀色のランキングです（赤は0.25を超えるため）。 さらに興味深いのは、緑色のバーが73％になっていることです。これが75％に達すると、このページはCoreWebVitalsを通過します。

CrUXの履歴値を確認することはできませんが、これを長期にわたって監視することができます。 明日が74％になると、私たちは正しい方向に向かっており（変動する可能性があります！）、すぐに75％の魔法を打つことを期待できます。 遠くにある値については、定期的にチェックして増加を確認し、合格として表示され始める可能性があるときに予測することができます。

CrUXは、これらのパーセンテージのより正確な数値を取得するための無料のAPIとしても利用できます。 APIキーにサインアップしたら、次のようなcurlコマンドを使用して呼び出すことができます（API_KEY、formFactor、およびURLを適切に置き換えます）。

 curl -s --request POST 'https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY' \ --header 'Accept: application/json' \ --header 'Content-Type: application/json' \ --data '{"formFactor":"PHONE","url":"https://www.example.com"}'

そして、次のようなJSON応答を受け取ります。

 { "record": { "key": { "formFactor": "PHONE", "url": "https://www.example.com/" }, "metrics": { "cumulative_layout_shift": { "histogram": [ { "start": "0.00", "end": "0.10", "density": 0.99959769344240312 }, { "start": "0.10", "end": "0.25", "density": 0.00040230655759688886 }, { "start": "0.25" } ], "percentiles": { "p75": "0.00" } }, "first_contentful_paint": { ... } } }, "urlNormalizationDetails": { "originalUrl": "https://www.example.com", "normalizedUrl": "https://www.example.com/" } }

ちなみに、上記が少し怖くて、1つのURLについてこのデータをすばやく確認したい場合は、PageSpeed Insightsもこの精度を返します。これは、DevToolsを開いてPageSpeedInsightsテストを実行することで確認できます。 XHR呼び出しを見つける：

CrUXAPIのサンプルクエリを作成できるインタラクティブなCrUXAPIエクスプローラーもあります。 ただし、APIを定期的に呼び出す場合は、通常、無料のキーを取得してCurlまたはその他のAPIツールを使用する方が簡単です。

APIは、URLの代わりに「オリジン」を使用して呼び出すこともできます。その時点で、そのドメインへのすべてのページ訪問の要約値が提供されます。 PageSpeed Insightsはこの情報を公開します。これは、URLに利用可能なCrUX情報がない場合に役立ちますが、Google検索コンソールにはありません。 Googleは、Core Web Vitalsがランキングにどのように影響するかを正確に述べていません（そしてそうなる可能性は低いです！）。 オリジンレベルのスコアはランキングに影響しますか、それとも個々のURLスコアのみに影響しますか？ または、PageSpeed Insightsのように、個々のURLデータが存在しない場合、Googleは元のレベルのスコアにフォールバックしますか？ 現時点では知るのが難しく、これまでのところ唯一のヒントはFAQのこれです：

Q ：最近公開され、28日間のデータがまだ生成されていないURLのスコアはどのように計算されますか？

A ：検索コンソールがページエクスペリエンスデータをレポートする方法と同様に、類似したページをグループ化し、その集計に基づいてスコアを計算するなどの手法を採用できます。 これは、トラフィックをほとんどまたはまったく受信しないページに適用されるため、フィールドデータのない小さなサイトを心配する必要はありません。

CrUX APIはプログラムで呼び出すことができ、GoogleCrUXチームのRickViscomiはGoogleスプレッドシートモニターを作成しました。これにより、URLまたはオリジンを一括チェックでき、多数のURLまたはオリジンを綿密に監視する場合は、時間の経過とともにCrUXデータを自動的に追跡することもできます。 。 シートのクローンを作成し、[ Tools → Scriptエディター]に移動し、キーを使用してCRUX_API_KEYのスクリプトプロパティを入力し（これはレガシーエディターで実行する必要があります）、スクリプトを実行すると、指定されたCrUXAPIが呼び出されます。 URLまたは起点を指定し、データを含む行をシートの下部に追加します。 その後、これを定期的に実行することも、定期的に実行するようにスケジュールすることもできます。

これを使用して、GoogleSearchConsoleでCoreWebVitalsレポートの更新が遅いサイトのすべてのURLをチェックし、CrUXに多くのURLのデータがなく、残りのほとんどが合格したことを確認しました。 Google Search Consoleレポートは遅れています—それが基づいているはずのCrUXデータからでさえ。 以前に失敗したURLが原因で、更新されたCrUXデータを取得するのに十分なトラフィックがないためか、それとも他の原因によるものかはわかりませんが、このレポートは間違いなく遅いことがわかります。

その大部分は、CrUXとGoogle検索にデータのないURLがそれらの値をプロキシするために最善を尽くしていることが原因であると思われます。 したがって、このレポートは、サイトの概要を把握するための開始点としては最適であり、今後の監視には最適ですが、より迅速なフィードバックが必要な問題を処理するための優れたレポートではありません。

CrUXをさらに詳しく知りたい場合は、BigQueryで利用できるCrUXデータの月次テーブルがあり（元のレベルのみで、個々のURLではありません）、Rickは、これに基づいてCrUXダッシュボードを作成する方法も文書化しています。数か月にわたってウェブサイト全体のパフォーマンスを監視する良い方法になります。

Cruxデータに関するその他の情報

したがって、上記を使用すると、CrUXデータセット、それを使用するツールの一部が更新に時間がかかり、不安定に見える理由、およびそれをもう少し詳しく調べる方法を十分に理解する必要があります。 ただし、代替案に進む前に、CrUXについて理解しておくべきことがいくつかあり、表示されているデータを実際に理解するのに役立ちます。 そこで、コアWebバイタルに関連してCrUXについて収集したその他の有用な情報のコレクションを次に示します。

CrUXはChromeのみです。 これらすべてのiOSユーザー、およびその他のブラウザー（Desktop Safari、Firefox、Edgeなど）は、古いブラウザー（Internet Explorer —急いでフェードアウトします！）は言うまでもなく、ユーザーエクスペリエンスがCrUXデータに反映されていません。 GoogleのCoreWebVitalsの見方について。

現在、Chromeの使用率は非常に高く（おそらくサイト訪問者にとってはそうではありませんか？）、ほとんどの場合、Chromeが強調するパフォーマンスの問題は、他のブラウザーにも影響しますが、注意が必要です。 そして控えめに言っても、検索におけるグーグルの独占的地位が人々に彼らのブラウザのために最適化することを奨励していることは少し「厄介」に感じます。 この限られたビューの代替ソリューションについては、以下で説明します。

使用されているChromeのバージョンも影響を及ぼします。これらの指標（特にCLS）はまだ進化しており、バグが発見されて修正されているからです。 これにより、データの理解がさらに複雑になります。 Chromeの最近のバージョンではCLSが継続的に改善されており、Chrome 91に導入されたCLSの再定義が大きくなっています。フィールドデータが使用されているという事実は、これらの変更がユーザーに反映されるまでに時間がかかる可能性があることを意味します。次に、CrUXデータに追加します。

CrUXは、 Chromeにログインしているユーザー、または実際の定義を引用するユーザーのみを対象としています。

「[CrUXは]閲覧履歴の同期をオプトインし、同期パスフレーズを設定しておらず、使用統計レポートを有効にしているユーザーから集計されます。」

— Chromeユーザーエクスペリエンスレポート、Google Developers

したがって、主に企業ネットワークからアクセスされるサイトで情報を探している場合、そのような設定は中央のITポリシーによってオフになっているため、特に貧しい企業ユーザーが依然としてインターネットの使用を余儀なくされている場合は、多くのデータが表示されない可能性があります。エクスプローラーも！

CrUXには、「インデックスなし/ロボット/ログインページが含まれる」など、通常はGoogle検索に表示されないページを含むすべてのページが含まれます（ただし、CrUXで公開されるURLとオリジンには最小しきい値があります）。 これらのカテゴリのページはGoogle検索結果に含まれない可能性が高いため、ランキングへの影響はおそらく重要ではありませんが、CrUXには引き続き含まれます。 ただし、GoogleSearchConsoleのCoreWebVitalsレポートには、インデックス付きのURLしか表示されないようであるため、そこには表示されません。

PageSpeed Insightsと生のCrUXデータに表示される元の数値には、インデックスが作成されていない非公開のページが含まれます。前述したように、その影響についてはわかりません。 私が取り組んでいるサイトでは、ログインしたページにアクセスする訪問者の割合が高く、公開ページは非常にパフォーマンスが高いものの、ログインしたページはそうではなく、元のWebVitalsスコアが大幅に歪んでいました。

CrUX APIを使用してこれらのログインURLのデータを取得できますが、PageSpeed Insightsなどのツールは使用できません（実際のブラウザーを実行するため、ログインページにリダイレクトされるため）。 CrUXデータを見て影響を認識したら、それらを修正し、元の数値が低下し始めましたが、相変わらず、フィードスルーには時間がかかります。

インデックス付けされていないページやログインしているページも、個々のページのコレクションではなく「アプリ」であることが多いため、1つの実際のURLでシングルページアプリケーションの方法論を使用している可能性がありますが、その下には多くの異なるページがあります。 これは、特にCLSに影響を与える可能性があります。これは、ページの存続期間全体にわたって測定されるためです（ただし、CLSへの今後の変更がそれを支援することを願っています）。

前述のように、GoogleSearchConsoleのCoreWebVitalsレポートは、CrUXに基づいていますが、まったく同じデータではありません。 前に述べたように、これは主にGoogleSearchConsoleがCrUXデータが存在しないURLのWebVitalsを推定しようとしたことが原因であると思われます。 このレポートのサンプルURLも、CrUXデータを使用したものではありません。

I've seen many instances of URLs that have been fixed, and the CrUX data in either PageSpeed Insights, or directly via the API, will show it passing Web Vitals, yet when you click on the red line in the Core Web Vitals report and get sample URLs these passing URLs will be included as if they are failing . I'm not sure what heuristics Google Search Console uses for this grouping, or how often it and sample URLs are updated, but it could do with updating more often in my opinion!

CrUX is based on page views . That means your most popular pages will have a large influence on your origin CrUX data. Some pages will drop in and out of CrUX each day as they meet these thresholds or not, and perhaps the origin data is coming into play for those? Also if you had a big campaign for a period and lots of visits, then made improvements but have fewer visits since, you will see a larger proportion of the older, worse data.

CrUX data is separated into Mobile , Desktop and Tablet — though only Mobile and Desktop are exposed in most tools. The CrUX API and BigQuery allows you to look at Tablet data if you really want to, but I'd advise concentrating on Mobile and then Desktop. Also, note in some cases (like the CrUX API) it's marked as PHONE rather than MOBILE to reflect it's based on the form factor, rather than that the data is based on being on a mobile network.

All in all, a lot of these issues are impacts of field (RUM) data gathering, but all these nuances can be a lot to take on when you've been tasked with “fixing our Core Web Vitals”. The more you understand how these Core Web Vitals are gathered and processed, the more the data will make sense, and the more time you can spend on fixing the actual issues, rather than scratching your head wondering why it's not reporting what you think it should be.

Getting Faster Feedback

OK, so by now you should have a good handle on how the Core Web Vitals are collected and exposed through the various tools, but that still leaves us with the issue of how we can get better and quicker feedback. Waiting 21–28 days to see the impact in CrUX data — only to realize your fixes weren't sufficient — is way too slow. So while some of the tips above can be used to see if CrUX is trending in the right direction, it's still not ideal. The only solution, therefore, is to look beyond CrUX in order to replicate what it's doing, but expose the data faster.

There are a number of great commercial RUM products on the market that measure user performance of your site and expose the data in dashboards or APIs to allow you to query the data in much more depth and at much more granular frequency than CrUX allows. I'll not give any names of products here to avoid accusations of favoritism, or offend anyone I leave off! As the Core Web Vitals are exposed as browser APIs (by Chromium-based browsers at least, other browsers like Safari and Firefox do not yet expose some of the newer metrics like LCP and CLS), they should, in theory, be the same data as exposed to CrUX and therefore to Google — with the same above caveats in mind!

For those without access to these RUM products, Google has also made available a Web Vitals JavaScript library, which allows you to get access to these metrics and report them back as you see fit. This can be used to send this data back to Google Analytics by running the following script on your web pages:

 <script type="module"> import {getFCP, getLCP, getCLS, getTTFB, getFID} from 'https://unpkg.com/web-vitals?module'; function sendWebVitals() { function sendWebVitalsGAEvents({name, delta, id, entries}) { if ("function" == typeof ga) { ga('send', 'event', { eventCategory: 'Web Vitals', eventAction: name, // The `id` value will be unique to the current page load. When sending // multiple values from the same page (eg for CLS), Google Analytics can // compute a total by grouping on this ID (note: requires `eventLabel` to // be a dimension in your report). eventLabel: id, // Google Analytics metrics must be integers, so the value is rounded. // For CLS the value is first multiplied by 1000 for greater precision // (note: increase the multiplier for greater precision if needed). eventValue: Math.round(name === 'CLS' ? delta * 1000 : delta), // Use a non-interaction event to avoid affecting bounce rate. nonInteraction: true, // Use `sendBeacon()` if the browser supports it. transport: 'beacon' }); } } // Register function to send Core Web Vitals and other metrics as they become available getFCP(sendWebVitalsGAEvents); getLCP(sendWebVitalsGAEvents); getCLS(sendWebVitalsGAEvents); getTTFB(sendWebVitalsGAEvents); getFID(sendWebVitalsGAEvents); } sendWebVitals(); </script>

Or alternatively, you can include this as an external script instead:

 <script type="module" src="/javascript/send-web-vitals.js"></script>

Now I realize the irony of adding another script to measure the impact of your website, which is probably slow in part because of too much JavaScript, but as you can see above, the script is quite small and the library it loads is only a further 1.7 kB compressed (4.0 kB uncompressed). Additionally, as a module (which will be ignored by older browsers that don't understand web vitals), its execution is deferred so shouldn't impact your site too much, and the data it can gather can be invaluable to help you investigate your Core Web Vital, in a more real-time manner than the CrUX data allows.

The script registers a function to send a Google Analytics event when each metric becomes available. For FCP and TTFB this is as soon as the page is loaded, for FID after the first interaction from the user, while for LCP and CLS it is when the page is navigated away from or backgrounded and the actual LCP and CLS are definitely known. You can use developer tools to see these beacons being sent for that page, whereas the CrUX data happens in the background without being exposed here.

The benefit of putting this data in a tool like Google Analytics is you can slice and dice the data based on all the other information you have in there, including form factor (desktop or mobile), new or returning visitors, funnel conversions, Chrome version, and so on. And, as it's RUM data, it will be affected by real usage — users on faster or slower devices will report back faster or slower values — rather than a developer testing on their high spec machine and saying it's fine.

At the same time, you need to bear in mind that the reason the CrUX data is aggregated over 28 days, and only looks at the 75th percentile is to remove the variance. Having access to the raw data allows you to see more granular data , but that means you're more susceptible to extreme variations. Still, as long as you keep that in mind, keeping early access to data can be very valuable.

Google's Phil Walton created a Web-Vitals dashboard, that can be pointed at your Google Analytics account to download this data, calculate the 75th percentile (so that helps with the variations!) and then display your Core Web Vitals score, a histogram of information, a time series of the data, and your top 5 visited pages with the top elements causing those scores.

Using this dashboard, you can filter on individual pages (using a ga:pagePath==/page/path/index.html filter), and see a very satisfying graph like this within a day of you releasing your fix, and know your fix has been successful and you can move on to your next challenge!:

With a little bit more JavaScript you can also expose more information (like what the LCP element is, or which element is causing the most CLS) into a Google Analytics Custom Dimension. Phil wrote an excellent Debug Web Vitals in the field post on this which basically shows how you can enhance the above script to send this debug information as well, as shown in this version of the script.

These dimensions can also be reported in the dashboard (using ga:dimension1 as the Debug dimension field, assuming this is being sent back in Google Analytics Customer Dimension 1 in the script), to get data like this to see the LCP element as seen by those browsers:

前に述べたように、市販のRUM製品は、この種のデータも公開することがよくあります（そしてそれ以上！）が、足を水に浸しただけで、それらの製品の財政的コミットメントの準備ができていない人にとって、これは少なくとも最初の手を出すことを提供しますRUMベースのメトリクスと、実装している改善に関する重要な迅速なフィードバックを取得するのにどれほど役立つかを説明します。 そして、これがこの情報に対するあなたの欲求を刺激するなら、間違いなくそこにある他のRUM製品を見て、それらがどのようにあなたを助けることができるかを見てください。

代替の測定値とRUM製品を見るときは、Googleがサイトに表示しているものとは異なる可能性があるため、必ず元に戻してください。 パフォーマンスに一生懸命取り組むのは残念ですが、同時にこれのすべてのランキングの利点を得るわけではありません！ したがって、これらの検索コンソールのグラフに注目して、何かを見逃していないことを確認してください。

結論

Core Web Vitalsは、Webの閲覧のユーザーエクスペリエンスを表すことを目的とした興味深い一連の主要なメトリックです。 熱心なWebパフォーマンスの支持者として、サイトのパフォーマンスを改善するためのあらゆるプッシュを歓迎します。これらのメトリックのランキングへの影響は、WebパフォーマンスとSEOコミュニティで確かに大きな話題を呼んでいます。

メトリック自体は非常に興味深いものですが、おそらくもっとエキサイティングなのは、これらを測定するためのCrUXデータの使用です。 これにより、基本的にRUMデータが、これまでこの方法で現場でサイトのパフォーマンスを測定することを検討したことのないWebサイトに公開されます。 RUMデータは、ユーザーが実際に体験しているものであり、すべてのワイルドで多様な設定であり、Webサイトが実際にどのように実行され、ユーザーによって体験されているかを理解することに代わるものはありません。

しかし、私たちが長い間ラボデータに依存してきた理由は、RUMデータにノイズが多いためです。 これを減らすためにCrUXが実行する手順は、より安定したビューを提供するのに役立ちますが、それを犠牲にして、最近の変更を確認するのが難しくなります。

うまくいけば、この投稿は、WebサイトのCore Web Vitalsデータにアクセスするさまざまな方法と、各方法の制限のいくつかを説明するのに役立つでしょう。 また、理解に苦労しているデータのいくつかを説明し、それらの制限を回避するためのいくつかの方法を提案するのに役立つことを願っています。

最適化をお楽しみください。