Core Web Vitalsをテストし、その背景にある要因を確認する.

Core Web Vitalsのテストでは、どのような項目が測定されるのでしょうか?

Core Web Vitalsのテストでは、ページごとに3つの数値が出ます。読み込みを表すLCP、応答性を表すINP、視覚的な安定性を表すCLSです。Search Consoleのレポートを開くと、これらの項目が「良好」「改善が必要」「不良」のいずれかで評価されています。LCPは、ページのメインコンテンツが読み込まれたとみなされる時点を示します。INPは、ページを開いている間に起きた対象のインタラクションをすべて測定し、訪問者が体験した中で最も悪いものを報告します。CLSは、表示中のコンテンツが予期せずずれる量を追跡します。たとえば、ボタンをタップしようとした瞬間にボタンが動いてしまう状況です。

数値を読むうえで、押さえておきたい事実が2つあります。1つ目は、指標がサイトの実際の訪問者から集められるため、訪問者ごとに値が異なることです。Googleやそのクローラーがページをどう見ているかとは別のものです。2つ目は、この診断がページ上で指標を測定しているわけではなく、ページが実際に配信している内容を読み取っていることです。それが数値の根拠であり、ご自身で直接手を入れられる部分です。

LCP、INP、CLSの合格基準はどのようなものでしょうか?

ページの75パーセンタイルで、LCPが2.5秒以下、INPが200ミリ秒以下、CLSが0.1以下なら合格です。レポートを開いて、基準を満たしていない項目を探してください。LCPが4000ミリ秒を超える、INPが500ミリ秒を超える、CLSが0.25を超える、のいずれかなら「不良」です。「良好」と「不良」の間にある項目は「改善が必要」になります。要するに、そのページはまだ基準に届いていません。

見落としやすいのが75パーセンタイルです。モバイルとデスクトップを合わせたページ読み込みのうち、4分の3が目標を満たしている必要があります。平均値が速くても、それだけでは合格になりません。PageSpeed Insightsが3つの指標すべてについて十分なデータを取得できた場合は、3つの75パーセンタイルがすべて基準を満たして初めて合格です。どの指標が基準に届いていないかは、レポートに表示されます。INPのデータが足りない場合は、LCPとCLSだけで評価されます。ただし、LCPまたはCLSのデータが欠けていると、ページを評価できません。2024年3月12日に、Core Web Vitalsの指標がFIDからINPに替わりました。古いレポートには、まだFIDが表示されていることがあります。

ラボテストの結果がフィールドデータと異なるのはなぜでしょうか?

結果が食い違うのは、1回の制御された読み込みと、実環境での多数の読み込みを比べているからです。ラボテストは、あらかじめ決めたデバイスとネットワーク設定で動きます。一方、実環境データには、訪問者が実際にページを読み込んだ記録が入っています。PageSpeed InsightsでURLを実行すると、2つのブロックが並びますので、見比べてみてください。ラボの結果は Lighthouse によるもの、実環境の結果は CrUX、つまり Chrome ユーザー体験レポートによるものです。ラボは再現もデバッグも簡単ですが、実環境のボトルネックを見逃すことがあります。実環境データが示すのは、ユーザーが実際に体験した状況です。ただ、測定指標の数は少なく、デバッグの詳細情報も限られています。

フィールドデータは、単一の数値ではなく分布です。Lighthouseを実行すれば毎回同じLCP要素が得られますが、実際の訪問者の側では、通常さまざまなLCP要素が生じます。CLSの値もばらつきます。Lighthouseのテストでは検出されないインタラクティブなコンテンツが、ページに含まれている可能性があるからです。ですから、2つの結果が食い違うときは、ロード後のCLSやINPについてラボ環境から得たアドバイスを、そのまま信じないでください。

フィールドデータがない場合、公開スキャンでWeb Vitalsについて何がわかるのでしょうか?

パブリックスキャンでわかるのは、各ページがどのような要素を含み、良好なスコアを出しやすいかどうかです。LCP、INP、CLSの75パーセンタイル値は表示されません。評価の「パフォーマンス」項目では、ホームページと最大8つのサンプリングページから読み取った、スクリプトの重さ、画像の読み込み状況、レンダリングパターンを確認できます。レスポンスヘッダーやマークアップも併せて表示されます（地味な部分ですが、多くの場合、いちばん重要な手がかりです）。つまり、ページが訪問者にどう届いているかが見えます。

ここで得られるのは測定値ではなく、原因を推測するための目安です。スクリプトバンドルが重ければ、INPのリスクが気になります。画像の読み込みが遅ければ、LCPのリスクがうかがえます。ただ、どちらも訪問者に実際に問題が出ている証拠にはなりません。逆も同じで、分析結果が良好でも、実環境のパフォーマンスが良好とは言い切れません。起動が遅いと、LCPの下限も決まってしまいます。ダウンロードが数秒間終わらないページは、2.5秒を切って表示されることがありません。最終的な判断には、評価結果に加えて、Search Consoleのフィールドデータも確認してください。

INPで不合格になりやすいのは、どのようなページのパターンでしょうか?

INPに失敗するページには、通常いくつかの原因があります。負荷の高いイベントハンドラの実行、メインスレッドをブロックするサードパーティのスクリプト、頻繁なレイアウトの再描画、大規模なDOMなどです。まず、最も処理に時間がかかりそうなフィルター、フォームフィールド、メニューをタップしてみてください。一時停止は見られますか？ ページに最も大きな悪影響を与えるのは負荷の高いイベントハンドラなので、複雑なフォームの検証処理、クライアントサイドのフィルタリング、大規模なDOMの変更を確認しましょう。アニメーションがレイアウトの再描画や大規模なペイントを引き起こす場合も、負荷は増えます。クリックやタップに紐付いた、負荷の高いサードパーティ製スクリプトも同様です。

INPは、ページの実行中に起きた最悪のインタラクションを報告する指標です。そのため、サイト上のコントロールが1つ遅いだけでも、数値は悪化します。まずコードを見て、よくある原因である「長いタスク」がないか確認してください。50ミリ秒以上かかるタスクのことです。見つかりましたか？ 一般的な対処法は、schedule.yield() や setTimeout を使ってタスクを小さく分割することです。DOM が大きいと、ページ上の表示を更新するたびに処理コストがかさみます。そして評価結果にはスクリプトの負荷とレンダリングパターンが出るので、どこから手を付けるかの見当がつきます。ただし、インタラクションそのものを記録しているのは、フィールドデータだけです。

Core Web Vitalsで最もよく見られる3つの不具合は、どのように修正すればよいでしょうか?

改善の方向は指標ごとに違います。LCPはメインコンテンツの読み込み開始を早めること、INPは長いタスクを分割してブロックするスクリプトを減らすこと、CLSはページ上で予期せず動く要素を特定してそのスペースを確保することです。最初に見るのは、Search Consoleのレポートです。75パーセンタイルで基準を満たしていない指標を確認し、その問題から先に直してください。そのうえで、手元のラボ環境で現象を再現してみましょう。実際のユーザーの体験を正確につかめるのは、フィールドツールです。でも、問題の特定や修正ではラボツールが役立つ場面も多くあります。得意な場面で使い分けてください。

LCPでは、コンテンツが表示されるまでの遅延要因を確認してください。ページのダウンロードが数秒間終わらなければ、2.5秒以内に表示されることはありません。次に、最も大きな要素がどう読み込まれるかを見ます。INPでは、50ミリ秒を超えるタスクを見つけたら、`scheduler.yield()` または `setTimeout` で分割し、ページ上のクリックに関わるサードパーティ製スクリプトを取り除いてください。ただ、CLSはラボ環境の実行ではシフトが起きないことがあります。インタラクティブな部分も、改めてテストが必要です。だから変更を加えるたびにサイトで評価を実行して、結果がどう変わったかを見てください。

よくある質問.

次に読む.

1. 01ウェブサイトのヘルスチェック全体的な診断、8つの柱すべて。
2. 02Next.js SEO監査レンダリングモード、メタデータ、ハイドレーションコスト。
3. 03ウェブサイト監査チェックリスト8つの柱を、自分で実行できるリストにまとめました。