コアウェブバイタル悪化を切り分ける5つの手順

Search Console が「低速」と言ってきた。でも、心当たりのある変更は何もしていない。——そのとき最初に疑うべきなのは、ページの中身ではなくレポートの読み方です。

ウェブに関する主な指標（コアウェブバイタル）のレポートは、URL を1本ずつ採点しているわけではありません。Search Console ヘルプによれば、このレポートは「実際のユーザーデータで測定される3つの指標」に基づき、ステータス（低速・改善が必要・良好）別、指標タイプ別、そして「URL グループ（類似するウェブページのグループ）」別に結果を示します。データ源は CrUX レポート、つまり実際に利用者がその URL を訪れたときの記録を匿名化したもの（フィールド データ）です。

つまり、あなたのコードだけが動かしている数字ではありません。

レポートが「悪化した」と言うとき、動いている可能性は3つある

同じヘルプには、ステータスが変わる理由として、クライアント側の大規模な変化が挙げられています。広く使われているブラウザのバージョン更新や、低速のネットワークを使うユーザーの増加です。さらに、数値が「低速・改善が必要・良好」の境界上にある場合は、小さな変化でもステータスが変わる原因になった可能性がある、とも書かれています。

だから、悪化の通知を見たときに考えられる筋は少なくとも3つあります。ページを本当に重くしてしまった場合、境界のすぐそばにいて小さく揺れた場合、そして測られる相手（利用者の環境）が変わった場合です。この3つは対処がまったく違います。1つめは直す、2つめは余裕を作る、3つめは慌てない。

先に手を動かす前に、どれなのかを決めます。

切り分けの5ステップ

1. どの指標が悪いのかを1つに絞る。 レポートは指標タイプ（CLS・INP・LCP）別に見られます。3つの意味は、LCP＝主要な中身が表示されるまでの読み込みの速さ、INP＝クリックやタップへの反応の速さ、CLS＝読み込み中に画面がどれだけズレるか、です。ここで大事なのは、グループの見え方の癖。ヘルプには、URL グループのデータ量が LCP と CLS の両方でしきい値に達すると、そのグループのステータスは「最もパフォーマンスの低い指標のステータスになる」とあります。例として挙げられているのは、CLS が低速で INP が良好なら URL ステータスは「低速」になる、というものです。悪いのは1つだけかもしれません。
2. 目安からの距離を測る。 Google の公式ドキュメントは、主要な指標として「LCP は2.5秒未満、INP は200ミリ秒未満、CLS は0.1未満」を挙げています。自分の数値がこの線からどれだけ離れているかを見てください。2.6秒と5.0秒では、同じ「良好ではない」でも意味が違います。境界のすぐ内側にいるなら、次に揺れたときもまた同じ通知が来ます。
3. 特定の URL を診断したいなら、レポートの外に出る。 ここは誤解されやすいところです。ヘルプは、このレポートが「特定の URL のステータスを検出するためではなく、サイトの全体的なパフォーマンスを確認して、サイトの複数のページに影響を与える問題のトラブルシューティングを行うために設計されている」と明記しています。特定の URL のパフォーマンスデータを確認するには外部テストを使うように、とも書かれています。1本の記事の重さをレポートの画面から読み取ろうとして時間を溶かさないでください。
4. 悪化の時期と、自分の変更履歴を突き合わせる。 ヘルプが示す確認方法は、ログをチェックして、ユーザーのブラウザ・デバイス・場所に変化があった時期とサイトのステータスが変化した時期が一致するかを見ること、そしてその時期のサイトのトラフィックデータに急激な変動がないかを確認することです。公開日・テンプレート改修日・広告タグの追加日を並べると、たいてい原因の候補は2つか3つに減ります。
5. グループ全体として直せるかを考える。 URL グループは、ユーザー体験が似たページをまとめたものです。ヘルプには、これらのグループには共通のフレームワークがあり、グループのパフォーマンスが低い原因は同じ根本原因によるものである可能性が高い、と想定されている旨が書かれています。1本ずつ直すより、共通のテンプレートを1回直すほうが早いことが多いのは、この構造から来ています。

実際に1回通してみる

たとえば、記事一覧と個別記事を持つ自社ブログで、「記事詳細」のグループが CLS で「改善が必要」に落ちたとします。

ステップ1で、悪いのは CLS だけだと分かる。読み込みの速さと反応の速さは良好のままです。ステップ2で数値を見ると、0.11。目安の0.1をわずかに超えただけでした。ここで「サイトが重い」という話に飛ばないことが肝心です。

ステップ3では、グループの中で気になる記事を数本選び、外部テストにかけます。ステップ4で時期を突き合わせると、2週間前に記事上部へ差し込んだお知らせバナーの追加と重なっていた。バナーは読み込みが終わってから挿入され、その分だけ本文が下に押し出されます。

ステップ5の判断はこうなります。直す対象は記事1本ではなく、バナーを差し込んでいるテンプレート。押し出しが起きないように、あらかじめ場所を確保しておく作りに変えれば、同じグループの記事すべてに一度で手が届きます。直したあとは、同じ差し込みが他のテンプレートにも残っていないかを見ておきます。

なお、ヘルプに書かれているグループの読み方には、もう一段の注意があります。グループ内の一部の URL は、アクセスによって表示より良い値にも悪い値にもなり得るが、グループ内のすべての URL へのアクセスの75%は表示されるグループのステータスに該当する、という説明です。平均ではなく、多数派の体験だと思っておくとズレません。

状況別の判断表

1行目は、さきほどの CLS 0.11 がまさにこれです。焦って全ページを触るより、押し出しの起きない作りに変えて余白を取り戻すほうが、次の揺れにも効きます。2行目のように改修と一致していれば話は早い。3行目は、自分のサイトの外側が動いた可能性を含むので、直す前に照合が要ります。4行目は、1本ずつ潰す罠に一番はまりやすい形です。そして5行目。戻ったあとに監視を外してしまうと、同じ改修がどこかで復活したときに気づけません。

よくある誤解：悪化＝順位が落ちる、ではない

ここは弱めに、しかしはっきり書いておきます。

公式のよくある質問には、ランキングに使われる単一の「ページ エクスペリエンス シグナル」は無く、コアランキングシステムは全般的なページ体験を示すさまざまなシグナルを評価する、とあります。同じページには、Google のランキングシステムでは Core Web Vitals が使用される、とも書かれています。使われていないわけではありません。単独の決め手ではない、という位置づけです。

さらに公式は、Google 検索はページ体験が平均を下回るコンテンツも含め、常に最も関連性の高いコンテンツが表示されるように設計されている、と述べています。2020年の公式ブログにも、ページ体験の一部の要素が平均以下であっても、総合的に優れた情報を含むページが優先される、という記述があります。評価の単位についても、コアランキングシステムは一般的にコンテンツをページ限定で評価し、ただしサイト全体での評価も一部実施している、と説明されています。

読み替えるとこうなります。1つのテンプレートの CLS が悪いからといって、サイト全部が沈むという話ではない。逆に、数字を良好にしたら順位が上がるという交換条件でもありません。順位が動かない理由の整理はページ速度を改善しても順位が変わらない理由にまとめています。

もう一つの誤解：FID の記憶で止まっている

古い記事を参考にしていると、反応の速さの指標として FID の名前が出てくることがあります。公式ブログの更新記録では、2024年3月12日に Interaction to Next Paint（INP）が FID に代わって Core Web Vitals に組み込まれた、と告知されています。手元のチェックリストが FID のままなら、そこは INP に置き換えてください。

測定に使う道具も公式が示しています。2020年のブログでは、Lighthouse や PageSpeed Insights といったデベロッパー ツールを更新して Core Web Vitals の情報と改善案を表示できるようにした、と書かれています。ステップ3の「外部テスト」は、この系統の道具のことだと考えて差し支えありません。

手を入れる前の自己点検

• 悪いのは3指標のうちどれか、1つに絞れているか。絞れていないなら、グループのステータスが最も悪い指標に引きずられていないかを疑う。
• 目安（2.5秒／200ミリ秒／0.1）からどれだけ離れているか、数字で言えるか。
• 特定の URL の話をしているのに、レポートの画面だけで判断していないか。外部テストを通したか。
• 悪化の時期と、自社の改修・タグ追加・デザイン変更の日付を並べたか。
• 直す対象は1ページか、テンプレートか。同じグループの他のページにも同じ症状が出ていないか。
• 効果確認を、手元のテスト結果だけで済ませていないか。

最後の項目は見落としやすいところです。レポートが見ているのは、自分の手元での測定結果ではなく、実際に利用者がその URL を訪れたときの記録でした。手元のテストで速くなったことと、レポートの評価が動くことは別の話だと考えておくほうが安全です。数字の読み取りに迷ったときは、他の指標も合わせて見る点検が要ります。数字が動いたときの手順はSearch Console のクリック数が減ったときの点検リストが使えます。