Core Web Vitals：Google の速度テストに合格する

2021 年に、Google はCore Web Vitals が順位要因であると発表しました。3 つの具体的な指標、Largest Contentful Paint（LCP）、Cumulative Layout Shift（CLS）、Interaction to Next Paint（INP）が、検索順位に直接影響します。Vitals が悪いサイトは上位に表示されにくくなり、Vitals が優れたサイトは順位で優位に立ちます。現代の SEO では、Core Web Vitals の合格は譲れません。

その意味は重大です。もはやパフォーマンスを無視することはできません。遅いウェブサイトを作って良い順位を期待することはできません。Google は、ユーザー体験が重要であることを明確にしており、Core Web Vitals はユーザー体験を数値化したものです。Core Web Vitals の最適化は、もはや任意ではなく、競争力のある検索での可視性のために必須です。

Core Web Vitals とは何か、なぜ重要か

Core Web Vitals は、ユーザー体験の 3 つの側面を測ります。読み込みの速さ（LCP）、視覚的な安定性（CLS）、応答性（INP）です。Google の Web Vitals のページは、各指標を詳しく定義しています。この 3 つの指標は、ユーザーがウェブサイトをどう体験するかの最も重要な側面を表しています。

Google は、どの指標が最も重要かを判断するために、実際のユーザーから何兆ものデータポイントを集めました。その結果が Core Web Vitals です。これらは恣意的な基準値ではなく、実際のユーザーにとってウェブサイトを速く応答性が高いと感じさせる要素についての、証拠に基づく測定です。

Google の公式発表は、Core Web Vitals が検索順位にどう影響するかを説明しています。Google は Core Web Vitals を複数の順位要因の一つとみなしています。コンテンツの質と関連性のほうが今も重要ですが、同じくらい関連性の高い 2 つのサイトは、Core Web Vitals のパフォーマンスに従って順位が決まります。

Largest Contentful Paint（LCP）：読み込みの速さを測る

Largest Contentful Paint（LCP）は、ページ上で最も大きなコンテンツ要素がユーザーに見えるようになるまでにかかる時間を測ります。画像、動画、見出し、テキストのブロックなどが該当します。LCP は、ユーザーがメインのコンテンツを見て、ページが読み込まれたと感じる瞬間を測ります。

Google の推奨：LCP は 2.5 秒未満であるべきです。LCP が 2.5 秒未満のページは「良好」とされ、2.5〜4 秒のページは「改善が必要」、4 秒を超えるページは「不良」です。LCP が 3 秒を超えると、ユーザーはページを遅いと感じます。LCP が 4 秒を超えると、ユーザーはページを離れることが多くなります。

LCP が遅くなる主な原因：サーバーの応答時間の遅さ、レンダリングをブロックする CSS と JavaScript、最適化されていない画像、読み込みに時間のかかる大きなフォントです。LCP は次のように改善します。サーバーの速度を上げる（Time to First Byte / TTFB を短縮する）、レンダリングをブロックするリソースを取り除く、JavaScript を遅延させる、画像を最適化して圧縮する、最新の画像形式（WebP）を使う、重要なリソースをプリロードする。

PageSpeed Insights は、LCP のスコアと具体的な提案を示します。重要なページでテストを実行し、提案を影響の大きい順に優先づけして、最も効果の大きい修正から実施しましょう。

Cumulative Layout Shift（CLS）：視覚的な安定性を測る

Cumulative Layout Shift（CLS）は、ページの読み込み中に起こるページ要素の予期しない動きを測ります。記事を読んでいるときに、上に広告が読み込まれて突然テキストが下にずれる、これがレイアウトのずれです。CLS は、読み込み中にページのレイアウトがどれだけずれるかを数値化します。

Google の推奨：CLS は 0.1 未満であるべきです。CLS のスコアが 0.1 未満なら「良好」、0.1〜0.25 は改善が必要、0.25 を超えると「不良」です。小さなレイアウトのずれも積み重なります。CLS が 0.15 なら、読み込み中にページの要素がビューポートの高さの合計 15% 分ずれたことを意味します。ユーザーはこれを煩わしく感じ、いらだちます。

CLS が高くなる主な原因：非同期で読み込まれる広告、幅と高さの属性がない画像、非同期で読み込まれる埋め込み（YouTube の動画、ソーシャルメディアのウィジェット）、突然入れ替わるフォントです。CLS は次のように修正します。HTML で画像のサイズ（width と height の属性）を指定する、広告が読み込まれる前に領域を確保する、フォントの入れ替わりによる乱れを防ぐために @font-face の CSS で font-display: swap を使う、動画や埋め込みを同期的に、または領域を確保して読み込む。

サイト上のすべての画像には、明示的な width と height の属性を付けましょう。これにより、ブラウザーは画像が読み込まれる前に領域を確保できます。サイズがなければ、ブラウザーはどれだけの領域を確保すべきかわからず、画像が届いたときにレイアウトがずれます。

Interaction to Next Paint（INP）：応答性を測る

Interaction to Next Paint（INP）は、ページがユーザーの操作（クリック、タップ、キーボード入力）にどれだけ反応するかを測ります。INP は、ユーザーがページを操作してから、ページが視覚的に応答するまでの時間です。応答性の高いページはミリ秒で応答します。応答性の低いページは数秒かかります。

Google の推奨：INP は 200 ミリ秒未満であるべきです。200 ミリ秒未満のスコアは「良好」、200〜500 ミリ秒は改善が必要、500 ミリ秒を超えると「不良」です。ユーザーは即座の応答を期待します。INP が 500 ミリ秒だと、もたつくと感じます。INP が 1 秒だと、壊れていると感じます。

INP が悪くなる主な原因：メインスレッドをブロックする重い JavaScript、大きなサードパーティのスクリプト、非効率なイベントハンドラー、requestIdleCallback を使っていないことです。INP は次のように修正します。長い JavaScript のタスクをより小さなかたまりに分割する、重要でない JavaScript を遅延させる、使っていないスクリプトを削除する、イベントリスナーを最適化する、計算量の多いタスクには Web ワーカーを使う。

INP は、JavaScript の専門知識が必要なので、Core Web Vitals の指標の中で最も最適化が難しいことがよくあります。チームに JavaScript の最適化のスキルがなければ、パフォーマンスのコンサルタントを雇うか、サードパーティのパフォーマンス最適化のサービスを使うことを検討しましょう。

Core Web Vitals の測定方法

Core Web Vitals は、ラボデータとフィールドデータの 2 つの方法で測定されます。ラボデータは、PageSpeed Insights や Lighthouse などのツールを、管理された環境で実行して得られます。フィールドデータは、サイトを訪れる実際のユーザーから得られます。フィールドデータは実際のユーザー体験を表すので、Google はこちらを優先します。

Google のパフォーマンスの学習パスは、ラボの指標とフィールドの指標の違いを説明しています。ラボデータは問題を特定し、修正をテストする助けになります。フィールドデータは、実際のパフォーマンスを示します。実際のユーザーが遅い回線や古い端末を使っていれば、ラボのスコアは優れていても、フィールドのスコアは悪いことがあります。

Google Search Console は、Core Web Vitals のフィールドデータを報告します。このレポートは、Chrome ユーザー体験レポート（CrUX）から集計された実際のユーザーの測定値を示します。サイトの実際のユーザーのデータが不十分な場合は、代わりに Lighthouse のラボデータが提供されます。

基準値と合格のスコア

Google は、「良好」な Core Web Vitals を、ユーザー体験の 75 パーセンタイルが基準を満たすことと定めています。つまり、実際のユーザーの 75% が、基準値以上の体験をしているということです。基準値は次のとおりです。

LCP：2.5 秒以下。CLS：0.1 以下。INP：200 ミリ秒以下。これらの基準値は、何兆もの実際のユーザーの操作の分析によって科学的に検証されています。この基準値以上のページは、良いユーザー体験を提供します。

ただし、Google はすべてのページが Core Web Vitals に合格することを求めているわけではありません。ページの 75% が合格すれば、サイトは全体として「良好」な Core Web Vitals を持つとみなされます。つまり、一部に遅いページがあっても、トラフィックの大半を占めるページが速ければ合格できます。

各指標の最適化：実践的な手順

LCP の最適化：まず、PageSpeed Insights で TTFB（Time to First Byte）を測定します。TTFB が遅い（600 ミリ秒超）なら、サーバーがボトルネックです。ホスティングをアップグレードするか、バックエンドのコードを最適化するか、コンテンツ配信ネットワーク（CDN）を使いましょう。TTFB は良好なのに LCP が遅いなら、CSS か JavaScript がレンダリングをブロックしています。重要でない JavaScript を遅延させ、ファーストビューの重要な CSS をインライン化しましょう。

CLS の最適化：読み込み中に動く要素がないか、サイトを監査します。ブラウザーの開発者ツールで、ずれる要素を特定しましょう。すべての画像に width と height の属性を追加します。CSS で font-display: swap を使います。広告、埋め込み、動的なコンテンツの領域を確保しましょう。

INP の最適化：Chrome DevTools のパフォーマンスタブで、長い JavaScript のタスク（50 ミリ秒を超えるタスク）を特定します。長いタスクを分割します。重要でない JavaScript を遅延させます。優先度の低い処理には requestIdleCallback を使いましょう。デスクトップだけでなく、実際の端末でテストします。

Core Web Vitals を継続的に監視する

Google Search Console で Core Web Vitals のパフォーマンスを監視しましょう。Core Web Vitals のレポートは、サイトの実際のユーザーの指標と、Google の基準値との比較を示します。ページは「良好」「改善が必要」「不良」に分類されます。

監視のアラートを設定しましょう。Core Web Vitals が悪化したら、すぐに調査する必要があります。原因には、非効率を招いた新しいコードのデプロイ、新しいサードパーティのスクリプト、画像やメディアの変更、ホスティングの問題などが考えられます。

モバイルとデスクトップは別々に監視しましょう。モバイル端末は通常、プロセッサーも回線も遅いので、Core Web Vitals はデスクトップよりモバイルで悪いことが多くなります。モバイルのトラフィックが多いサイトは、モバイルの最適化を優先しましょう。

Core Web Vitals と SEO 戦略

Core Web Vitals は今や、被リンクやコンテンツの質に並ぶ重要度を持つ、中核の順位要因です。Core Web Vitals が悪いサイトは、コンテンツがどれだけ優れていても、上位に表示される可能性は低くなります。つまり、パフォーマンスの最適化は、後回しではなく SEO 戦略の一部でなければなりません。

順位を競っていて、競合のほうが Core Web Vitals が優れているなら、競合は順位で有利です。サイトが遅く応答しないなら、コンテンツだけでは勝てません。対等に競うには、競合のパフォーマンスに並ぶか、上回る必要があります。

まとめ

Core Web Vitals は今や、SEO の成功に欠かせません。LCP、CLS、INP を最適化すれば、検索順位とユーザー体験が直接改善します。Core Web Vitals が優れたサイトは、同じくらい関連性があるのに Vitals が悪いサイトを上回ります。避けて通れません。上位に表示されたいなら、Core Web Vitals に合格する必要があります。

まず、重要なページで PageSpeed Insights を実行しましょう。最大のボトルネックを特定し、そこから修正します。モバイルの最適化を優先します。Google Search Console でパフォーマンスを定期的に監視します。GEO SEO 診断で、サイト全体の Core Web Vitals の問題を見つけ、時間をかけて改善を追跡しましょう。