PageSpeed Insightsとは?使い方・スコアの見方・改善優先順位【2026年版】
- SEO対策
- ホームページ制作
- 保守管理・運用
最終更新日:2026年08月31日

PageSpeed Insightsを使うときに重要なのは、パフォーマンススコア100点を目指すことではありません。まず実際の利用者が体験したCore Web Vitalsを確認し、問い合わせや売上に関わるページから改善することが重要です。
PageSpeed Insightsには、実際のChromeユーザーによる過去28日間の「フィールドデータ」と、Lighthouseが一定条件で測定する「ラボデータ」があります。両者は役割が異なるため、スコアだけを見て判断すると改善の優先順位を誤ることがあります。
表示速度改善の費用は、画像圧縮やキャッシュ設定などの基本対応で10万円~30万円程度、JavaScript・CSS・サーバー構成まで見直す本格対応では30万円~100万円以上が一つの目安です。ただし、サイト規模、CMS、サーバー環境、改修範囲によって変動します。
本記事では、1998年創業・4,000件超の制作実績を持つ株式会社ファーストネットジャパンが、PageSpeed Insightsの使い方、スコアの見方、Core Web Vitals、表示速度を改善する順序を実務目線で解説します。
ホームページの保守・管理にお困りではありませんか?
ファーストネットジャパンでは、1998年の創業以来、4,000件を超える実績で培った知見をもとに、ホームページの更新・保守・セキュリティ対応から、他社で制作されたサイトの引き継ぎ・乗り換えまで総合的にサポートします。
連絡が取れない、放置してしまっているサイトのご相談も承ります。まずはお気軽にお問い合わせください。


この記事でわかること
- PageSpeed Insightsの基本的な使い方
- フィールドデータとラボデータの違い
- スコアとCore Web Vitalsの見方
- LCP・INP・CLSなどを改善する方法
- PageSpeed Insightsで表示される改善項目への対処法
- WordPressサイトの表示速度改善ポイント
- 自社対応と制作会社へ依頼する判断基準
- 表示速度改善にかかる費用と期間の目安
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への影響、対象ページの重要度、改修工数、表示崩れや機能停止のリスクを考えて優先順位を決めます。
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ステップ
PageSpeed Insightsに表示された改善項目をすべて同時に対応する必要はありません。費用対効果を高めるには、次の順序で判断します。
STEP1. フィールドデータで不合格の指標を確認する
最初にCore Web VitalsのLCP・INP・CLSを確認します。実ユーザー環境で問題が発生している指標から優先するのが基本です。
フィールドデータがない場合は、ラボデータだけで結論を出さず、Search ConsoleのCore Web Vitals、Google Analytics、実機確認なども組み合わせます。
STEP2. 重要ページから測定する
問い合わせや売上への影響が大きいページを優先します。例えば、サービスページ、ランディングページ、問い合わせフォーム、検索流入の多い記事です。
利用者がほとんど訪れないページを90点から100点にするより、問い合わせページの表示や操作を改善する方が、事業上の効果を得やすくなります。
STEP3. 遅さの中心原因を特定する
LCPが悪いからといって、画像だけが原因とは限りません。TTFBが遅ければ、画像が最適化されていても表示開始が遅れます。
次のように指標を関連付けて確認します。
- LCPが悪い:LCP対象要素、TTFB、FCP、レンダリングを妨げるリソースを確認
- INPが悪い:TBT、長いJavaScript処理、外部タグ、イベント処理を確認
- CLSが悪い:画像サイズ、iframe、フォント、後から挿入される要素を確認
STEP4. 効果・工数・リスクを比較する
改善候補ごとに、効果、工数、表示崩れや機能停止のリスクを整理します。
| 対策例 | 効果 | 工数 | 注意点 |
| 画像圧縮・適正サイズ化 | 高い | 小~中 | 画質と表示サイズを確認する |
| キャッシュ設定 | 高い | 小~中 | 更新内容が反映されない場合がある |
| JavaScriptの遅延・削減 | 高い | 中~大 | メニューやフォームが動かなくなる可能性がある |
| 未使用CSSの削減 | 中~高 | 中~大 | ページごとの表示崩れに注意する |
| サーバー移行 | 中~高 | 大 | DNS・メール・移行作業への影響を確認する |
STEP5. 改修後に再測定する
改修前後のPageSpeed Insightsの結果を保存し、同じURLを複数回測定します。ラボスコアには変動があるため、一度の測定だけで判断しません。
フィールドデータは過去28日間のデータを基にするため、改修直後にすべての数値が切り替わるわけではありません。公開直後はラボデータと実機で確認し、その後にフィールドデータの変化を追います。

指標別に見る表示速度の改善方法
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点を保証する」といった数値だけで依頼先を選ぶのではなく、対象ページ、改善項目、機能維持、測定方法、改修後の動作確認まで含まれているかを確認することが重要です。
自社対応と外注の判断基準
| 状況 | 自社対応が向く | 外注が向く |
| 画像圧縮 | 更新ルールを決められる | 大量の既存画像を一括整理したい |
| キャッシュ設定 | テスト環境と復旧手順がある | 更新反映やログイン機能への影響が不安 |
| 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の更新と速度改善をまとめて任せたい」といった段階でも構いません。まずはお気軽にご相談ください。
【関連記事】
ホームページ保守・管理サービス
ホームページ維持費の相場と管理費の内訳
WordPress保守の作業内容と放置するリスク
よくある質問
Q. PageSpeed Insightsのスコアは何点を目指せばよいですか?
一律の目標点はありません。まず実ユーザーデータでLCP・INP・CLSが良好かを確認し、Lighthouseでは重大なボトルネックがない状態を目指します。スコア100を目的にするのではなく、重要ページの体感速度と機能を優先してください。
Q. 改善したのにPageSpeed Insightsの結果がすぐ変わらないのはなぜですか?
ラボデータは再測定すると変化を確認できますが、フィールドデータは過去28日間の実ユーザーデータを基にしています。そのため、改修前のデータが一定期間含まれます。改修直後はラボデータと実機で確認し、その後にフィールドデータを継続して確認します。
Q. 実際のユーザーデータが表示されない場合はどうすればよいですか?
URL単位で十分なアクセスデータがない可能性があります。オリジン単位のデータ、Search ConsoleのCore Web Vitals、Google Analytics、Lighthouse、実機確認を組み合わせて判断してください。
Q. モバイルのスコアだけ低いのは問題ですか?
モバイルは端末性能や通信環境の制約により、パソコンより低いスコアになりやすい傾向があります。自社サイトのデバイス比率を確認し、モバイル利用者が多い場合は、画像、JavaScript、外部スクリプト、レスポンシブCSSを優先して改善します。
Q. WordPressの表示速度は自社で改善できますか?
画像圧縮や不要プラグインの整理などは自社でも対応できます。ただし、キャッシュ、JavaScript、CSS、PHP、データベース、サーバー設定は相互に影響します。バックアップとテスト環境を用意できない場合は、制作会社や保守会社への相談が安全です。
Q. 表示速度改善の費用と期間はどれくらいですか?
基本的な画像・キャッシュ改善は10万円~30万円、CSS・JavaScriptを含む改修は30万円~60万円、サーバーやテーマ構造まで見直す場合は50万円~100万円以上が目安です。期間は1週間~2か月以上で、サイト規模と改修範囲により変動します。
まとめ
PageSpeed Insightsは、スコアを競うためのツールではなく、実際の利用者が感じている問題と、改善すべき技術要因を整理するためのツールです。
まずはフィールドデータでLCP・INP・CLSを確認し、問い合わせや売上に関わるページから改善してください。ラボデータは、画像、JavaScript、CSS、サーバー、外部スクリプトなどの原因を特定するために使います。
PageSpeed Insightsに表示される改善項目をすべて消す必要もありません。事業上必要なフォーム、アクセス解析、動画、地図などを維持しながら、効果・工数・リスクのバランスを考えて優先順位を決めることが重要です。
また、表示速度改善ではスコアだけを上げてフォームや計測機能を壊さないことも重要です。バックアップ、テスト環境、実機確認、公開後の継続測定までを一つの工程として考える必要があります。
ファーストネットジャパンは、1998年創業・4,000件超の制作実績をもとに、PageSpeed Insightsの診断、WordPressの表示速度改善、サーバー・キャッシュ設定、公開後の保守管理まで一貫してサポートします。「まだ原因がわからない」という段階でも構いません。まずはお気軽にご相談ください。
| 会社名 | 株式会社ファーストネットジャパン |
| 所在地 | 大阪市中央区南久宝寺町1-7-10 シャンクレール南久宝寺201 |
| 設立 | 2004年12月(1998年8月創業) |
| URL | https://gelatocms.com/ |
ホームページの保守・管理にお困りではありませんか?
ファーストネットジャパンでは、1998年の創業以来、4,000件を超える実績で培った知見をもとに、ホームページの更新・保守・セキュリティ対応から、他社で制作されたサイトの引き継ぎ・乗り換えまで総合的にサポートします。
連絡が取れない、放置してしまっているサイトのご相談も承ります。まずはお気軽にお問い合わせください。






