PageSpeed Insightsの使い方|結果の見方・改善優先順位・確認手順【2026年版】
- SEO対策
- ホームページ制作
- 保守管理・運用
最終更新日:2026年10月09日

PageSpeed Insightsは、Webページの表示や操作を測定し、改善すべき箇所を調べるための無料ツールです。結果を見る順番は、実ユーザーデータの対象 → モバイル・デスクトップ → 遅い指標 → 原因候補 → 修正後の確認です。
過去28日間の実ユーザーデータと、測定時点のラボデータは役割が違います。改善直後の確認はラボと実機操作で行い、利用者の体験が変わったかは実ユーザーデータで経過を見ます。スコアだけで改修の優先順位を決めないことが大切です。
ツール利用は無料ですが、改善費は原因調査、画像・テーマ・プラグインの修正、検証範囲で変わります。1998年創業・4,000件超の制作実績を持つFNJが、担当者が結果から次の作業を決める手順と、WordPressの改修で確認する点を解説します。
ホームページの保守・管理にお困りではありませんか?
ファーストネットジャパンでは、1998年の創業以来、4,000件を超える実績で培った知見をもとに、ホームページの更新・保守・セキュリティ対応から、他社で制作されたサイトの引き継ぎ・乗り換えまで総合的にサポートします。
連絡が取れない、放置してしまっているサイトのご相談も承ります。まずはお気軽にお問い合わせください。


PageSpeed Insightsとは
Googleが無料で提供するWebページの測定ツール
PageSpeed Insightsは、Googleが無料で提供しているWebページのパフォーマンス測定ツールです。測定したいURLを入力すると、モバイルとパソコンの分析結果を確認できます。
公式ツールは以下から利用できます。
PageSpeed Insightsでは、主に以下を確認できます。
- 実際の利用者が体験したCore Web Vitals
- Lighthouseによるパフォーマンススコア
- アクセシビリティ
- ベストプラクティス
- SEOの基本項目
- 画像・JavaScript・CSS・サーバーなどの改善候補
測定対象はサイト全体ではなく入力したページ
PageSpeed Insightsで測定されるのは、基本的に入力したURLのページです。トップページのスコアが良くても、画像やフォームが多いサービスページ、記事ページ、問い合わせページが同じ状態とは限りません。
実務では、トップページだけでなく、次のページも個別に測定します。
- 問い合わせにつながるサービスページ
- 検索流入の多い記事ページ
- ランディングページ
- 問い合わせフォーム
- 画像・動画・外部ツールを多く利用するページ
最初に理解したいフィールドデータとラボデータの違い
PageSpeed Insightsを見るうえで、最も重要なのがフィールドデータとラボデータの区別です。
| 項目 | フィールドデータ | ラボデータ |
| データの内容 | 実際のChromeユーザーが体験したデータ | Lighthouseによるシミュレーション測定 |
| 集計期間 | 過去28日間 | 測定を実行した時点 |
| 主な用途 | 実際の利用者の体験を確認する | 遅い原因を調査する |
| 表示される主な指標 | LCP・INP・CLS・FCP・TTFBなど | FCP・LCP・Speed Index・TBT・CLSなど |
| 注意点 | アクセスデータが不足すると表示されない場合がある | 測定環境によって結果が変動する |
フィールドデータは実際の利用者の体験
フィールドデータにはChrome User Experience Reportのデータが利用されます。過去28日間の実ユーザーデータを基に、モバイルとパソコンの利用状況を確認できます。
Core Web Vitalsの判定では、原則として75パーセンタイルの値が使われます。簡単にいえば、多くの利用者が基準内の体験を得られているかを確認する考え方です。
URL単位のデータが不足している場合は、サイト全体を表すオリジン単位のデータが表示される場合があります。公開直後のページやアクセス数が少ないページで「データがありません」と表示されても、測定エラーとは限りません。
ラボデータは原因調査に使う
ラボデータは、Lighthouseが一定の端末・通信条件を想定して測定した結果です。実ユーザーの平均値ではなく、問題の発見や改修前後の比較に向いています。
例えば、フィールドデータでLCPが悪い場合に、ラボデータを使ってLCP対象画像、サーバー応答、レンダリングを妨げるCSSなどを調査します。
フィールドデータとラボデータの数値が異なっていても、どちらかが間違っているわけではありません。利用者の端末性能、通信環境、キャッシュ、アクセス地域、測定時のサーバー負荷などが異なるためです。
PageSpeed Insightsの使い方
1. 測定したいページのURLを入力する
PageSpeed Insights公式サイトへアクセスし、測定したいページのURLを入力して「分析」をクリックします。

画面構成はGoogle側のアップデートによって変更されることがありますが、基本操作はURLを入力して分析するだけです。
2. モバイルとパソコンを切り替える
分析結果は、モバイルとパソコンに分けて表示されます。一般的には、端末性能や通信環境の制約が大きいモバイルの方が、パフォーマンススコアは低くなりやすい傾向があります。
自社サイトのアクセスの多くがスマートフォンからであれば、モバイルを優先します。ただし、BtoBサイトではパソコンからの閲覧や問い合わせも多いため、Google Analyticsなどで実際のデバイス比率を確認したうえで判断することが重要です。
3. 実際のユーザー環境を確認する
最初に実際のユーザー環境を評価するフィールドデータを確認します。
ここでは、主に次の内容を見ます。
- Core Web Vitalsに合格しているか
- LCP・INP・CLSのうち、どの指標が基準を外れているか
- URL単位とオリジン単位で差があるか
- モバイルとパソコンで差があるか
- TTFBやFCPがLCPを遅らせていないか
4. パフォーマンスの問題点を確認する
次にLighthouseのパフォーマンススコアと改善候補・診断項目を確認します。
改善候補には、画像配信、JavaScript、CSS、キャッシュ、サーバー応答、外部スクリプトなどが表示されます。
ただし、表示された項目を上から機械的に修正するのではなく、Core Web Vitalsへの影響、対象ページの重要度、改修工数、表示崩れや機能停止のリスクを考えて優先順位を決めます。
結果を見る最初の3分で確認すること
最初に測定URLと実ユーザーデータの対象を確認します。個別URLのデータが不足するとサイト全体のオリジンデータが表示される場合があるため、それを当該ページだけの結果と受け取らないでください。
| 読む場所 | 確認すること | 次に行うこと |
|---|---|---|
| 実ユーザーデータの対象 | このURLかオリジンか、データがあるか | 集計対象と測定日を記録 |
| Core Web Vitals | LCP・INP・CLSの状態 | 実利用者の課題がどの指標かを整理 |
| ラボの診断 | 測定条件と原因候補 | 修正できる対象を制作・運用担当へ確認 |
| 実機での操作 | 表示、スクロール、メニュー、フォーム | スコアに出ない操作の障害も確認 |
実ユーザーデータがない場合の進め方
データ不足は、それだけで表示速度が悪いという意味ではありません。ラボの診断と実際のスマートフォン操作で課題を調べ、可能ならサイトの計測環境も確認します。存在しない実ユーザー値を推測して報告しないでください。
PageSpeed Insightsのスコアの見方

パフォーマンススコアは3段階で表示される
| スコア | 評価 | 表示色 |
| 90~100 | 良好 | 緑 |
| 50~89 | 改善が必要 | オレンジ |
| 0~49 | 低い | 赤 |
このスコアは、Lighthouseの複数の指標を重み付けして算出したものです。同じページでも、測定時のサーバー負荷や外部スクリプトなどによって数値が変動します。
そのため「何点以上ならSEOに強い」という単純な基準で判断するのではなく、Core Web Vitals、利用者の体感、問い合わせに関わる機能を優先します。
PageSpeed InsightsのスコアとSEO順位は同じではない
Core Web VitalsはGoogle検索のランキングシステムで利用されていますが、数値が良好だからといって上位表示が保証されるわけではありません。
検索順位には、検索意図への適合、コンテンツの品質、専門性、サイト構造、内部リンク、被リンクなど複数の要因が関係します。
また、Lighthouseのパフォーマンススコアそのものが検索順位を決める数値ではありません。PageSpeed Insightsは、検索順位だけではなくユーザー体験を改善するための診断ツールとして活用することが重要です。
モバイルとパソコンのスコアが違う理由
モバイルとパソコンでは、想定する端末性能や測定条件が異なります。また、実ユーザーのデータもモバイルとパソコンで別々に集計されます。
モバイルスコアが低い場合は、次の原因を確認します。
- ファーストビュー画像の容量が大きい
- JavaScriptの処理が多い
- スマートフォンだけで読み込む機能がある
- 外部フォント・動画・地図・SNS埋め込みが多い
- レスポンシブ表示用のCSSが複雑になっている
Core Web Vitalsと主要指標の基準
Core Web VitalsはLCP・INP・CLSの3指標
| 指標 | 測定する内容 | 良好 | 改善が必要 | 不良 |
| LCP | 主要コンテンツが表示されるまでの時間 | 2.5秒以下 | 2.5秒超~4.0秒以下 | 4.0秒超 |
| INP | クリックやタップに反応するまでの時間 | 200ミリ秒以下 | 200ミリ秒超~500ミリ秒以下 | 500ミリ秒超 |
| CLS | 予期しないレイアウトのずれ | 0.1以下 | 0.1超~0.25以下 | 0.25超 |
LCPは主要コンテンツの表示速度
LCPはLargest Contentful Paintの略で、画面内の主要な画像や大きなテキストブロックが表示されるまでの時間を表します。
企業サイトでは、メインビジュアル、サービス紹介画像、大きな見出しなどがLCP対象になりやすい傾向があります。対象画像を遅延読み込みにしている、画像サイズが大きい、サーバー応答が遅いといった原因で悪化します。
INPは操作への反応速度
INPはInteraction to Next Paintの略で、利用者がクリック、タップ、キー入力をしてから、画面が反応するまでの時間を評価します。
JavaScriptの長い処理、外部タグ、複雑な検索・絞り込み、フォーム処理などが原因になります。INPはFIDに代わり、2024年3月からCore Web Vitalsの正式指標になりました。
CLSは画面のずれを評価する
CLSはCumulative Layout Shiftの略です。読み込み途中に画像や広告が挿入され、ボタンや文章の位置が突然ずれる現象を評価します。
画像・動画・iframeの表示領域をあらかじめ確保する、Webフォントの読み込みを調整する、既存コンテンツの上部へ後から要素を挿入しない、といった対策が有効です。
FCP・TTFB・TBTは原因を調べる補助指標
| 指標 | 意味 | 目安 | 主な用途 |
| FCP | 最初の文字や画像が表示されるまでの時間 | 1.8秒以下が良好 | 初期表示が遅い原因を確認する |
| TTFB | 最初のデータが返るまでの時間 | 0.8秒以下が一つの目安 | サーバー・キャッシュ・リダイレクトを確認する |
| TBT | メインスレッドが処理で塞がった時間 | 200ミリ秒以下が良好 | JavaScriptが操作性に与える影響を調べる |
FCPとTTFBはCore Web Vitalsではありませんが、LCPが遅い原因を分解するために役立ちます。TBTもCore Web Vitalsではありませんが、ラボ環境でJavaScript処理の重さを調べ、INP改善の手掛かりにできます。
表示速度改善の優先順位を決める5ステップ

スコアを上げやすい項目ではなく、利用者の操作と事業への影響が大きい課題から選びます。すべてのプラグインを一度に変更すると原因を追いにくくなるため、作業は小さく区切って検証します。
- 主力サービス、トップ、問い合わせなど重要ページを選び、変更前の結果を保存する
- 実ユーザーの指標と実機の操作から遅さ・ずれ・反応の問題を確認する
- ラボの診断で画像、JavaScript、サーバー応答などの原因候補を調べる
- 影響範囲を決め、バックアップと検証環境を用意して一つずつ修正する
- 同じ条件で再測定し、表示・フォーム・計測の副作用を確認する
| 問題 | 原因候補の確認例 | 修正後の確認 |
|---|---|---|
| 大きな画像の表示が遅い | 画像容量、表示サイズ、読み込み方法 | 主画像の表示と画質、LCP |
| ボタンへの反応が遅い | JavaScript処理、外部タグ、重い操作 | メニューやフォームの操作、INP |
| 読み込み中に位置が動く | 画像の寸法、後から出る要素、フォント | 予約・送信ボタン付近のずれ、CLS |
| 最初の応答に時間がかかる | サーバー、キャッシュ、処理負荷 | 対象ページとログイン等の動作 |
最初の画面の画像を一律に遅延させない
画像を軽くすることと、必要な画像の表示を後回しにすることは別です。最初に見せる主画像まで遅延させると体験が悪化する場合があります。画像の役割と表示位置を確かめ、変更後に画面を見て確認しましょう。
キャッシュ設定では動的な画面を確認する
問い合わせ、予約、会員、カートなどは静的な会社案内と同じ条件で扱えない場合があります。設定変更後は送信、ログイン、更新情報の反映まで試し、古い表示や入力エラーが出ていないか確認してください。
指標別に見る表示速度の改善方法
LCPが悪い場合の改善方法
- LCP対象となっている画像・見出しを特定する
- ファーストビュー画像をWebP・AVIFなどへ最適化する
- 表示サイズに合った画像を配信する
- LCP画像に不要な遅延読み込みを設定しない
- 重要画像の読み込み優先度を見直す
- サーバー応答とキャッシュを改善する
- 初期表示を妨げるCSS・JavaScriptを整理する
- 必要に応じてCDNを利用する
画像だけを圧縮しても、TTFBが遅い、CSSの読み込み待ちが長いといった問題があれば、LCPは十分に改善しません。LCPを「サーバー応答」「リソース読み込み」「要素の描画」に分けて確認することが重要です。
INP・TBTが悪い場合の改善方法
- 長時間実行されるJavaScript処理を分割する
- 使っていないJavaScriptやライブラリを削除する
- 解析タグ・広告タグ・チャットなどの外部スクリプトを整理する
- 必要なページだけでスクリプトを読み込む
- イベント処理を軽量化する
- 検索・絞り込み・フォーム処理の実装を見直す
- メインスレッドを塞ぐ処理を遅延または分離する
INPは、ページ表示後に利用者が操作したときの反応も含みます。初期表示だけを測定するラボテストでは再現しにくい問題があるため、実ユーザーデータや実機操作も確認します。
CLSが悪い場合の改善方法
- 画像と動画にwidth・heightを指定する
- iframe・地図などの表示領域を事前に確保する
- Cookie同意や告知バーの表示方法を見直す
- Webフォント読み込み時の文字幅変化を抑える
- 既存コンテンツの上へ後から要素を挿入しない
- アニメーションにレイアウトが変わりにくい方式を使う
TTFB・FCPが悪い場合の改善方法
- 不要なリダイレクトを削減する
- ページキャッシュ・オブジェクトキャッシュを適切に設定する
- データベースの遅い処理を調査する
- サーバーのCPU・メモリ・同時接続状況を確認する
- HTML・CSS・JavaScriptの圧縮配信を設定する
- CDNやエッジキャッシュの利用を検討する
- 初期表示に不要なCSS・JavaScriptの読み込みを遅らせる
内容を踏まえて、自社で対応する範囲と依頼する範囲を整理して相談できます。
ホームページの保守・管理にお困りではありませんか?
ファーストネットジャパンでは、1998年の創業以来、4,000件を超える実績で培った知見をもとに、ホームページの更新・保守・セキュリティ対応から、他社で制作されたサイトの引き継ぎ・乗り換えまで総合的にサポートします。
連絡が取れない、放置してしまっているサイトのご相談も承ります。まずはお気軽にお問い合わせください。


PageSpeed Insightsでよく表示される改善項目と対処法
PageSpeed Insightsでは、単に「ページが遅い」と表示されるのではなく、画像、JavaScript、CSS、LCP、キャッシュなど、表示速度を低下させている可能性のある項目が具体的に示されます。
ただし、表示される項目はサイトによって異なります。また、すべての項目を上から順番に修正する必要はありません。Core Web Vitalsへの影響、対象ページの重要度、修正工数、表示崩れなどのリスクを踏まえて優先順位を決めます。
| PageSpeed Insightsで確認する項目 | 主な原因 | 最初に確認すること | 主な改善方法 |
| 画像配信の改善 | 画像サイズが大きい、表示サイズより元画像が大きい | LCP対象画像、画像容量、表示サイズ | WebP・AVIF化、圧縮、適正サイズ化、srcset設定 |
| LCPの内訳・LCPリクエスト | 主要画像やコンテンツの読み込み開始が遅い | LCP対象要素、TTFB、画像読み込み開始時刻 | LCP画像の優先読み込み、サーバー応答改善、不要な遅延読み込み解除 |
| レンダリングを妨げるリクエスト | CSS・JavaScriptの読み込み待ち | ファーストビューで必要なCSS・JavaScript | 不要ファイル削減、読み込み順変更、遅延・非同期読み込み |
| INPの内訳 | JavaScript処理やイベント処理が重い | クリック・タップ時に実行される処理 | 長い処理の分割、不要JavaScript削減、イベント処理の軽量化 |
| レイアウトシフトの原因 | 画像や外部コンテンツが後から挿入される | 画像、iframe、Webフォントなど | 表示領域の事前確保、width・height指定、フォント読み込み改善 |
| 効率的なキャッシュ設定 | 同じ静的ファイルを繰り返しダウンロードしている | 画像・CSS・JavaScriptのキャッシュ期間 | ブラウザキャッシュ、CDN、ファイルバージョン管理 |
| ドキュメントリクエストの遅延 | HTMLが返るまでに時間がかかっている | TTFB、リダイレクト、サーバー処理 | サーバー・DB・キャッシュ設定の見直し、不要リダイレクト削減 |
| 第三者リソース | 解析、SNS、動画、地図、チャットなどの外部処理 | 本当に必要な外部ツールか | 不要タグ削除、読み込みページ限定、遅延読み込み |
| JavaScriptの重複・不要コード | 同じライブラリや機能を複数回読み込んでいる | テーマ・プラグイン・外部タグの重複 | 重複機能削除、プラグイン整理、必要ページのみ読み込み |
| DOMサイズ | HTML要素が過剰に多い | ページビルダー、長大なメニュー、非表示要素 | HTML構造の簡素化、不要要素削除、テンプレート改善 |
画像配信の改善と表示された場合
画像は企業サイトで最も容量が大きくなりやすい要素です。まず、PageSpeed InsightsでLCP対象になっている画像と、容量の大きい画像を確認します。
改善では、単純にWebPやAVIFへ変換するだけでなく、実際の表示サイズに合った画像を配信することが重要です。例えば横幅600pxで表示する画像に、横幅3,000pxの元画像をそのまま読み込ませる必要はありません。
- 画像をWebP・AVIFなどへ変換する
- 画質を確認しながら圧縮する
- 表示サイズに合わせて画像寸法を調整する
- srcset・sizesを利用して端末ごとに適切な画像を配信する
- 画面外の画像は遅延読み込みする
- LCP対象画像には不要な遅延読み込みを設定しない
LCP関連の改善項目が表示された場合
LCPが遅い場合は、対象画像だけを見るのではなく、「サーバーからHTMLが返るまで」「LCPリソースの読み込みが始まるまで」「画像などのリソースを取得するまで」「画面へ描画されるまで」のどこで時間がかかっているかを確認します。
例えばLCP画像を十分に圧縮していても、サーバー応答が遅ければ改善効果は限定的です。逆にサーバーが高速でも、LCP画像の読み込み開始が遅れていれば表示は速くなりません。
PageSpeed Insightsの数値だけで判断せず、ボトルネックを分解して対応することが重要です。
レンダリングを妨げるリクエストと表示された場合
ブラウザがページを表示する前に、多数のCSSやJavaScriptを読み込んでいる場合に発生しやすい項目です。
ファーストビューに必要なCSSを優先し、初期表示に不要なJavaScriptを後から読み込む方法などが有効です。
ただし、JavaScriptやCSSを機械的に遅延・削除すると、メニュー、スライダー、問い合わせフォーム、アクセス解析などが動作しなくなることがあります。変更後は必ず実機で機能確認を行ってください。
INPの改善が必要な場合
INPは、ユーザーがクリック・タップ・キー入力したときの反応速度を評価します。JavaScript処理が長時間メインスレッドを占有している場合や、外部スクリプトが大量に動作している場合に悪化しやすくなります。
- 長時間実行されるJavaScriptを分割する
- 利用していないJavaScriptを削除する
- 外部タグや計測ツールを整理する
- 必要なページだけでJavaScriptを読み込む
- クリック・タップ時のイベント処理を軽量化する
INPは実際のユーザー操作を基に評価されるため、Lighthouseのラボデータだけでなく、フィールドデータも確認します。
レイアウトシフトの原因が表示された場合
ページを読み込んでいる途中で文章、ボタン、画像などの位置が動く場合はCLSが悪化します。
企業サイトでは、画像、YouTube動画、Googleマップ、Cookie同意表示、Webフォントなどが原因になりやすいため、次の項目を確認します。
- 画像・動画にwidthとheightが設定されているか
- iframeの表示領域が事前に確保されているか
- 後からコンテンツ上部へ要素を挿入していないか
- Webフォント読み込み時に文字幅が大きく変わっていないか
効率的なキャッシュ設定が必要と表示された場合
画像、CSS、JavaScriptなどの静的ファイルに十分なキャッシュ期間が設定されていないと、再訪問時にも同じファイルをダウンロードすることになります。
ブラウザキャッシュやCDNを適切に利用することで改善できますが、更新頻度の高いファイルに長期間のキャッシュを設定すると、サイトを修正しても古い内容が表示されることがあります。
ファイル名やバージョン番号を変更してキャッシュを更新する仕組みまで含めて設計します。
ドキュメントリクエストの遅延が表示された場合
HTMLそのものがサーバーから返ってくるまでに時間がかかると、その後の画像やCSSが高速でもページ全体の表示開始が遅れます。
主に以下を確認します。
- 不要なリダイレクトが発生していないか
- WordPressのデータベース処理が重くないか
- ページキャッシュが利用できているか
- サーバーのCPUやメモリに余裕があるか
- 外部APIの応答待ちが発生していないか
第三者リソースの影響が大きい場合
Google Analytics、広告タグ、ヒートマップ、SNS埋め込み、YouTube、Googleマップ、チャットなどは、自社サーバーとは別の処理が発生します。
すべて削除すれば速度は改善する可能性がありますが、アクセス解析や問い合わせ獲得に必要な機能まで削除しては本末転倒です。
同じ目的のツールが複数導入されていないかを確認し、必要性の低いものを整理する、利用するページを限定する、初期表示後に読み込むといった方法で調整します。
PageSpeed Insightsの改善項目は「消すこと」が目的ではない
PageSpeed Insightsに改善項目が残っているからといって、すべてをゼロにする必要はありません。
企業サイトでは、問い合わせフォーム、アクセス解析、広告計測、動画、地図など、事業上必要な機能が表示速度へ影響することがあります。
重要なのは、スコア100点や警告ゼロを目指すことではなく、Core Web Vitalsとユーザー体験を確認しながら、問い合わせや売上に必要な機能を維持したうえで改善することです。
WordPressサイトの表示速度を改善するポイント
WordPressはテーマやプラグインで機能を拡張しやすい一方、運用を続けるうちに読み込むファイルやデータベース処理が増えやすいCMSです。
プラグインは個数ではなく処理内容で判断する
「プラグインが10個を超えると遅くなる」というような一律の基準はありません。軽量なプラグインが多い場合もあれば、1つの高機能プラグインが大きな負荷を発生させる場合もあります。
次の観点で確認します。
- 全ページでCSS・JavaScriptを読み込んでいないか
- 外部サービスへ多数の通信を行っていないか
- データベースへの重い処理がないか
- 機能が重複していないか
- 停止中のプラグインが放置されていないか
- 更新とセキュリティ対応が継続されているか
キャッシュ機能を重複させない
サーバー、CDN、WordPressプラグインで複数のキャッシュ機能を重ねると、表示不具合や更新反映の遅れが起こることがあります。
利用しているサーバー環境に適したキャッシュ方式を選び、原則として同じ役割のキャッシュプラグインを複数併用しません。
テーマとページビルダーを確認する
多機能テーマやページビルダーは便利ですが、利用していない機能のCSS・JavaScriptまで読み込む場合があります。
必要に応じて、ページ単位でアセットを制御する、テンプレートを軽量化する、問い合わせにつながる重要ページだけ個別に改修するといった対応を行います。
データベースと自動処理を整理する
投稿リビジョン、期限切れデータ、ログ、バックアップ、アクセス解析データなどがデータベースに蓄積すると、管理画面やページ生成が遅くなることがあります。
削除前にバックアップを取り、テーブル容量、遅いクエリ、自動実行処理を確認してから整理します。
PHPやWordPressを更新する前に互換性を確認する
WordPress本体、PHP、テーマ、プラグインを適切な状態へ更新することは重要です。ただし、公開環境でいきなり更新すると、表示崩れや機能停止が起こる可能性があります。
テスト環境で互換性を確認し、バックアップと復旧手順を用意したうえで更新します。
表示速度改善で発生しやすい失敗
スコアを上げるために必要な機能を止める
アクセス解析、問い合わせフォーム、Cookie同意、チャットなどを削除すればスコアは上がる可能性があります。しかし、計測や問い合わせができなくなれば、事業上は改善とはいえません。
削除ではなく、読み込み条件、読み込み時期、利用ツールの重複を見直します。
JavaScriptを一括で遅延させる
自動最適化プラグインなどでJavaScriptを一括遅延すると、メニュー、スライダー、フォーム、計測タグなどが動かなくなることがあります。
対象ファイルを分け、主要ブラウザと実機で動作確認を行います。
ファーストビュー画像まで遅延読み込みする
画面外の画像には遅延読み込みが有効ですが、LCP対象となるファーストビュー画像まで遅延すると、主要コンテンツの表示が遅れる場合があります。
キャッシュを設定して更新できなくなる
強いキャッシュ設定を行うと、管理画面で更新しても古い内容が表示されることがあります。更新担当者がキャッシュ削除方法を理解できる運用設計が必要です。
改善後の機能テストを行わない
表示速度改善後は、少なくとも以下を確認します。
- パソコン・スマートフォンの表示
- メニュー・検索・絞り込み
- 問い合わせフォームと自動返信
- Google Analytics・広告のコンバージョン計測
- Cookie同意管理
- 会員・ログイン機能
- 管理画面からの更新反映
- 主要ブラウザでの動作
表示速度改善の費用相場と期間
表示速度改善は、対象範囲によって費用と期間が変わります。以下は一般的な企業サイトやWordPressサイトでの概算です。
| 対応レベル | 主な内容 | 費用の目安 | 期間の目安 |
| 基本改善 | 画像圧縮、キャッシュ、不要設定の整理 | 10万円~30万円 | 1~2週間 |
| フロントエンド改善 | CSS・JavaScript・フォント・読み込み順の調整 | 30万円~60万円 | 2~4週間 |
| 構造的な改善 | テーマ改修、サーバー、DB、CDN、外部ツール見直し | 50万円~100万円以上 | 1~2か月以上 |
ページ数、CMS、EC・会員機能、外部システム連携、サーバー移行の有無などによって金額は変動します。
また「PageSpeed Insightsで90点を保証する」といった数値だけで依頼先を選ぶのではなく、対象ページ、改善項目、機能維持、測定方法、改修後の動作確認まで含まれているかを確認することが重要です。
表示速度の改善依頼に使う作業メモ
制作会社へは「スコアを100にしてほしい」ではなく、対象URL、困っている操作、測定日・端末、実ユーザー値の対象、変更履歴を共有します。見積もりは調査、修正、検証、公開後の確認へ分けます。
| メモの項目 | 記入する内容 |
|---|---|
| 影響するページ | サービス・問い合わせなどのURL |
| 実際の問題 | 主画像が遅い、メニューが反応しない等 |
| 変更できる範囲 | 画像、テーマ、プラグイン、外部タグ、サーバー |
| 検証対象 | 表示、フォーム、ログイン、解析タグ |
| 判断方法 | 同条件の測定と実機操作、実ユーザー値の経過 |
改善直後のスコア変動だけで成功とせず、重要な操作が正常であることを確認します。実ユーザーデータは過去の利用を含むため、更新後の変化を時間をかけて評価してください。
自社対応と外注の判断基準
| 状況 | 自社対応が向く | 外注が向く |
| 画像圧縮 | 更新ルールを決められる | 大量の既存画像を一括整理したい |
| キャッシュ設定 | テスト環境と復旧手順がある | 更新反映やログイン機能への影響が不安 |
| CSS・JavaScript | 実装担当者が社内にいる | テーマやプラグインを含めた調査が必要 |
| サーバー・DB | インフラ担当者がいる | 移行・障害・セキュリティを含めて任せたい |
| 継続運用 | 定期測定と更新ルールを社内化できる | 保守と速度監視をまとめて依頼したい |
自社で対応できる範囲から始めることに問題はありません。ただし、CSS・JavaScript・キャッシュ・サーバー設定は相互に影響するため、公開サイトで試行錯誤すると障害につながる可能性があります。
ファーストネットジャパンの表示速度改善・保守サポート
ファーストネットジャパンは、1998年創業・大阪市中央区に拠点を置くWeb制作会社です。4,000件超の制作実績をもとに、ホームページの企画・設計・制作からWordPress、システム、サーバー、公開後の保守・改善まで一貫してサポートしています。
表示速度改善の対応内容
- PageSpeed Insights・Core Web Vitalsの現状診断
- 重要ページと改善優先順位の整理
- 画像・フォントの最適化
- CSS・JavaScriptの読み込み改善
- WordPressテーマ・プラグインの調査
- キャッシュ・CDN・サーバー設定の調整
- データベース・自動処理の確認
- フォーム・計測タグ・主要機能の動作確認
- 改修前後の測定結果の確認
- 公開後の保守・定期的な運用改善
ご相談から改善までの流れ
- 対象URL・課題・運用状況の確認
- PageSpeed Insightsと実機による現状調査
- 改善項目を効果・工数・リスクで分類
- 対象範囲と見積もりのご提案
- テスト環境での改修・検証
- 公開後の再測定と運用改善
「PageSpeed Insightsのスコアが低いが、何から直せばよいかわからない」「制作会社が保守を終了して対応先がない」「WordPressの更新と速度改善をまとめて任せたい」といった段階でも構いません。まずはお気軽にご相談ください。
| 会社名 | 株式会社ファーストネットジャパン |
| 所在地 | 大阪市中央区南久宝寺町1-7-10 シャンクレール南久宝寺201 |
| 設立 | 2004年12月(1998年8月創業) |
| URL | https://gelatocms.com/ |
【関連記事】
WordPressのSEO設定と確認手順
ホームページのスマホ対応と改修
WordPress保守の作業範囲と外注判断
よくある質問
Q. PageSpeed Insightsはどの順番で見ればよいですか?
測定URLと実ユーザーデータの対象を確認し、モバイルとデスクトップ、Core Web Vitals、ラボの原因候補、実機操作の順に見ます。スコアだけで修正項目を決めないことが大切です。
Q. スコアは100点にする必要がありますか?
100点だけを目的にしないでください。実ユーザーの体験と、問い合わせや予約などの重要な操作を優先します。改善によって必要な機能や画質を損なわないかも確認します。
Q. 実ユーザーデータとラボデータは何が違いますか?
実ユーザーデータは過去28日間の利用者の体験を集計したものです。ラボデータは測定時点の条件で診断します。改善直後の確認と、実利用者への変化の評価で使い分けます。
Q. オリジンのデータが表示されるのはなぜですか?
個別URLのデータが十分でない場合に、サイトのオリジン単位のデータが表示されることがあります。個別ページだけの評価と混同せず、結果に表示された集計対象を記録してください。
Q. WordPressで最初に改善する箇所はどこですか?
画像、JavaScript、サーバー応答などの原因を診断してから選びます。重要ページの実機操作を確認し、バックアップと検証環境を用意して一つずつ修正し、フォーム等の副作用も点検します。
Q. 表示速度改善の外注費は何で変わりますか?
原因調査、対象ページ、画像やテーマの修正、プラグインやサーバーの対応、検証の範囲で変わります。調査・改修・公開後確認を分けて見積もり、スコアや順位の保証で判断しないでください。
まとめ
PageSpeed Insightsは、スコアを競うためのツールではなく、実際の利用者が感じている問題と、改善すべき技術要因を整理するためのツールです。
まずはフィールドデータでLCP・INP・CLSを確認し、問い合わせや売上に関わるページから改善してください。ラボデータは、画像、JavaScript、CSS、サーバー、外部スクリプトなどの原因を特定するために使います。
PageSpeed Insightsに表示される改善項目をすべて消す必要もありません。事業上必要なフォーム、アクセス解析、動画、地図などを維持しながら、効果・工数・リスクのバランスを考えて優先順位を決めることが重要です。
また、表示速度改善ではスコアだけを上げてフォームや計測機能を壊さないことも重要です。バックアップ、テスト環境、実機確認、公開後の継続測定までを一つの工程として考える必要があります。
ファーストネットジャパンは、1998年創業・4,000件超の制作実績をもとに、PageSpeed Insightsの診断、WordPressの表示速度改善、サーバー・キャッシュ設定、公開後の保守管理まで一貫してサポートします。「まだ原因がわからない」という段階でも構いません。まずはお気軽にご相談ください。
ホームページの保守・管理にお困りではありませんか?
ファーストネットジャパンでは、1998年の創業以来、4,000件を超える実績で培った知見をもとに、ホームページの更新・保守・セキュリティ対応から、他社で制作されたサイトの引き継ぎ・乗り換えまで総合的にサポートします。
連絡が取れない、放置してしまっているサイトのご相談も承ります。まずはお気軽にお問い合わせください。






