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

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


この記事でわかること
- PageSpeed Insightsの基本的な使い方
- フィールドデータとラボデータの違い
- スコアとCore Web Vitalsの見方
- LCP・INP・CLSなどを改善する方法
- 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パーセンタイルの値が使われます。簡単にいえば、利用者の75%以上が基準内で利用できているかを確認する考え方です。詳しい仕組みは、GoogleのCore Web VitalsとGoogleツールの解説でも確認できます。
URL単位のデータが不足している場合は、サイト全体を表すオリジン単位のデータだけが表示されることがあります。公開直後のページやアクセス数が少ないページで「データがありません」と表示されても、測定エラーとは限りません。
ラボデータは原因調査に使う
ラボデータは、Lighthouseが一定の端末・通信条件を想定して測定した結果です。実ユーザーの平均値ではなく、問題の発見や改修前後の比較に向いています。
フィールドデータでLCPが悪い場合に、ラボデータでLCP対象画像、サーバー応答、レンダリングを妨げるCSSなどを調べる、という使い方が基本です。
フィールドデータとラボデータの数値が異なっていても、どちらかが間違っているわけではありません。利用者の端末性能、通信環境、キャッシュ、アクセス地域、測定時のサーバー負荷などが異なるためです。
PageSpeed Insightsの使い方
1. 測定したいページのURLを入力する
PageSpeed Insights公式サイトへアクセスし、測定したいページのURLを入力して「分析」をクリックします。

画面構成は更新されることがありますが、基本操作はURLを入力して分析するだけです。
2. モバイルとパソコンを切り替える
分析結果は、モバイルとパソコンに分けて表示されます。一般的には、端末性能や通信環境の制約が大きいモバイルの方が、パフォーマンススコアは低くなりやすい傾向があります。
自社サイトのアクセスの多くがスマートフォンからであれば、モバイルを優先します。ただし、BtoBサイトではパソコンからの閲覧や問い合わせも多いため、Google Analyticsなどで実際のデバイス比率を確認したうえで判断することが重要です。
3. 実際のユーザー環境を確認する
最初に「実際のユーザーの環境で評価する」「実際のユーザーが体験していることを確認する」などと表示される領域を確認します。
ここでは、主に次の内容を見ます。
- Core Web Vitalsに合格しているか
- LCP・INP・CLSのうち、どの指標が基準を外れているか
- URL単位とオリジン単位で差があるか
- モバイルとパソコンで差があるか
- TTFBやFCPがLCPを遅らせていないか
4. パフォーマンスの問題点を確認する
次にLighthouseのパフォーマンススコアと、改善候補・診断項目を確認します。

改善候補には、画像配信、JavaScript、CSS、キャッシュ、サーバー応答、外部スクリプトなどが表示されます。ただし、表示された項目を上から機械的に修正するのではなく、実ユーザーデータへの影響、改修工数、表示崩れのリスクを考えて優先順位を決めます。
PageSpeed Insightsのスコアの見方

パフォーマンススコアは3段階で表示される
| スコア | 評価 | 表示色 |
| 90~100 | 良好 | 緑 |
| 50~89 | 改善が必要 | オレンジ |
| 0~49 | 低い | 赤 |
このスコアは、Lighthouseの複数の指標を重み付けして算出したものです。スコア100は必須ではなく、同じページでも測定時のサーバー負荷や外部スクリプトなどによって数値が変わることがあります。
Googleも、SEOだけを目的として完璧なスコアを目指すことが、必ずしも時間の有効な使い方ではないと説明しています。まずはCore Web Vitals、利用者の体感、問い合わせに関わる機能を優先します。スコアの算出方法は、Chrome DevelopersのLighthouseのパフォーマンススコア解説を参照してください。
PageSpeed InsightsのスコアとSEO順位は同じではない
Core Web VitalsはGoogle検索のランキングシステムで利用されていますが、スコアが高いだけで上位表示されるわけではありません。検索意図への適合、コンテンツの品質、専門性、サイト構造、被リンクなども検索順位に影響します。Googleのページエクスペリエンスに関する公式解説でも、Core Web Vitalsだけで上位表示が保証されるわけではないと説明されています。
また、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が悪い:画像サイズ、広告枠、フォント、後から挿入される要素を確認
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でよく表示される改善項目
画像を適切なサイズにする
大きな画像をCSSだけで縮小表示すると、画面に不要な容量まで読み込むことになります。パソコン・タブレット・スマートフォンに応じた画像を配信し、表示サイズに合わせます。
WebPやAVIFへの変換も有効ですが、変換しただけで十分とは限りません。元画像の寸法、圧縮率、画質、レスポンシブ画像の設定まで確認します。
レンダリングを妨げるリソースを減らす
初期表示に不要なCSSやJavaScriptが先に読み込まれると、画面表示が遅れます。ファーストビューに必要なCSSを優先し、その他を後から読み込む設計が有効です。
ただし、ファイルを一律に遅延させると、デザイン崩れや機能停止が起こる可能性があります。ページ単位で検証しながら進めます。
使用していないJavaScript・CSSを削減する
テーマやプラグインは、利用していない機能のファイルまで全ページで読み込むことがあります。必要なページだけで読み込む、機能の重複をなくす、不要なライブラリを削除するといった対策が有効です。
キャッシュの有効期間を設定する
画像、CSS、JavaScriptなどの静的ファイルに適切なキャッシュ期間を設定すると、再訪問時の読み込み量を減らせます。
一方、更新頻度が高いファイルに長いキャッシュを設定すると、修正内容が反映されにくくなります。ファイル名のバージョン管理やキャッシュ削除の運用も必要です。
第三者スクリプトの影響を減らす
アクセス解析、広告、SNS、動画、地図、チャット、ヒートマップなどの外部スクリプトは、自社サーバーだけでは制御できない負荷を発生させます。
利用目的が重複しているツールを整理し、必要なページや同意取得後だけで読み込むなど、事業上の必要性と速度のバランスを取ります。
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・会員機能、外部システム連携、サーバー移行の有無によって金額は変動します。また、スコア保証ではなく、対象ページ、改善項目、機能維持、測定方法を明確にした見積もりを依頼することが重要です。
自社対応と外注の判断基準
| 状況 | 自社対応が向く | 外注が向く |
| 画像圧縮 | 更新ルールを決められる | 大量の既存画像を一括整理したい |
| キャッシュ設定 | テスト環境と復旧手順がある | 更新反映やログイン機能への影響が不安 |
| CSS・JavaScript | 実装担当者が社内にいる | テーマやプラグインを含めた調査が必要 |
| サーバー・DB | インフラ担当者がいる | 移行・障害・セキュリティを含めて任せたい |
| 継続運用 | 定期測定と更新ルールを社内化できる | 保守と速度監視をまとめて依頼したい |
自社で対応できる範囲から始めることに問題はありません。ただし、CSS・JavaScript・キャッシュ・サーバー設定は相互に影響するため、公開サイトで試行錯誤すると障害につながる可能性があります。
ファーストネットジャパンの表示速度改善・保守サポート
ファーストネットジャパンは、1998年創業・大阪市中央区に拠点を置くWeb制作会社です。4,000件超の制作実績をもとに、ホームページの企画・制作からWordPress、システム、サーバー、公開後の保守・改善まで一貫して対応しています。
表示速度改善の対応内容
- PageSpeed Insights・Core Web Vitalsの現状診断
- 重要ページと改善優先順位の整理
- 画像・フォントの最適化
- CSS・JavaScriptの読み込み改善
- WordPressテーマ・プラグインの調査
- キャッシュ・CDN・サーバー設定の調整
- データベース・自動処理の確認
- フォーム・計測タグ・主要機能の動作確認
- 改修前後の測定結果の報告
- 公開後の保守・定期モニタリング
ご相談から改善までの流れ
- 対象URL・課題・運用状況の確認
- 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、サーバー、外部スクリプトなどの原因を特定するために使います。
表示速度改善では、スコアだけを上げてフォームや計測機能を壊さないことも重要です。バックアップ、テスト環境、実機確認、公開後の継続測定までを一つの工程として考える必要があります。
ファーストネットジャパンは、1998年創業・4,000件超の制作実績をもとに、PageSpeed Insightsの診断、WordPressの表示速度改善、サーバー・キャッシュ設定、公開後の保守管理まで一貫してサポートします。「まだ原因がわからない」という段階でも構いません。まずはお気軽にご相談ください。
| 会社名 | 株式会社ファーストネットジャパン |
| 所在地 | 大阪市中央区南久宝寺町1-7-10 シャンクレール南久宝寺201 |
| 設立 | 2004年12月(1998年8月創業) |
| URL | https://gelatocms.com/ |
ホームページの保守・管理にお困りではありませんか?
ファーストネットジャパンでは、1998年の創業以来、4,000件を超える実績で培った知見をもとに、ホームページの更新・保守・セキュリティ対応から、他社で制作されたサイトの引き継ぎ・乗り換えまで総合的にサポートします。
連絡が取れない、放置してしまっているサイトのご相談も承ります。まずはお気軽にお問い合わせください。






