本文へスキップ

Web制作・サイト改善

ホームページの表示速度改善|PageSpeed Insightsの見方と修正の優先順位

点数だけを追わず、お客さまが困る場所から表示速度を改善する。PageSpeed Insightsの読み方と、原因別の修正・検証・相談の進め方を整理します。

ホームページの表示速度を測定し、修正して確認する流れ

「ホームページが少し重い気がする」「PageSpeed Insightsの点数が低いと言われた」。そう聞いても、写真を減らすべきか、サーバーを変えるべきか、制作会社に何を頼めばよいかは判断しづらいものです。

表示速度の改善は、重要なページで起きている不便を確かめ、原因に合った修正を選ぶことから始まります。点数だけを追うと、必要な写真や機能まで削ってしまうことがあります。この記事では、専門の開発担当者がいない企業でも、測定結果を読み、改修の優先順位を相談できるように手順を整理します。

以下の数値・ツール仕様はGoogleの公式資料に基づきます。ページの選び方や作業順は編集部の実務上の提案、業種別の場面は説明用の仮例です。特定サイトの診断結果や、改善効果を保証するものではありません。

1.表示速度改善で目指すのは、迷わず使えること

たとえば、施工事例の写真がなかなか出ない。サービスの説明は読めるのに、メニューを押しても反応しない。問い合わせボタンを押そうとした瞬間に、上の画像が表示されて位置がずれる。これらは、別々の問題です。

表示、操作への反応、画面の安定性という三つの使いやすさ

「速くする」という一言で依頼するより、「誰が、どのページで、何をしようとして困るか」を共有すると、調査の方向が定まります。スマートフォンから相談先を探す人にとって、写真が見えることと、相談へ進めることの両方が必要だからです。

GoogleはCore Web Vitalsをランキングに使用していますが、良い結果が検索上位を保証するわけではありません。SEOのためだけに満点を追うのではなく、全体の使いやすさを改善することが重要だと説明しています。出典:Google 検索セントラル「ページ エクスペリエンス」

2.トップページだけでなく、事業に大切な3ページを選ぶ

最初から全ページを調べようとすると、結果を集めるだけで終わりがちです。まずは「集客の入口」「サービスの検討」「問い合わせ」の代表ページを、一つずつ選ぶ方法をおすすめします。広告用LPが入口なら、そのLPを含めましょう。

集客の入口、サービス紹介、問い合わせの代表ページを選ぶ図
  • 入口:検索や広告から訪れる人が多いページ
  • 検討:商品・サービス・事例を詳しく確認するページ
  • 行動:問い合わせや予約に進むページ

仮に、工務店への相談の多くが施工事例から始まっているなら、トップページの装飾より、施工事例の写真と相談導線を先に確認する判断ができます。入口が分からない場合は、GA4を使った集客予算の考え方も参考に、閲覧されているページと問い合わせの状況を整理してください。

測定前には、自分のスマートフォンでも実際に開きます。端末・ブラウザ・通信環境と、気になった操作を記録しておくと、制作会社が症状を再現しやすくなります。

3.PageSpeed Insightsでは、実ユーザーとラボの結果を分ける

PageSpeed Insightsに対象URLを入力し、分析を実行します。モバイルとパソコンを切り替え、測定日とURLを残してください。最初に見るのは点数の大小だけではなく、どのデータを見ているかです。

過去28日間の実ユーザーデータと今回のラボテストを分けて読む図

実ユーザーのデータは、CrUXという仕組みに基づく過去28日間の集計です。一方、ラボデータは一定の条件で行うテストで、修正箇所を調べる手がかりになります。両者は測っている対象が違うため、数値が一致しなくても不思議ではありません。

さらに「このURL」の結果か、「オリジン」全体の結果かを確認します。オリジンは、同じプロトコル・ホスト名・ポートの範囲を指し、特定の1ページと同じではありません。ページのデータが足りないと、より広い範囲の結果が表示されることがあります。実ユーザーのデータ自体が出ない場合も、速い・遅いを判定できたわけではありません。出典:Google「PageSpeed Insightsについて」

保存する項目は「URL/測定日/端末区分/URL単位かオリジンか/気になる指標/再現した症状」で十分です。ラボテストは複数回行い、最高点だけを採用せず、同じ問題が繰り返し出るかを見ます。

4.LCP・INP・CLSは、それぞれ違う不便を見る指標

Core Web Vitalsの良好な目安はLCP2.5秒以下、INP200ミリ秒以下、CLS0.1以下
  • LCP:画面内の大きな画像やテキストが表示されるまでの時間。良好の目安は2.5秒以下。
  • INP:クリック・タップ・キー操作への応答性。良好の目安は200ミリ秒以下。
  • CLS:予期しないレイアウトのずれの大きさ。良好の目安は0.1以下。秒数ではありません。

実ユーザーデータでは、端末区分ごとに75パーセンタイルで評価します。これは測定値を小さい順に並べたときの75%の位置に当たる値で、平均値とは違います。3指標すべてが目安を満たすことが、Core Web Vitalsの合格の基本です。なお、PSIの通常のLighthouse読み込みテストはINPを直接測るものではありません。ラボ側のTBTを、そのままINPと読み替えないようにしましょう。出典:web.dev「Web Vitals」

5.LCPが遅いときは、画像の容量以外も調べる

大きなメイン画像の表示が遅いと、すぐに「圧縮しよう」と考えがちです。しかし、原因が画像を読み始めるまでの待ち時間なら、容量を減らすだけでは解決しきれません。

LCPが遅いときは画像容量、読み込み順、サーバー応答を切り分ける

制作担当者には、LCPの対象要素を特定し、サーバー応答、画像などの読み込み開始、転送、表示処理のどこで時間を使っているかを確認してもらいます。最初の画面で重要なLCP画像を遅延読み込みの対象にしていないかも点検します。Googleの技術資料では、LCP画像の遅延読み込みを避けるよう説明されています。出典:web.dev「LCPを最適化する」

たとえば「サービスページだけ写真の表示が遅い」なら、そのページ固有の画像や構成を調べます。「複数ページで最初の表示まで長く待つ」なら、共通処理も調査対象です。測定せずに、すべてをサーバーの問題と決めつけないことが大切です。

6.INPが悪いときは、実際に困る操作を再現する

表示が終わっていても、操作が軽いとは限りません。メニューを開く、事例を絞り込む、フォームを入力するといった場面を、利用者と同じ順で試します。

メニュー、絞り込み、フォーム操作の反応を確認する図

INPの調査では、どの操作が遅いかを絞り込むことが重要です。可能であれば実ユーザーの情報を起点にし、開発用ツールで再現して、JavaScriptの処理や画面描画などを調べます。出典:web.dev「INPを最適化する」

依頼する際は「フォームが重い」だけでなく、「スマホで相談種別を選び直すと、入力欄の切り替えが遅い」と伝えましょう。追加したチャット、解析タグ、アニメーションなども確認候補ですが、原因と決まったわけではありません。計測や問い合わせ機能を、根拠なく停止しないようにします。

7.CLSが悪いときは、後から動く場所を探す

読んでいる文章や押そうとしたボタンが動くと、利用者は操作をやり直すことになります。最初の読み込みだけでなく、スクロール後や、埋め込みコンテンツが出たときも観察してください。

画像などの表示領域を先に確保し、レイアウトのずれを抑える図

代表的な対策は、画像・動画の幅と高さ、または縦横比を指定して、読み込み前に必要な場所を確保することです。広告や外部コンテンツなど、後から挿入される要素も確認します。出典:web.dev「CLSの最適化」

仮に事例写真の表示で相談ボタンが押し下げられているなら、写真を削る前に表示領域の確保を検討できます。画面録画や、ずれる直前・直後の画像があると、修正対象を共有しやすくなります。

8.写真や動画は、伝える役割を残して軽くする

施工の質感、スタッフの雰囲気、商品の細部。こうした情報は、写真だから伝わる場合があります。速度改善を理由に一律に画像を削ると、検討材料まで失われかねません。

写真の訴求力を残しながら画質、サイズ、読み込み方法を整える図

編集部が提案する進め方は、まず各画像を「判断に必要」「補助説明」「装飾」に分けることです。必要な写真は実際の表示サイズに合うデータを用意し、圧縮後も質感や文字が読めるかを確認します。最適な容量は画像の内容や表示条件で変わるため、全画像に同じ上限値を当てはめる必要はありません。

動画も、自動再生が本当に必要か、静止画から再生する形でも目的を満たせるかを検討します。ページ下部の素材と、最初に見せる主役の画像では、読み込み方を分けて考えます。今回のように図解が多い記事も、適切なサイズ・圧縮・表示領域の指定をセットで行うことが大切です。

9.修正順は「事業への影響・症状・工数」で決める

診断結果に項目が並んでも、上から全部直す必要があるとは限りません。次の三つを並べて、担当者と優先順位を決めます。

事業への影響、症状、工数とリスクから修正の優先順位を決める図
  1. 事業への影響:見込み客の多い入口か、問い合わせに近い操作か。
  2. 症状の強さ:実際に困る場面が再現するか、複数ページに共通するか。
  3. 工数とリスク:部分修正で対応できるか、機能やデザインへの影響は何か。

説明用の例として、広告で使うサービスページの主役画像が遅く、画像の修正だけで対応できそうなら、先に小さく試す判断があります。一方、問い合わせフォームで操作が止まるなら、アクセス数が少なくても優先度は高くなり得ます。単純な閲覧数順では決められません。

逆に、ほとんど見られない旧記事の点数を上げるために大きな改修をするより、今の相談導線の不具合を直す方が、事業上の意味が大きい場合があります。どのページも正常に使えているなら、残る課題と費用を見て、対応を見送る選択もできます。

10.改修後は、数字と機能の両方を確かめる

高速化の設定は、表示や動作に影響することがあります。特にWordPressでは、キャッシュやJavaScriptの読み込み設定を一度に変えず、変更内容を記録しながら進めることをおすすめします。

変更前の保存、テスト、公開、再測定の順で安全に改修する流れ
  1. 変更前の状態を保存し、戻す方法と担当者を決める。
  2. テスト環境などで変更し、メニュー・フォーム・予約導線を確認する。
  3. 公開後、同じURL・端末区分で再測定する。
  4. 問い合わせの到達確認と、設定した計測が動いているかを確認する。

実ユーザーの集計には過去の期間が含まれるため、公開直後のラボ結果と同じタイミングでは置き換わりません。直後は不具合と再現テストを確認し、その後に実ユーザー側の推移を追います。

問い合わせ数を比較するときも、広告量や流入経路、季節要因などの変化を一緒に記録してください。改修後に問い合わせが増えたというだけでは、速度だけが原因とは断定できません。「不便が解消したか」と「事業の結果がどう動いたか」を分けて見ておくと、次の判断がしやすくなります。

11.制作会社には「対象URL・症状・結果・残したい表現」を渡す

相談時に、専門用語をすべて覚えている必要はありません。次の四つを整理すると、調査や見積もりの前提がそろいます。

表示速度改善の相談で共有するURL、操作、測定結果、残したい表現
  • 対象URL:どのページで、何をしてもらいたいか。
  • 困る操作:どの端末・場面で、どんな待ちやずれがあるか。
  • 測定結果:測定日、端末区分、URL単位かどうかを添えた結果。
  • 残したい表現:大切な写真、動画、予約や計測の機能。

そのうえで「原因調査」「修正」「公開後の検証」のどこまで含むか、作業範囲を確認します。プラグインを追加すれば必ず直る、サーバーを変えれば必ず速くなる、と決め打ちせず、調査結果に合わせて選びましょう。

まとめ|まずは、大切な1ページを測ってみる

表示速度改善の出発点は、点数を眺めることより、お客さまが困る場所を見つけることです。大切なページを選び、実ユーザーとラボのデータを分け、LCP・INP・CLSに対応する症状を確かめる。その後で、事業への影響と工数を踏まえて修正を選びます。

MADE IN CREWでは、Web制作・LP制作において、写真やコピーなどの伝える内容と、スマートフォンでの見やすさ、表示速度、問い合わせ導線を合わせて考えます。改修範囲を決める前に、まず自社のページで何を残し、何を直すべきかを整理したい方は、Web制作・LP制作サービスをご覧ください。Webサイト改善について相談する

参考にした一次資料

確認日:2026年10月17日。ツールの表示や仕様は変更される場合があります。

Contact

SEOコンテンツ・Web制作のご相談はMADE IN CREWへ

「検索から問い合わせにつながる記事をつくりたい」「Webサイトからの集客を強化したい」。MADE IN CREWは、戦略設計からコンテンツ制作・サイト制作まで一貫して支援します。まずは無料相談からお気軽にご連絡ください。