INPが厳しいのは、サイトが遅くなったからではない｜Google公式が語ったCore Web Vitalsの読み方

検索を学ぶ

INPへの移行で、それまで「良好」だったサイトが軒並み黄色や赤に変わりました。何もしていないのにスコアが落ちた、という体験をした人は多いと思います。

Googleの説明はシンプルです。指標が新しくなっただけで、サイトが急に遅くなったわけではない。 FIDが緩すぎたせいで見えていなかった問題が、INPによって可視化された、というのが実際に起きたことでした。

この記事では、公式ポッドキャスト「Search Off the Record」でページエクスペリエンスを扱った回から、Core Web Vitalsの読み方と、数値をどこまで追うべきかを整理しました。UXとCVRの話も含みます。

この記事は「Search Off the Record 全54回まとめ」のクラスタ記事です。他のテーマは元記事から辿れます。

Core Web Vitalsは何を測っているのか

第71回（2024-03-28）は、ChromeのRick Viscomi氏がゲストの回です。この記事の中心になります。

「vitals」は生命兆候という意味で、ページの健全性を測る核となる指標を指します。LCP・CLS・INPの3つがこれにあたり、TTFBなどは非コアですが重要な補助指標という位置づけです。

LCPについて興味深い補足があります。LCPは「視覚的に意味のあるコンテンツが表示されたか」を測る指標で、onloadのような裏側の完了ではなくユーザーが知覚する完了を測る点が特徴です。

ただし、LCP要素が常にユーザーにとって最重要とは限らないとも述べられています。例に挙がっているのがYouTubeで、ユーザーにとって重要なのは動画の再生開始であって、LCPが捉える要素とは必ずしも一致しません。文脈依存の指標も重要になる、ということです。

自社サイトで「ユーザーがそのページで待っているもの」がLCP要素と一致しているか、一度考えてみる価値があります。

FIDからINPへ — 指標が変わっただけ

INPが導入された経緯が、この回で明確に説明されています。

FID（First Input Delay） は、最初のインタラクションの遅延のみを測る指標でした。処理時間や次の描画までは含みません。その結果、ほぼ全サイトが「良好」と判定される緩すぎる指標になっていた、と。

INP（Interaction to Next Paint） は違います。全インタラクションを対象に、遅延・処理・次の描画までの全体レイテンシを測り、ほぼ最も遅いインタラクションを報告します。

つまり、INPで悪化したように見えるサイトは、もともと存在していた応答性の問題が見えるようになっただけです。指標が新しくなったからサイトが遅くなったわけではない、と明言されています。

移行前の第67回（2023-12-21）にも関連するやりとりがあります。Martin氏が自分のサイトのスコアが下がったことを報告した場面で、Johnが “You shouldn’t be optimizing for these metrics”（第67回、2023-12-21）と応じています。指標そのものを目標にするのではなく、ユーザーのために最適化すべきだ、という趣旨です。

注意: 第67回は移行前の収録で、INPは2024年3月に実際にFIDを置き換えました。第71回も収録から2年以上が経過しており、Core Web Vitalsの運用や指標の扱いに更新がある可能性があります。

PageSpeed Insightsの点数を、実ユーザー体験と混同しない

ここは誤解が多い部分だと思います。

PageSpeed InsightsのLighthouseスコアは、実ユーザーデータではありません。 スクロールもクリックもしないラボ環境（模擬環境）での、ワーストケースを想定した指標です。そのため、赤く低いスコアが出ても必ずしも実際のユーザー体験の悪さを意味しません。

第71回では、Lizzi氏がGoogleのドキュメントページをテストして45点（赤）が出た、という実例が紹介されています。

重視すべきはフィールドデータ、つまりCrUXのような実ユーザーデータのほうです。“What really matters is what your real users are experiencing.”（第71回、2024-03-28）

開発者の環境は、ユーザーの環境ではない

パフォーマンス測定はローカルでの目視確認では不十分で、実ユーザーデータ（RUM）をブラウザAPI経由で収集し、75パーセンタイルなどの分布で評価する必要がある、とされています。開発者のマシンは実ユーザーの環境と大きく異なるためです。

これに関連して、Facebookの「2G Tuesdays」が紹介されています。低速環境を意図的に体験することで開発者の共感を育て、パフォーマンス改善につながった実例です。

データの読み方にも罠がある

もう一つ、示唆的な事例が語られています。

YouTubeが低スペック端末向けにページを簡素化したところ、指標上は**「遅くなった」**という結果が出ました。原因はA/Bテストの母集団の偏りです。ページが軽くなったことで、それまで使えなかったより低速な環境のユーザーが新たに使い始めた。その結果、平均値が悪化して見えた、というわけです。

改善したのに数字が悪化する。KPIを設計する側にとって、覚えておく価値のある話だと思います。

Googlebotの体験と、ユーザーの体験は別

第71回で、SEO業界の誤解として名指しされている部分があります。

Googlebotのクロールは、ユーザーのクリックやスクロールのようなインタラクションを伴いません。 そのためINPのような指標は、Googlebotの体験には直接関係しません。Googlebotはページロードに対して忍耐強い、とも説明されています。

そのうえで、クロール速度の遅さとCore Web Vitalsの悪さを短絡的に結びつけるSEO業界の誤解があると指摘されています。「CWVが悪いからクロールされない」という説明は、少なくともこの回の内容とは食い違います。

ただし、Core Web Vitalsがランキングと無関係というわけではありません。SearchランキングチームがCore Web Vitalsを実際にランキングシステムで使用していることが、INP移行にあたる社内議論を通じて再確認され、ドキュメントにも明記されたと語られています。詳細な閾値などは非公開です。

整理すると、こうなります。

Core Web Vitalsの影響
ランキング実際に使用されている（閾値は非公開）
クロール速度直接の関係は示されていない
Googlebotの体験インタラクションを伴わないため、INPは直接関係しない

数値そのものを目的にしない

第71回では、マイクロ最適化への警告も出ています。

数値そのものへの過度な執着は、実際のSearchへの影響が小さい場合が多く、コンテンツ品質など他の要素を犠牲にしてまで追求すべきではないと明言されています。空白の高速ページが良い例にはならない、という言い方もされていました。

CMSの制約などでコントロールできない場合もあるので、完璧なスコアが取れなくても過度に心配しすぎないように、という補足もあります。

第63回（2023-08-22）にも同趣旨の説明があります。ページエクスペリエンスは個別指標（Core Web Vitalsなど）の達成度で判断するものではなく、**全体的なユーザー体験の良さという「マインドセット」**として捉えるべきだ、と。

この回はランキングシステムの呼称整理がテーマで、“we started talking about our ranking systems as opposed to ranking updates”（第63回、2023-08-22）という説明がされています。個別のシステムに名前を付けたのは、逆算してもらうためではありませんでした。ページエクスペリエンスの扱いも同じ発想です。

Core Web Vitalsについては、本質的にはアクセシビリティの問題に近い、という位置づけも語られています。ユーザーがサイト上でタスクを完了する「摩擦のない体験」を保証するためのものだ、と。

注意: 第63回は収録から約3年が経過しており、ランキングシステムの構成は変化している可能性が高い部分です。

原因を特定する方法

数値が悪いことは分かっても、何が原因かは別の話です。第71回では具体的なツールが挙げられています。

web-vitals.js ライブラリ を使うと、Core Web Vitalsの値だけでなく、どの要素・スクリプトが遅延の原因かという**属性データ（attribution）**も取得できます。

さらに Long Animation Frames API と組み合わせることで、原因調査ができるとされています。

スコアだけを見て改善案を出すより、attributionを取得してから手を付けるほうが確実です。

遅延読み込みとLCP

第98回（2025-08-21）は遅延読み込みを扱った回ですが、LCPに直結する内容が含まれています。

“if every image gets lazy loaded”（第98回、2025-08-21）——すべての画像に遅延読み込みを適用すると、すぐに表示されるべき画像まで遅延してしまいます。ファーストビューのヒーロー画像に loading="lazy" を付けると、ブラウザのリソーススキャナーによる早期読み込みが阻害され、LCPが悪化します。

Google自身のdevelopers.google.com/searchでも、全画像をデフォルトで遅延読み込みしてしまい、ヒーロー画像に影響していた事例が語られています。CMSが一括で設定するパターンで起きやすい問題です。

実装の詳細はレンダリング編で扱っています。

順位の外側 — UXとコンバージョン

第86回（2024-11-21）は、UX専門家のRio氏をゲストに迎えた回です。SEOとUX・CROの関係が議論されています。

SEOの最終目的はランキング向上だけでなく、ユーザーを顧客に転換することにある、というのがRio氏の立場です。

キーワードを削っても、順位は落ちなかった

この回でいちばん実用的なのがこの実例です。

“I recommended them to remove all the unnecessary keywords on that page”（第86回、2024-11-21）

クライアントのページでキーワードスタッフィングを解消したところ、可読性とCVRが改善し、ランキングへの悪影響はなかったという結果でした。キーワードスタッフィングはUXを損なうが、SEO（ランキング）への直接的な悪影響は必ずしもない、という整理です。

「順位が落ちるのが怖くて過剰なキーワードを外せない」という状況にある人には、判断材料になると思います。

UI要素の評価

  • カルーセル — ユーザーがあまりクリックせず情報が伝わりにくいため、UX上望ましくない。画像を並べて表示するほうがよい
  • アコーディオン（展開式コンテンツ） — FAQなど情報量が多い場合に有効。ただし重要情報を隠すと見落とされるリスクがある。SEO的には主要な答えが最初から見えていることが多いため大きな問題にはならない、とJohnが補足
  • 画像・GIF — 視覚的要素はコンテンツへの関与度を高め、CVR向上に寄与することがある。ただし点滅や一時停止不可といったアクセシビリティ面の懸念も指摘されています

コンバージョンをどう定義するか

ECサイトと違い、明確な購入ボタンがないドキュメントページのようなケースでは、コンバージョンの定義自体が難しくなります。

Rio氏の提案は、シェアボタンやコピーリンクのクリックを指標にすることでした。サムズアップ／ダウンの満足度評価も参考になりますが、ページの文脈による解釈が必要だとされています。例として、削除リクエストページの低評価はページの問題ではなくプロセス自体への不満が原因、という分析が挙がっていました。

ヒートマップ

ユーザーの読了範囲やクリック箇所を可視化でき、アナリティクスのスクロール率設定より直感的に把握できる、と推奨されています。

小規模サイトでもできるUXリサーチ

第85回（2024-10-31）は、GoogleのUXリサーチャーが小規模サイト向けの手法を解説した回です。予算がなくてもできることが整理されています。

“You are not your users.”（第85回、2024-10-31）——この一言がこの回の前提です。

ユーザーに話を聞く前にできること

いきなりインタビューをする必要はありません。ユーザーを介さない手法で、大きな問題を安価に発見できるとされています。

  • コグニティブウォークスルー — 想定ユーザー像を定義し、タスクごとに理想的な画面遷移を自分で追体験して問題点を洗い出す
  • ヒューリスティック評価 — コントラストやエラー予防といった業界標準の原則リストを、各画面に当てはめて確認する

学習リソースとして、Nielsen Norman Groupのウェブサイトが無料で有用だと紹介されています。

5人で足りる

定性調査（少人数インタビュー）は「なぜ」を知るのに有効で、定量調査（サーベイ）は問題の広がりや頻度を知るのに有効。両方を組み合わせるのが一般的とされています。

そして5人程度のインタビューでも十分な場合が多く、6人目以降の追加インサイトの価値は低下していく、と。

サンプルサイズについての注意もあります。回答率1%のような小さいサンプルは、単発の傾向把握には使えますが、時系列でのメトリクス追跡には信頼区間が大きすぎて不向きです。

データが少なくても、統計より先に人間の目で生データ（分布やタイミング）を見て観察することが有効な第一歩だ、という指摘もありました。満足度の平均値が3.5でも、賞賛者と批判者に二極化しているのか全員がまあまあなのかは分からない、という例です。

Googleが否定した通説

このクラスタで正式に否定リストに挙がっているのは4件です。ただし、いずれもページエクスペリエンスそのものではなく、同じ回で扱われた別テーマの項目になります。

通説Googleの説明出典鮮度
文字数が多いほど評価される文字数要件はどこにも定めていない第63回 2023-08-22要確認
著者情報（byline）は全ページに必須読者にとって意味がある場合のみ有効第63回 2023-08-22要確認
画像に透かしを入れるとGoogleに不利に扱われるペナルティを与えることはない第97回 2025-08-07要確認
自サイトに先にアップすればcanonical扱いになるそういう仕組みではない第97回 2025-08-07要確認

ページエクスペリエンスに関する実質的な訂正は、この記事の本文で扱ったものになります。特に以下の3点は、正式な否定リストには含まれていませんが、第71回で明確に指摘されている内容です。

  • 指標が新しくなったからサイトが遅くなったわけではない（FIDが緩すぎた）
  • PageSpeed Insightsのスコアは実ユーザー体験ではない
  • クロール速度の遅さとCore Web Vitalsの悪さを短絡的に結びつけるのは誤解

日本のサイト運営者にとって

このクラスタには、日本について具体的に言及された箇所があります。54エピソードを通しても数少ない例です。

第86回でRio氏が調査結果として紹介しているのは、日本のユーザーは英語圏に比べて画像・ビジュアル要素が多いコンテンツを好む傾向があるというものでした。日本語記事で画像を追加した記事と追加しない記事を比較し、画像入りのほうがエンゲージメント率が高かった、と。

一方で、ナビゲーション構造自体には大きな差は見られなかったとも述べられています。ここは重要で、「日本向けだから構造も変えるべき」という話にはなっていません。

この結果を実務に落とすなら、こうなります。

視覚要素の追加には根拠がある。 ただし第86回でも指摘されているとおり、GIFの点滅や一時停止不可といったアクセシビリティ上の懸念は別途考慮が必要です。また、画像を増やせばLCPに影響します。第98回の遅延読み込みの話と合わせて、ファーストビューだけは除外する設定が必要になります。

ナビゲーションは英語圏の標準から外す理由がない。 独自のUI設計を「日本向け」として正当化する根拠は、この調査からは出てきません。

そのほかの項目についても挙げておきます。

PageSpeed Insightsのスコアを報告指標にしている場合

ラボ環境の数値であることを共有しておいたほうがよさそうです。CrUXのフィールドデータに切り替えるか、両方を併記して性質の違いを明示するのが妥当だと思います。

キーワードを外せずにいる場合

第86回の実例が使えます。過剰なキーワードを削除しても順位は落ちず、可読性とCVRは改善しました。

UXリサーチに予算が付かない場合

第85回のコグニティブウォークスルーとヒューリスティック評価は、ユーザーを介さずに実施できます。インタビューも5人程度で十分とされています。

まとめ

ページエクスペリエンス関連で語られてきた内容を並べると、共通していたのは**「数値と体験を混同するな」**という一点でした。

INPで悪化して見えるのは、FIDが緩すぎて隠れていた問題が見えるようになったから。PageSpeed Insightsの赤い点数は、スクロールもクリックもしないラボ環境の想定値。改善したのにA/Bテストの数値が悪化することもある。そして、Googlebotはクリックもスクロールもしないので、INPが悪いからクロールされないという説明は成り立ちません。

その代わり、Core Web Vitalsがランキングシステムで実際に使われていることは明言されています。閾値は非公開ですが、無関係ではありません。

では何をすればいいか。web-vitals.jsのattributionで原因を特定する。ヒーロー画像を遅延読み込みから除外する。過剰なキーワードを外して読みやすくする。5人にインタビューしてみる。どれも、スコアを上げるためというより、実際に体験を良くするための行動です。 空白の高速ページが良い例にならない、という言い方が、たぶん一番分かりやすい線引きだと思います。

なお、この記事で「要確認」と付けた項目は、収録から時間が経っており仕様が変わっている可能性があります。実装を決める前には developers.google.com と web.dev の最新情報を確認してください。

関連記事