まず結論から言うと
ページ速度の最適化って、もう「速ければいい」って話じゃないんですよね。要は「ユーザーがどう感じるか」。これが全て。で、Googleがそれに合わせて出してきたのがCore Web Vitals。LCP、CLS、そして最近FIDから変わったINP。 この3つを意識するのがマジで大事。スコア100点を目指すゲームじゃなくて、ユーザーの体感を良くする活動、そう捉えるべき。
だから、まずやるべきは「計測」。自分のサイトが今、この3つの指標でどう見られてるのかを知るところから。話はそれからです。
じゃあ、どうやるの？実践手順
OK、じゃあ具体的な手順。まあ、大きく分けて3ステップかな。計測→優先順位付け→改善。このサイクルを回していく感じ。
ステップ1：計測フェーズ
まず現状把握。ここで使うツールがいくつかある。
- PageSpeed Insights (PSI): 一番手軽。URL入れるだけで、フィールドデータ（実際のユーザー環境）とラボデータ（仮想環境でのテスト）の両方を見せてくれる。 まずはこれで全体像を掴むのがおすすめ。
- Chromeのデベロッパーツール: 自分のPCで、もっと細かく見たいとき。特に「Performance」タブは、何がページの表示をブロックしてるか、滝のように（ウォーターフォールって言うけど）表示してくれるから原因特定に便利。
- Search Console: Core Web Vitalsのレポートがあって、サイト全体でどのURLが「不良」判定受けてるか一覧でわかる。 どこから手をつけるべきか、これ見れば一目瞭然。
あ、そうだ。フィールドデータとラボデータの違いは意識しといた方がいい。ラボデータが良くても、実際のユーザー（例えば電波の悪い場所にいる人）の体験は悪い、なんてことはザラにあるから。
ステップ2：優先順位付けフェーズ
計測すると、改善点が山ほど出てくる。全部やろうとすると死ぬ。だから優先順位が大事。僕がよくやるのは「インパクト（効果の大きさ）」と「エフォート（実装の手間）」でマッピングする方法。
- インパクト大・エフォート小: 真っ先にやるべきこと。例えば、巨大な画像の圧縮とか。
- インパクト大・エフォート大: 計画的に取り組む。サーバーの応答速度改善とか、根本的なJavaScriptの書き直しとか。
- インパクト小なもの: とりあえず後回し。気にしすぎない。
特にLCPに影響してるヒーロー画像、CLSを引き起こしてる広告スペース、INPを悪化させてる重いJavaScriptあたりが、だいたいインパクト大きいことが多いかな。
ステップ3：改善フェーズ
いよいよ改善作業。指標ごとに代表的な打ち手をいくつか。
- LCP (Largest Contentful Paint) 改善:
- 画像の最適化: これが一番効くことが多い。 表示に必要なサイズで配信する、WebPみたいな次世代フォーマットを使う、あとは遅延読み込み（lazy loading）も。
- サーバーの応答時間短縮: TTFB (Time to First Byte) とも言うけど、サーバーがリクエストに素早く応えるのは基本中の基本。 CDNの導入も有効。
- CLS (Cumulative Layout Shift) 改善:
- 画像や広告にサイズ指定: `width`と`height`をちゃんと指定するだけで、後から読み込まれてガクッてなるのを防げる。 簡単だけど効果絶大。
- 動的にコンテンツを挿入しない: 「ここにバナーを挿入」みたいなことをユーザーが見ている上部でやると、レイアウトが崩れて最悪。やるなら下に。
- INP (Interaction to Next Paint) 改善:
- JavaScriptの分割: 長いタスクは分割する。ブラウザが他の操作（クリックとか）を受け付ける余裕を作るため。
- 不要なJavaScriptの削除: もう使ってない昔のタグとか、意外と残ってたりする。大掃除が大事。
特に2024年3月からFIDに代わって導入されたINPは、クリックやタップへの反応性を見る指標。 ユーザーが「なんかこのサイト、クリックしても反応鈍いな」と感じさせないために、JavaScriptの処理を見直すのが中心になりますね。
ツールの使い分け、どうしてる？
測定ツールはいっぱいあるけど、それぞれ得意なことが違う。 目的によって使い分けるのが賢い。僕なりの使い分けはこんな感じ。
| ツール名 | 良いところ | イマイチなところ | いつ使う？ |
|---|---|---|---|
| PageSpeed Insights | 実際のユーザーデータ（CrUX）が見れるのが神。 合格・不合格がパッとわかる。 | 毎回結果がちょっとブレる。ラボデータはあくまで参考値。 | 「まず健康診断」って感じで、定期的にサイト全体の状況を見るとき。 |
| Chrome DevTools (Performance) | 原因究明の鬼。どの処理に何ミリ秒かかってるか、全部見える。 | 見方が難しい。初心者だと情報過多で溺れるかも。あと自分の環境に依存する。 | PSIで「要改善」が出たとき、「じゃあ具体的に何が原因？」を掘り下げるとき。 |
| WebPageTest | 世界中のいろんな場所から、いろんな回線速度でテストできる。動画で表示過程も記録してくれる。 | 多機能すぎて、最初はちょっと戸惑うかも。無料版は順番待ちになることも。 | 「海外からのアクセスだとどう見える？」とか、特定の条件下での挙動を確認したいとき。 |
海外の話で言うと、Googleの `web.dev` のようなグローバルな情報はすごく参考になるけど、日本の事情に合わせる視点も必要。例えば、日本では特定のスマホキャリアの通信特性とか、よく使われる広告ネットワークがパフォーマンスに与える影響とか、そういうローカルな視点でボトルネックを探すこともあります。一概に「この手法がベスト」とは言えないのが面白いところ。
よくある失敗と注意点
ありがちなのが、「スコア100点教」に入信しちゃうこと。PSIで100点を取ることが目的化しちゃう。でも、それって意味ないことが多い。さっきも言ったけど、大事なのはユーザーの体感。スコア90でも体感が良ければそれでOK。
もう一つは、トップページだけ最適化して満足しちゃうこと。でも、ユーザーはブログ記事とか商品詳細ページに直接来ることの方が多い。Search Consoleのレポートを見て、トラフィックが多いのに遅いページから手をつけるのが正解。
まとめというか、今後の話
ページ速度の最適化は、一度やったら終わりじゃない。新しいコンテンツを追加したり、新しい広告タグを入れたりするたびに、パフォーマンスは変わるから。だから、最初に話した「計測→優先順位付け→改善」のサイクルを地道に回し続けることが、結局一番の近道なんだと思う。
特にINPが新しい指標になったことで、これからは「見た目の速さ」だけじゃなく「操作したときの快適さ」がもっと重要になる。 JavaScriptとの付き合い方が、これまで以上に問われる時代になったってことですね。
それで、皆さんに質問です。あなたのサイトで一番のボトルネックになってるのは、LCP、CLS、INPのどれですか？ もし分かれば、コメントで教えてもらえると嬉しいです！
