ページスピード改善ガイド｜PageSpeed Insightsの見方と高速化施策【2026年版】

「サイトが遅い」と感じた時点で、ユーザーは離脱しています。

Googleの調査によれば、ページの読み込みに3秒以上かかると、モバイルユーザーの53%がそのページを離れます。 さらに厳しいのは、ページスピードがSEOのランキング要因として明確に組み込まれているという事実です。

どんなに質の高いコンテンツを用意しても、表示が遅ければユーザーには届きません。 検索順位でも不利になり、コンバージョンも下がる。ページスピードの問題は、サイト運営における「静かな損失」です。

この記事では、ページスピードがSEOに与える影響、PageSpeed Insightsの正しい読み解き方、具体的な改善施策10選、さらにWordPressサイトに特化した高速化手法まで、実務で使えるレベルで解説します。

なお、SEO対策の全体像についてはSEO対策とは？初心者でもわかる完全ガイドで体系的にまとめています。ページスピードは内部対策（テクニカルSEO）の一部です。内部対策全般を把握したい方はSEO内部対策チェックリストもあわせてご確認ください。

ページスピードがSEOに与える影響

ページスピードは、単なる「ユーザーの快適さ」の問題ではありません。 Googleが公式にランキング要因として扱っている、数少ない明示的なシグナルの一つです。

Googleのスピードアップデートと順位への影響

Googleは2018年に「Speed Update」を導入し、モバイル検索においてページの読み込み速度をランキング要因に加えました。 さらに2021年には、Core Web Vitals（コアウェブバイタル）がランキング要因に正式に組み込まれています。

Core Web Vitalsは3つの指標で構成されています。

2024年3月にFID（First Input Delay）がINP（Interaction to Next Paint）に置き換わり、2026年現在はこの3指標が基準です。

Core Web Vitalsの詳細な解説はCore Web Vitalsとは？3つの指標と改善方法にまとめています。

直帰率・CVRへの影響は数字で見えている

ページスピードの影響は、SEO順位だけにとどまりません。

Googleが公開しているデータによると、ページの読み込み時間が1秒から3秒に伸びると直帰率は32%増加します。 1秒から5秒なら90%増加。1秒から10秒なら123%増加です。

ECサイトのデータでは、表示速度が0.1秒改善するだけでコンバージョン率が8%向上したという報告もあります。 つまり、ページスピードの改善は「SEOのため」だけではなく、売上に直結する施策です。

モバイルファーストインデックスとの関係

2026年現在、Googleはすべてのサイトをモバイルファーストインデックス（MFI）で評価しています。 つまり、デスクトップ版ではなくモバイル版のページ速度が、ランキングに影響するということです。

モバイル回線は固定回線より遅く、端末のスペックもPCより低い。 そのため、モバイル環境でのページスピード改善は、デスクトップ以上に優先度が高いといえます。

PageSpeed Insightsの見方と読み解き方

ページスピードの現状を把握するために最も使われるツールが、Googleが無料で提供している「PageSpeed Insights」です。 URLを入力するだけで、ページのパフォーマンスを100点満点で採点してくれます。

ただし、このスコアの意味を正しく理解していないと、的外れな改善に時間を費やすことになります。

スコアの仕組みと評価基準

PageSpeed Insightsのスコアは、以下の色分けで表示されます。

このスコアは、Lighthouseというオープンソースの監査ツールが算出しています。 スコアの内訳は、以下の5つのメトリクスの加重平均です。

注目すべきは、TBT（Total Blocking Time）の配点が30%と最も高いことです。 TBTはメインスレッドがブロックされた合計時間を示すラボデータの指標で、JavaScriptの実行効率に大きく左右されます。

フィールドデータとラボデータの違い

PageSpeed Insightsには2種類のデータが表示されます。この違いを理解していないと、改善の方向性を間違えます。

フィールドデータ（実際のユーザーデータ）

Chromeユーザーの実際のアクセスデータを集計したものです。CrUX（Chrome User Experience Report）と呼ばれるデータセットから取得されます。 実際のユーザーが体験しているパフォーマンスを反映しているため、信頼性が高いデータです。 ただし、十分なトラフィックがないサイトでは表示されません。

ラボデータ（シミュレーションデータ）

Lighthouseがシミュレーション環境でページを読み込み、測定した結果です。 毎回の測定条件が統一されているため、改善の前後比較に適しています。 ただし、実際のユーザー体験とは乖離する場合があります。

SEOのランキングに影響するのはフィールドデータ（Core Web Vitals）です。 ラボデータのスコアは、あくまで改善作業のための参考指標として活用してください。

「改善できる項目」と「診断」の読み方

スコアの下に表示される「改善できる項目（Opportunities）」と「診断（Diagnostics）」は、具体的に何を改善すべきかを示しています。

改善できる項目（Opportunities） は、読み込み時間を短縮するための提案です。 各項目に「推定節約時間」が表示されるため、節約時間が大きい項目から優先的に対処するのが効率的です。

主な項目を挙げます。

• 適切なサイズの画像を配信してください（Properly size images）
• 次世代フォーマットでの画像の配信（Serve images in next-gen formats）
• レンダリングを妨げるリソースの除外（Eliminate render-blocking resources）
• 使用していないJavaScriptの削減（Reduce unused JavaScript）
• 使用していないCSSの削減（Reduce unused CSS）

診断（Diagnostics） は、ページの技術的な詳細情報です。直接的に速度を改善する項目ではありませんが、パフォーマンスに影響する可能性のある設計上の問題を指摘します。

スコアに振り回されない判断基準

PageSpeed Insightsのスコアは、測定のたびに数点の変動があります。 ラボデータはシミュレーション環境であるため、サーバーの負荷状況やネットワーク環境によって結果が変わるからです。

したがって、「スコアを100点にする」ことを目標にすべきではありません。

実務的な判断基準は以下の通りです。

• フィールドデータのCore Web Vitals 3指標がすべて「Good（良好）」であること
• ラボデータのスコアが50以上であること（理想は70以上）
• 「改善できる項目」で推定節約時間が大きいものを優先して対処すること

スコア90を95にする労力は、スコア30を60にする労力よりはるかに大きく、SEO的なリターンも小さい。費用対効果を意識して取り組みましょう。

ページスピードを改善する10の施策

ここからは、実際にページスピードを改善するための具体的な施策を解説します。 効果が大きい順に並べているので、上から順に対処していくことをおすすめします。

施策1: 画像の最適化

ページスピード改善で最も効果が大きいのが画像の最適化です。 多くのWebサイトにおいて、画像はページ全体の転送量の50%以上を占めています。

やるべきこと

まず、画像フォーマットをWebPまたはAVIFに変換してください。 JPEGやPNGと比べて、WebPなら25〜35%、AVIFなら最大50%ファイルサイズを削減できます。

次に、画像のサイズを表示サイズに合わせてリサイズします。 幅1200pxで表示する箇所に幅4000pxの画像を使っているケースは非常に多い。表示に必要なサイズの2倍（Retina対応）を上限として、それ以上は無意味な転送です。

さらに、レスポンシブ画像を設定しましょう。HTMLのsrcset属性とsizes属性を使えば、デバイスの画面サイズに応じて最適なサイズの画像を自動で配信できます。

施策2: 画像の遅延読み込み（Lazy Loading）

ファーストビューに表示されない画像は、スクロール時に読み込む「遅延読み込み」を設定します。

HTMLのimgタグにloading="lazy"属性を追加するだけで実装できます。 ブラウザがネイティブでサポートしているため、JavaScriptのライブラリは不要です。

ただし、ファーストビューに表示されるメイン画像（いわゆるヒーローイメージ）にはLazy Loadingを設定しないでください。 LCPの対象要素に遅延読み込みを設定すると、LCPが悪化します。ヒーローイメージには逆にloading="eager"とfetchpriority="high"を指定するのが正解です。

施策3: レンダリングブロックリソースの排除

ブラウザがHTMLを解析中に外部CSSや同期的なJavaScriptに遭遇すると、そのリソースのダウンロードと処理が完了するまでレンダリングが停止します。 これが「レンダリングブロック」です。

CSSの最適化

ファーストビューの表示に必要なCSSだけを<style>タグでHTMLに直接埋め込みます（クリティカルCSS）。 残りのCSSは<link rel="preload" as="style">で非同期に読み込むか、media属性を使って条件付き読み込みにします。

JavaScriptの最適化

<script>タグにdefer属性またはasync属性を追加して、HTMLの解析をブロックしないようにします。

• defer: HTMLの解析完了後に、記述順に実行される
• async: ダウンロード完了次第、即座に実行される（実行順序は保証されない）

ほとんどのケースではdeferを使うのが安全です。

施策4: 使用していないJavaScriptの削減

PageSpeed Insightsで「使用していないJavaScriptの削減」が指摘される場合、ページに読み込まれているJavaScriptのうち、実際には使われていないコードが大量に含まれています。

原因として多いのは以下のパターンです。

• 全ページで同じバンドルファイルを読み込んでいる（コード分割されていない）
• 使っていないプラグインやライブラリが残っている
• Google Tag ManagerやSNSウィジェットなどのサードパーティスクリプトが重い

対処法としては、Webpackやesbuildなどのバンドラーでコード分割（Code Splitting）を設定し、各ページで必要なJavaScriptだけを読み込むようにします。 サードパーティスクリプトは、ユーザーの操作後に遅延読み込みするか、Partytown等のライブラリでWebワーカーに逃がす方法もあります。

施策5: CSSの最適化と不要CSSの除去

使用していないCSSもレンダリングをブロックし、転送量を増やします。

Chrome DevToolsの「Coverage」タブを使えば、ページで実際に使われているCSSの割合を確認できます。 大規模なCSSフレームワーク（Bootstrap等）を使っている場合、CSSの70%以上が未使用というケースも珍しくありません。

PurgeCSSやUnCSSといったツールを使えば、未使用のCSSを自動で除去できます。 Tailwind CSSを使っている場合は、ビルド時に自動でパージされるため、この問題は発生しにくいです。

施策6: サーバー応答時間（TTFB）の改善

TTFB（Time to First Byte）は、ブラウザがサーバーにリクエストを送ってから、最初の1バイトが返ってくるまでの時間です。 TTFBが遅いと、どんなにフロントエンドを最適化しても根本的な改善にはなりません。

TTFBの目安は800ミリ秒以内。理想は200ミリ秒以内です。

改善方法は主に3つあります。

サーバーのスペックを上げる ― 格安の共用サーバーを使っている場合、VPSやクラウドサーバー（AWS、GCP、さくらのVPS等）への移行を検討してください。月額数千円の差で、TTFBが劇的に改善するケースがあります。

CDN（Content Delivery Network）の導入 ― Cloudflare、Fastly、AWS CloudFrontなどのCDNを導入すると、ユーザーに物理的に近いサーバーからコンテンツが配信されるため、TTFBが改善します。Cloudflareの無料プランでも十分な効果があります。

サーバーサイドのキャッシュ設定 ― データベースクエリの結果やページのHTMLをキャッシュすることで、毎回の動的生成を避けます。

施策7: ブラウザキャッシュの活用

一度読み込んだリソース（画像、CSS、JavaScript等）をブラウザにキャッシュさせることで、2回目以降のアクセスを高速化できます。

HTTPヘッダーのCache-Controlで、リソースの種類に応じたキャッシュ期間を設定します。

ファイル名にハッシュ値を含める（例: style.a1b2c3.css）運用にすれば、ファイルを更新したときにファイル名が変わるため、キャッシュの期間を長くしても古いファイルが配信され続ける問題を回避できます。

施策8: Webフォントの最適化

Google FontsやAdobe Fontsなどのカスタムフォントは、ページの表示速度に大きな影響を与えます。

フォントファイルの読み込みに時間がかかると、テキストが一時的に表示されない（FOIT: Flash of Invisible Text）か、システムフォントで一瞬表示された後にカスタムフォントに切り替わる（FOUT: Flash of Unstyled Text）現象が発生します。

対処法は以下の通りです。

font-display: swapを指定する ― CSSの@font-faceルールにfont-display: swapを追加します。フォントの読み込み中はシステムフォントを表示し、読み込み完了後にカスタムフォントに切り替えます。テキストが非表示になる時間がなくなるため、LCPの改善につながります。

フォントファイルをセルフホスティングする ― Google Fontsを外部CDNから読み込む代わりに、フォントファイルを自サーバーに配置します。DNSルックアップやTLS接続のオーバーヘッドを削減できます。

サブセット化する ― 日本語フォントは文字数が多く、ファイルサイズが巨大になりがちです。実際にサイトで使用する文字だけを含むサブセットフォントを作成すれば、ファイルサイズを大幅に削減できます。

そもそもカスタムフォントが必要か再検討する ― 本文にカスタムフォントを使う必要があるか、冷静に考えてみてください。見出しやロゴだけに限定し、本文はシステムフォント（游ゴシック、ヒラギノ角ゴ等）で十分な場合も多いです。

施策9: リソースのプリロードとプリコネクト

ブラウザが「このリソースが必要だ」と認識する前に、先回りしてリソースの取得やサーバーへの接続を開始する手法です。

<link rel="preload"> ― ファーストビューに必要なフォントやCSS、画像を先行ダウンロードします。LCP対象の画像にpreloadを設定すると、LCPが改善するケースが多いです。

<link rel="preconnect"> ― 外部ドメインへのDNSルックアップ・TLS接続を事前に行います。Google Fonts、Google Analytics、CDNなど、外部リソースを利用している場合に有効です。

<link rel="dns-prefetch"> ― preconnectよりも軽量で、DNSルックアップだけを事前に行います。preconnectの対象が多すぎる場合の代替として使います。

ただし、preloadやpreconnectを設定しすぎると逆効果になります。 本当にクリティカルなリソースだけに絞ることが重要です。目安は5個以内です。

施策10: HTMLの圧縮とHTTP/2の有効化

最後に、転送レベルの最適化です。

Gzip / Brotli圧縮 ― サーバーでテキストベースのリソース（HTML、CSS、JavaScript）を圧縮して転送します。Brotli圧縮はGzipより15〜25%圧縮効率が高いため、対応しているサーバーではBrotliを優先してください。ほとんどのモダンブラウザがBrotliをサポートしています。

HTTP/2（またはHTTP/3）の有効化 ― HTTP/2は1つのTCP接続で複数のリソースを並列にダウンロードできるため、HTTP/1.1と比べて転送効率が大幅に向上します。2026年現在、ほとんどのCDNとホスティングサービスがHTTP/2に対応していますが、念のため確認してください。

WordPressサイトのページスピード改善

WordPressは世界中で最も使われているCMSですが、「そのまま使うと遅い」という弱点があります。 プラグインの追加やテーマの肥大化によって、知らないうちにページスピードが悪化しているケースが非常に多い。

ここでは、WordPress固有の高速化施策を解説します。

テーマ選びが速度の8割を決める

WordPressの表示速度に最も影響するのは、テーマの品質です。

多機能を売りにしたテーマは、使わない機能のCSS・JavaScriptまで全ページで読み込みます。 結果として、トップページだけで1MB以上のJavaScriptが読み込まれるという状況が発生します。

高速なテーマの条件は以下の通りです。

• 不要な機能を無効化できる設計になっている
• ページビルダーに依存しない（Elementor、Divi等は重い傾向がある）
• 初期状態でPageSpeed Insightsスコア80以上

国内テーマならSWELL、SANGO、Cocoon。海外テーマならGeneratePress、Kadenceが速度面で評価されています。

キャッシュプラグインの導入と設定

WordPressで最も手軽にページスピードを改善できるのが、キャッシュプラグインの導入です。

キャッシュプラグインは、PHPで動的に生成されるHTMLをあらかじめ静的ファイルとして保存し、以降のアクセスではその静的ファイルを返します。 データベースへの問い合わせとPHPの実行が省略されるため、TTFBが劇的に短縮されます。

おすすめのキャッシュプラグインを3つ挙げます。

WP Rocketは有料ですが、設定の手軽さと総合的な最適化機能を考えると、投資対効果は高いです。 無料で済ませたい場合は、W3 Total Cacheが最もバランスが取れています。

プラグインの棚卸し

WordPressサイトが遅くなる原因の多くは、プラグインの入れすぎです。

「とりあえずインストールしたけど使っていない」「昔は使っていたけど今は不要」というプラグインが残っていませんか。 有効化しているプラグインが20個を超えているなら、まず棚卸しをしましょう。

特に速度に影響しやすいプラグインのカテゴリは以下の通りです。

• ページビルダー系（Elementor、WPBakery、Divi Builder）
• SNSシェアボタン系（重いJavaScriptを読み込む）
• スライダー系（大量の画像とJavaScriptを読み込む）
• セキュリティ系の一部（毎回のリクエストで重い処理を実行）
• アクセス解析系（サーバーサイドで集計するタイプ）

Query Monitorプラグインをインストールすれば、各プラグインがデータベースクエリやページ生成にどれだけ時間をかけているかを可視化できます。数値を見て判断することが大切です。

画像最適化プラグインの活用

WordPressの場合、画像の最適化はプラグインに任せるのが効率的です。

ShortPixel、Imagify、EWWW Image Optimizerなどのプラグインは、画像アップロード時に自動で圧縮・WebP変換を行ってくれます。 既存の画像も一括で最適化できるため、過去にアップロードした大量の画像を手作業で処理する必要はありません。

加えて、WordPress 5.8以降ではWebPがネイティブサポートされています。 WordPress 6.1以降では、アップロードした画像を自動でWebPに変換する機能も追加されました。

PHP・データベースの最適化

WordPress本体の処理速度を改善する施策も重要です。

PHPバージョンを最新にする ― PHP 7.4からPHP 8.3に更新するだけで、処理速度が20〜30%向上します。レンタルサーバーの管理画面からPHPバージョンを変更できます。事前にプラグインの互換性を確認してから更新してください。

データベースのクリーンアップ ― WordPressのデータベースには、投稿のリビジョン、自動保存、スパムコメント、一時的なトランジェントデータなど、不要なデータが蓄積していきます。WP-Optimizeプラグインを使えば、定期的に不要データを削除し、テーブルを最適化できます。

オブジェクトキャッシュの導入 ― Redis（またはMemcached）を使ったオブジェクトキャッシュを導入すると、データベースクエリの結果をメモリ上にキャッシュし、同じクエリの繰り返し実行を防げます。特にログインユーザーが多いサイトや、WooCommerceなどの動的なサイトで効果が大きいです。

FAQ

Q. PageSpeed Insightsのスコアは何点を目指すべきですか？

スコアの数字そのものよりも、Core Web Vitalsの3指標（LCP、INP、CLS）がすべて「Good（良好）」になることを優先してください。 ラボデータのスコアは70以上を目安にするとよいですが、90点以上を目指して過度に時間をかける必要はありません。スコアを5点上げるより、コンテンツの質を高めるほうがSEO効果は大きいです。

Q. ページスピード改善でSEO順位はどのくらい変わりますか？

ページスピードは「ネガティブシグナル」の側面が強い要因です。 つまり、速いから大幅に順位が上がるというよりも、遅いと順位が下がる、という性質があります。 すでにCore Web Vitalsが「Good」であれば、さらに速くしてもSEO順位への追加効果は限定的です。一方、「Poor」から「Good」に改善した場合は、明確な順位改善が見られるケースがあります。

Q. 無料でページスピードを改善する方法はありますか？

はい、多くの施策は無料で実行できます。 画像の圧縮・WebP変換（Squoosh等のWebツール）、Lazy Loadingの設定（HTML属性の追加だけ）、不要なプラグインの削除、PHPバージョンの更新、Cloudflare無料プランの導入など、費用をかけずにできることは多いです。

Q. ページスピード改善の効果はいつ頃から出ますか？

技術的な改善を行った直後から、PageSpeed Insightsのラボデータには変化が反映されます。 ただし、フィールドデータ（CrUX）は過去28日間の集計であるため、実際のユーザーデータに改善が反映されるまでに約1か月かかります。 SEO順位への影響は、Googleがフィールドデータの変化を認識してからさらに時間がかかるため、2〜3か月は見ておいてください。

Q. CDNを導入するだけでページスピードは改善しますか？

CDNはTTFB（サーバー応答時間）の改善に効果的ですが、フロントエンドの問題（画像の最適化不足、レンダリングブロック等）は解決できません。 CDNの導入は「サーバー側の高速化」であり、それだけでPageSpeed Insightsのスコアが大幅に改善するとは限りません。サーバー側とフロントエンド側の両方を改善する必要があります。

Q. AMPはまだ必要ですか？

2026年現在、AMP（Accelerated Mobile Pages）はSEOにおいてほぼ必須ではなくなっています。 Googleは2021年にAMPを「トップニュースカルーセル」の掲載要件から外しました。Core Web Vitalsで良好なスコアが出ているサイトであれば、AMPを導入する必要はありません。 ただし、すでにAMPを導入しているサイトが無理に外す必要もないため、現状維持で問題ないでしょう。

まとめ

ページスピードの改善は、SEO対策において「やって当たり前」の基盤施策です。

改善の優先順位を振り返ります。

1. PageSpeed Insightsでフィールドデータを確認し、Core Web Vitalsの現状を把握する
2. 「改善できる項目」の推定節約時間が大きいものから対処する
3. 画像の最適化は最優先。WebP変換・リサイズ・遅延読み込みの3点セット
4. レンダリングブロックリソースの排除とJavaScriptの削減
5. サーバー応答時間（TTFB）が遅い場合は、CDN導入やサーバー移行を検討
6. WordPressの場合は、キャッシュプラグインの導入とプラグインの棚卸しが即効性あり

ページスピードは一度改善して終わりではありません。 新しいプラグインの追加やコンテンツの更新によって、気づかないうちに悪化します。 月に1回はPageSpeed Insightsでチェックする運用を習慣にしてください。

ページスピードの改善は、テクニカルSEO（内部対策）の重要な柱の一つです。 SEO内部対策チェックリストを活用して、表示速度以外の技術的な課題も洗い出すことをおすすめします。

また、ページスピードの改善だけでは検索順位は上がりません。 SEO対策の全体ガイドで解説している通り、コンテンツSEO・内部対策・外部対策の3本柱をバランスよく進めることが、持続的な成果につながります。