まず結論から言うと…
モバイルファーストインデックスのパフォーマンス改善って、結局のところ、ただコアウェブバイタル（CWV）のスコアを良くするだけの話じゃないんですよね。もっと根本的な、Googlebotがどうやってサイトを見てるかっていう視点が必要。個人的にはそう思ってます。
ボットがページをクロールして、レンダリングして、内容を理解する。この一連の流れがスムーズじゃないと、いくら見た目のスコアが良くても、大事なコンテンツがインデックスされないかもしれない。 特に、スマホサイトのコンテンツがPCより極端に少ないとか、そういう基本的な部分が一番危ない。
みんなCWVの話ばかりだけど、それだけじゃない
最近の記事は、LCPだ、INPだ、CLSだって、コアウェブバイタルの話ばっかり。 もちろん、それはすごく大事。表示が遅かったり、操作中にレイアウトが崩れたりしたら、ユーザー体験は最悪だから。Googleがこれをランキング要因にするのも当然。
でも、忘れてはいけないのが、評価の主体はまず「Googlebot Smartphone」だということ。 人間のユーザーが見る前に、ボットがサイトの構造とコンテンツを正しく把握できなければ、話が始まらないんです。
例えば、重いJavaScriptが原因でレンダリングが遅れると、ボットはページの全体像を掴むのを諦めて、一部の情報だけでインデックスしてしまうかもしれない。 これは、Googleの公式ドキュメントでも示唆されていて、クロールにはリソースの制限（クロールバジェット）があるとはっきり書かれています。 日本の多くのSEO解説ブログではCWVの改善方法に焦点が当たりがちだけど、この「ボットから見たパフォーマンス」という視点は、もっと意識されていいと思うんです。
じゃあ、具体的に何をすればいいのか
じゃあ、ボットにもユーザーにも優しいサイトにするために、何をすべきか。まあ、基本はやっぱりCWVの最適化に行き着くんですが、少し視点を変えて考えてみます。
- LCP (Largest Contentful Paint) の改善: これは「メインコンテンツがどれだけ速く表示されるか」。 LCPの要素、大抵はヒーロー画像とか大きなテキストブロックですが、これがHTMLのできるだけ早い段階で特定できるようにするのが大事。 JavaScriptで後から挿入したりすると、発見が遅れる原因になります。 画像なら、WebPやAVIFみたいな次世代フォーマットを使うのはもう常識ですね。
- INP (Interaction to Next Paint) の改善: 2024年3月からFIDに代わって導入された新しい指標。 これは「クリックやタップへの応答性」です。 ユーザーがボタンを押したのに、画面が固まったりすると最悪。原因の多くは、重たいJavaScriptの処理。 長い処理は、`setTimeout`とか`requestIdleCallback`を使って分割したり、後回しにできないか検討するのがセオリーです。
- CLS (Cumulative Layout Shift) の改善: これは「読み込み中のレイアウトのズレ」。画像や広告が表示された瞬間にテキストがガクッと動く、あれです。画像には`width`と`height`（または`aspect-ratio`）を必ず指定する、広告のような後から読み込まれる要素には、あらかじめ表示領域を確保しておく、といった地道な対策が効きます。
これらの作業は、PageSpeed Insightsとか、Chromeのデベロッパーツールを使えば、どこがボトルネックになってるか分かります。
ありがちな間違いと、効果の薄い最適化
良かれと思ってやったことが、実は逆効果だったり、あまり意味がなかったりすることも。いくつか考えてみました。
- LCP要素まで遅延読み込み（Lazy Loading）する: 画像の遅延読み込みは基本だけど、ファーストビューに見えてるLCP対象の画像まで遅延させると、当然LCPのスコアは悪化します。単純なミスだけど、意外とよく見かけます。
- ひたすら画像を圧縮する: 画像サイズの最適化は重要。でも、画像のせいで遅いんじゃなくて、巨大なJavaScriptライブラリが原因ってことはよくあります。根本原因を見ないと、努力が無駄になることも。
- ラボデータだけ見て満足する: PageSpeed Insightsのスコア（ラボデータ）が良くても、実際のユーザー環境（フィールドデータ）では遅い、というケースはザラにあります。 大事なのは、Chrome User Experience Report (CrUX) に基づくフィールドデータの方。サーチコンソールの「ウェブに関する主な指標」レポートで、実際のユーザー体験を確認することが不可欠です。
LCPとINP、どっちを優先？まあ、両方なんだけど…
時間もリソースも限られてる中で、どっちから手をつけるべきか。まあ、理想は両方なんですけど、あえて整理してみました。
| 指標 | 何を見ているか | よくある原因 | 個人的なメモ |
|---|---|---|---|
| LCP | ページの主要コンテンツが表示されるまでの時間。 体感的な読み込み速度。 | ・サーバーの応答が遅い ・CSSやJavaScriptによるレンダリングブロック ・巨大な画像や動画ファイル |
こっちは「速さ」の話。サイトの第一印象を決めるから、悪いとすぐ離脱されちゃう。まずここを良くしないと、INPの土俵にすら立てないかも。 |
| INP | ユーザーのアクション（クリック等）から、次の描画が始まるまでの時間。 応答性。 | ・実行に時間のかかるJavaScript ・メインスレッドのブロック ・巨大なDOMツリーの更新 |
こっちは「快適さ」の話。FIDの後継。 Eコマースサイトとかで「購入」ボタンが反応しなかったら致命的。ユーザーにストレスを与える一番の原因になりやすい。 |
最後にちょっとした質問
ここまで色々書いてきましたが、皆さんのサイトではどうでしょう？もし今、自分のサイトのパフォーマンスを一つだけ改善するとしたら、LCP（表示速度）とINP（応答性）、どちらの問題に先に取り組みますか？理由と一緒に、もしよければコメントで教えてください。
