PageSpeed Insightsで100点を取ることは、それ自体が目的ではありません。しかし、100点を目指す過程で行う最適化は、確実にビジネス成果につながります。私たちが過去2年間で手がけたサイト改善の中で、PageSpeedスコアを90点以上に引き上げたケースでは、平均してコンバージョン率が23%向上しました。
この記事では、2024年3月に変更されたCore Web Vitalsの最新基準を踏まえながら、技術的な最適化手法を詳しく解説します。単なるスコア改善ではなく、実際のユーザー体験とビジネス成果につながる本質的な高速化を目指します。
2024年3月、Googleは指標を変えた
2024年3月12日、GoogleはCore Web Vitalsの構成指標を正式に変更しました。これまで使われていたFID（First Input Delay）が廃止され、代わりにINP（Interaction to Next Paint）が導入されています。この変更は単なる名称変更ではありません。測定の対象と基準が根本的に変わったのです。
FIDは「最初のインタラクション」だけを測定していました。ユーザーがページに到着して最初にボタンをクリックしたとき、そのクリックに対するブラウザの反応速度だけを評価していたのです。問題は、最初のクリックが速くても、2回目以降のクリックが遅いケースがあることでした。
INPはこの問題を解決するために導入されました。ページ滞在中のすべてのインタラクション（クリック、タップ、キー入力）を測定し、その中で最も遅いものを代表値として採用します。つまり、サイト全体を通じた応答性能が問われるようになったのです。
これにより、多くのサイトがスコアを落としました。FIDでは「良好」判定だったサイトが、INPでは「改善が必要」や「不良」になるケースが続出しています。古い最適化手法のままでは、もはや通用しません。
現在のCore Web Vitalsを正確に理解する
2024年以降のCore Web Vitalsは、3つの指標で構成されています。それぞれの意味と基準を正確に理解することが、効果的な最適化の第一歩です。
LCP（Largest Contentful Paint）は、ページの主要コンテンツが表示されるまでの時間を測定します。具体的には、ビューポート内で最も大きな画像、動画のポスター画像、または大きなテキストブロックが描画完了するまでの時間です。2.5秒以内であれば「良好」、2.5秒から4秒であれば「改善が必要」、4秒を超えると「不良」と判定されます。
日本の中小企業サイトを見ていると、LCPで問題を抱えているケースが最も多い印象です。特に、最適化されていない大きなヒーロー画像がLCPの遅延原因になっていることがよくあります。
INP（Interaction to Next Paint）は、ユーザーのインタラクションから次の画面更新までの時間を測定します。200ミリ秒以内であれば「良好」、200ミリ秒から500ミリ秒であれば「改善が必要」、500ミリ秒を超えると「不良」です。
この指標が厄介なのは、問題の特定が難しいことです。LCPやCLSと異なり、INPの問題はJavaScriptの実行に起因することがほとんどです。重いスクリプトがメインスレッドをブロックしていると、ユーザーのクリックに対する反応が遅れます。しかも、問題のあるスクリプトは必ずしも自社のものとは限りません。Google Analytics、広告タグ、チャットウィジェットなど、サードパーティのスクリプトが原因であることも多いのです。
CLS（Cumulative Layout Shift）は、ページ読み込み中にレイアウトがどれだけ動くかを測定します。0.1以下であれば「良好」、0.1から0.25であれば「改善が必要」、0.25を超えると「不良」です。
CLSの問題は、ユーザー体験を直接的に損ないます。読もうとした記事が突然ズレる、押そうとしたボタンが移動して別のリンクをクリックしてしまう。このような体験は、ユーザーの信頼を即座に失わせます。
約半数のサイトが基準を満たしていない
Chrome User Experience Report（CrUX）のデータによると、2024年時点でLCP、INP、CLSのすべてで「良好」を達成しているサイトは53%にとどまります。裏を返せば、47%のサイトが何らかの指標で基準を満たしていないということです。
これはチャンスです。競合の約半数がCore Web Vitalsの基準を満たしていないなら、自社サイトを最適化することで差別化できます。特に、INPは2024年3月に導入されたばかりの新指標であり、多くのサイトがまだ対応できていません。今から取り組めば、先行者利益を得られる可能性があります。
Googleは2021年からCore Web Vitalsを検索ランキング要因に組み込んでいます。ただし、その影響度は限定的だと言われています。しかし、ここで重要なのは検索順位への影響だけではありません。Core Web Vitalsの改善は、実際のユーザー体験の改善につながり、それがコンバージョン率や売上に反映されるのです。
売上に直結した企業事例
抽象的な話ではなく、実際の企業データを見てみましょう。これらの事例は、Googleのweb.devで公開されている実証データです。
Swappieはフィンランド発の中古スマートフォンECサイトです。同社はLCPを55%改善し、CLSを91%改善しました。その結果、モバイル売上が42%増加しました。42%という数字は驚異的です。サイトの内容やマーケティングを変えずに、技術的な最適化だけでこれだけの成果を上げたのです。
Vodafoneはイタリアの通信大手です。同社はLCPを31%改善した結果、売上が8%増加しました。Vodafoneのような大企業で8%の売上増加は、絶対額で見れば莫大な金額になります。
Yahoo! JAPANの事例も興味深いです。月間790億PVという巨大トラフィックを持つ同社は、CLSの問題を特定・修正した結果、セッションあたりのPVが15.1%増加し、セッション時間が13.3%延長され、直帰率が1.72%改善しました。
これらは「PageSpeedスコアが上がった」という話ではありません。「売上が増えた」「ユーザー行動が改善した」という実ビジネスの成果です。Core Web Vitalsの改善は、ビジネス成果に直結するのです。
LCP改善の実践的アプローチ
LCPは最も改善しやすい指標です。なぜなら、問題の原因が比較的特定しやすく、解決策も明確だからです。
まず、何がLCPの対象になっているかを特定します。Chrome DevToolsのPerformanceパネルでページをプロファイリングし、「LCP」というマーカーを探します。そこで特定された要素が、最適化の対象です。多くの場合、ヒーロー画像やファーストビューの大きな画像がLCPの対象になっています。
画像がLCPの対象である場合、最も効果的な改善策は画像の最適化です。JPEG画像をWebPやAVIF形式に変換するだけで、ファイルサイズを30〜50%削減できます。Next.jsやAstroなどのモダンなフレームワークを使っていれば、自動的に最適なフォーマットで配信してくれます。
さらに重要なのが、適切なサイズの画像を配信することです。1920px幅の画像をスマートフォンに配信しても意味がありません。srcset属性を使って、デバイスの画面サイズに応じた画像を配信するように設定します。これだけでモバイルでのLCPが大幅に改善されることがあります。
もうひとつの重要なポイントは、LCP画像のプリロードです。ブラウザはHTMLを上から順に解析していきます。LCP画像がCSSのbackground-imageで指定されていたり、JavaScriptで動的に挿入されている場合、ブラウザはその画像の存在を認識するのが遅れます。linkタグでpreload指定することで、ブラウザに「この画像を優先的に読み込んでほしい」と伝えることができます。
サーバー応答時間も見落とせません。いくら画像を最適化しても、サーバーが応答するまでに1秒かかっていてはLCPは改善しません。静的サイトであればCDNから直接配信することで、応答時間を10ミリ秒台に抑えることが可能です。
INP改善は難しいが、効果は大きい
INPの改善はLCPより難易度が高いです。問題の原因がJavaScriptにあることが多く、コードの内部動作を理解する必要があるからです。しかし、多くのサイトがまだ対応できていないため、取り組めば大きな差別化になります。
INPの問題は、ほとんどの場合、重いJavaScriptがメインスレッドをブロックしていることに起因します。ブラウザのメインスレッドは、HTML解析、スタイル計算、レイアウト、描画、そしてJavaScriptの実行を1本のスレッドで行っています。JavaScriptの実行に時間がかかると、その間ユーザーのインタラクションへの応答が遅れるのです。
まず確認すべきは、ファーストパーティ（自社）のJavaScriptです。不要なライブラリを読み込んでいないか、重い処理を同期的に実行していないかを確認します。特に、ページ読み込み時に実行される処理は、必要最小限に抑えるべきです。
次に確認すべきはサードパーティのスクリプトです。Google Analytics、広告タグ、チャットウィジェット、ソーシャルシェアボタン。これらのスクリプトは、それぞれは小さくても、積み重なると大きな負荷になります。本当に必要なものだけを残し、不要なものは削除することを検討してください。
どうしても必要なサードパーティスクリプトについては、読み込みタイミングの調整が有効です。async属性やdefer属性を使って非同期読み込みにする、ユーザーのスクロール後に読み込む、あるいはPartytownのようなライブラリを使ってWeb Workerに逃がすなどの手法があります。
CLS改善は予防が重要
CLSの問題は、一度発生すると修正が面倒なことがあります。むしろ、問題が発生しないように予防的なアプローチを取ることが重要です。
最も多いCLSの原因は、サイズ未指定の画像です。画像のwidth属性とheight属性を省略すると、ブラウザは画像のダウンロードが完了するまでサイズがわかりません。画像が読み込まれたときにスペースが確保され、周囲のコンテンツが押し下げられてレイアウトシフトが発生します。
解決策は単純で、すべての画像にwidth属性とheight属性を指定することです。実際のピクセル値を指定する必要はありません。アスペクト比を示す値であれば十分です。CSSでwidth: 100%とheight: autoを指定していれば、ブラウザはアスペクト比を維持したまま画像をリサイズします。
Webフォントも要注意です。カスタムフォントが読み込まれるまでの間、ブラウザはフォールバックフォントで描画します。カスタムフォントが読み込まれると、文字の大きさや行間が変わり、レイアウトシフトが発生することがあります。font-display: swapを指定しておくと、フォントの読み込み完了を待たずにフォールバックフォントで描画し、読み込み完了後に差し替えます。この際にわずかなレイアウトシフトが発生する可能性がありますが、テキストが表示されないよりはマシです。
動的に挿入されるコンテンツにも注意が必要です。広告、バナー、Cookie同意ダイアログなどが遅延して挿入されると、周囲のコンテンツが押し下げられます。これらの要素には、あらかじめスペースを確保しておくことが重要です。
日本のサイトが直面する固有の課題
日本語サイトには、欧米のサイトにはない固有の課題があります。特に深刻なのがWebフォントの問題です。
日本語フォントは、数千から数万の文字を含むため、ファイルサイズが非常に大きくなります。Noto Sans JPの全ウェイト（100〜900）を読み込むと、合計で10MBを超えることもあります。これは英語フォントの数十倍のサイズです。
対策としては、まず必要なウェイトだけを読み込むことです。本文用に400、見出し用に700など、実際に使うウェイトだけに絞ります。次に、サブセット化を検討します。サイトで使用する文字だけを抽出したフォントファイルを作成することで、ファイルサイズを大幅に削減できます。Google Fontsを使用している場合は、textパラメータで使用する文字を指定することで、自動的にサブセット化されます。
もうひとつの日本特有の課題は、モバイルの重要性です。日本では検索の82%がモバイルデバイスから行われています。これは世界的に見ても高い水準です。PageSpeed Insightsのデスクトップスコアが100点でも、モバイルスコアが50点では意味がありません。常にモバイルを優先して最適化してください。
100点は手段であって目的ではない
PageSpeed Insightsで100点を取ることは、それ自体に意味があるわけではありません。重要なのは、その過程で行った最適化がユーザー体験を向上させ、ビジネス成果につながることです。
しかし、100点を目指すことには意味があります。明確な目標があると、何をすべきかが見えてくるからです。100点を目指す過程で、サイトの構造を見直し、不要なコードを削除し、画像を最適化し、サードパーティスクリプトを整理する。これらの作業は、すべてユーザー体験の向上につながります。
私たちが手がけたサイトの中で、PageSpeedスコアを40点台から95点に改善したケースがあります。そのサイトでは、問い合わせフォームのコンバージョン率が34%向上しました。スコアの改善がビジネス成果に直結した好例です。
まずは現状を把握することから始めてください。PageSpeed Insights（pagespeed.web.dev）で自社サイトを診断すれば、どの指標に問題があるかがわかります。そこから、優先順位をつけて改善に取り組んでいきましょう。
私たちは、サイトの現状診断を無料で実施しています。PageSpeedスコアだけでなく、Core Web Vitalsの各指標、改善のための具体的な施策、期待される効果まで、詳しくレポートをお伝えします。