ホームページが遅いときは？表示速度の確認と改善の優先順位表

改修する場所と順番を整理するイメージ（AI生成）

ホームページの表示速度を改善するときは、先に対象ページと遅い症状を決め、測定結果から原因を絞ります。画像の圧縮やサーバー変更をまとめて試す前に、「どこで利用者が待つのか」を確かめるためです。この記事では、専門の開発担当がいない中小企業向けに、PageSpeed Insightsの読み方、改修の優先順位表、制作会社へ渡せる依頼表を紹介します。自社で確認する範囲と、技術担当へ任せる範囲も分けて進められます。

1. 遅いページと、困っている操作を一つ選ぶ

ホームページの表示速度改善は、サイト全体を一度に直そうとすると依頼範囲が広がります。まずは「どのページを、どんな端末で開いたとき、何が待たされるのか」を一つ書き出してください。トップページが遅いのか、サービス紹介の写真が出ないのか、メニューを押しても反応がないのかで、調べる場所は変わります。

候補が複数ある場合は、問い合わせまでの経路にあるページから着手します。アクセス解析が使えるなら利用されているページを参考にし、データがなければ営業で案内しているページを選びます。「一番遅そう」という感覚だけで選ばず、選んだ理由を残すのがこの確認表の使い方です。

点数を上げる目的と、相談しやすいサイトをつくる目的を分ける

GoogleはCore Web Vitalsを検索の評価に用いる一方、良好な数値でも上位表示を保証するものではないと説明しています。診断ツールの満点だけを目的にせず、読みやすさや使いやすさも含めてページを確認しましょう。

出典：ページエクスペリエンスとGoogle検索

たとえば、サービス内容を説明する写真をすべて削れば、読者が完成品や対応範囲を理解しにくくなるかもしれません。残す写真の役割を決めたうえで、配信方法を見直します。目的は「商品を確認し、必要なら相談へ進める状態」です。改修の依頼書にも、その状態を先に書いておくと判断がぶれません。

2. PageSpeed Insightsで測定条件をそろえる

PageSpeed Insightsは、入力したURLについてモバイルとパソコンのレポートを確認できるGoogleのツールです。実際の利用者から集めたフィールドデータと、一定の条件でページを読み込むラボデータがあり、役割が異なります。前者は利用時の傾向、後者は原因を調べる手掛かりとして読みます。

出典：PageSpeed Insightsについて

URL・端末・データの範囲を記録する

PageSpeed Insightsを開き、公開中の対象ページのURLを入力して分析します。結果が出たらモバイルとパソコンをそれぞれ確認し、結果のURLや画面を保存してください。管理画面のプレビューURLではなく、利用者が実際に見る公開URLを使います。ログインが必要な画面の診断は、管理者と別途方法を相談します。

実ユーザーデータが表示される場合は、「このURL」なのか「オリジン」なのかも確認します。URL単位のデータが少ないと、同じオリジンの集計へ切り替わることがあります。オリジンは、通信方式・ホスト名・ポートで区切られる範囲です。別のサブドメインまで同じ集計だと考えず、画面に表示された対象を記録します。

出典：PageSpeed Insightsについて

そのまま使える測定メモ

表が収まらない場合は横にスクロールできます →

前後を比べるときは、URLとモバイル／パソコンの区分をそろえます。ラボ結果は同じページでも変動するため、一回の点数差で結論を出さず、必要に応じて同じ条件で複数回確認します。記録には各回の値を残し、良い値だけを選んだ報告にしないでください。

出典：PageSpeed Insightsについて

実ユーザーデータがない場合は、未取得のまま進める

公開直後やデータ量が少ないページでは、実ユーザーデータが表示されない場合があります。それは「速度が0秒」「問題なし」という意味ではありません。ラボ診断と実際の端末での操作確認を進め、フィールドの欄は「データなし」と記録します。

出典：PageSpeed Insightsについて

測定結果を保存できたら、すぐに設定を変える前に、次の章で症状と指標を対応させます。スクリーンショットだけを制作会社へ送る場合も、「どの操作で困っているか」を一文添えてください。赤い項目の一覧だけより、調査の入口が明確になります。

3. LCP・INP・CLSを症状の切り分けに使う

Core Web Vitalsには、主な内容の表示をみるLCP、操作への応答をみるINP、表示の安定性をみるCLSがあります。画面が出るまでの待ち時間だけでなく、表示後に使えるか、意図せず位置がずれないかも別に確認する指標です。

出典：Core Web VitalsとGoogle検索

症状と指標の対応表

表が収まらない場合は横にスクロールできます →

出典：PageSpeed Insightsについて

出典：Core Web VitalsとGoogle検索

表の目安はGoogleの基準です。フィールドの判定では75パーセンタイル値を用います。これは観測値を小さい順に並べたとき、およそ75%がその値以下になる位置の値です。自分のスマホで一度だけ速く表示されたことを、利用者全体で良好だった証拠にはしません。

出典：PageSpeed Insightsについて

一つの指標から原因を決めつけない

LCPが遅い場合でも、画像のファイル容量だけが原因とは限りません。Googleの解説では、最初の応答を待つ時間、必要な素材を読み始めるまでの遅れ、転送、画面へ描画するまでの遅れを分けて考えています。まず、遅れている対象と段階を制作担当に特定してもらいます。

出典：Largest Contentful Paintを最適化する

INPに課題があるなら、実際に遅いメニューやボタン、そのときの端末を伝えます。CLSに課題があるなら、どの部分が動くかを短い録画で残すと共有しやすくなります。原因の候補を絞るための記録であり、録画に写った一回の現象だけでサイト全体を評価するものではありません。個人情報が写る画面は共有から外してください。

指標を調べても症状が再現しなければ、発生条件を追加します。特定のブラウザだけか、初回表示だけか、画像の差し替え後からかを聞き取り、分かったことと未確認のことを分けます。「不具合なし」で閉じず、次に誰がどの条件で確かめるかを決めておきましょう。

4. 改善の順番は、原因と事業への影響で決める

作業の順番は「画像から必ず着手」と固定せず、対象ページへの影響と確認できた原因で決めます。以下はVELGRIT編集部が依頼整理用にまとめた判断表です。効果の実測値や、すべてのサイトに当てはまる実装順ではありません。

調査・改修候補を並べる優先順位表

表が収まらない場合は横にスクロールできます →

画像が原因なら、容量と読み込み方を分ける

大きな画像がLCPの対象なら、必要な表示寸法に合う画像を配信しているか、読み込み開始が遅れていないかを調べます。圧縮や形式の変更だけで全体の待ち時間が短くなるとは限りません。また、LCP画像を遅延読み込みにすると開始が遅れるため、ページ内の全画像へ一律に同じ設定を当てないようにします。

出典：Largest Contentful Paintを最適化する

社内担当が素材を準備するなら、元の画像を残し、掲載URL・使用箇所・差し替え候補を一覧にします。製品の細部や文字が読み取れるかも確認してください。制作会社には「画質を落とせばよい」ではなく、「この説明に必要な部分は残したい」と伝えると、容量と見やすさの両方を検討できます。

画面がずれる場合は、表示する場所を先に確保する

画像や動画の領域を事前に確保していないことは、レイアウトのずれの原因になります。Googleの解説ではwidth・height属性やCSSのaspect-ratioなどで必要な空間を確保する方法を示しています。実装は制作担当へ渡し、スマホでも比率が崩れないか確認します。

出典：Cumulative Layout Shiftを最適化する

改修候補が複数あるときは、変更の単位を分けてください。画像の差し替え、キャッシュ設定、読み込み順の変更を同時に行うと、どの変更で改善したか、どの変更で操作が壊れたかを追いにくくなります。作業者には、検証する順序と元に戻す方法も見積もりに含めてもらいます。

5. 制作会社へ渡す依頼表と、作業の境界を決める

社内で進める範囲は、対象URL・症状・素材・業務への影響を集めるところまででも十分です。サーバー変更やキャッシュ設定、プログラムの読み込み制御は、運用環境と必要な機能を把握している担当へ依頼します。設定画面を開けることと、安全に変更できることは別に考えます。

キャッシュは、一度用意した内容を再利用する仕組みです。どのページや利用者に適用するかを確認せず、ログイン後の画面や入力フォームまでまとめて設定を変えるのは避けます。フォーム、会員機能、カートなどがある場合は、その存在を最初に伝え、変更後にどの動作を検証するか相談してください。

制作会社へ渡す依頼表

見積もりを受け取ったら、「高速化一式」の内訳を確認します。原因調査、改修、検証、作業後の確認がそれぞれ含まれるか、原因が追加で見つかった場合にどこまで対応するかをそろえてください。費用や日数はサイトの構造と作業範囲で変わるため、点数の低さだけで一律に決めないほうが比較しやすくなります。

既存サイトを別の会社へ引き継ぐ場合は、契約範囲や更新方法、必要な管理権限を先に確認します。パスワードを依頼表へ直接書かず、共有方法を担当同士で決めてください。VELGRITでも、他社制作サイトの改修は事前調査で構造と対応範囲を確認してから進めます。

6. 完了条件は、速度・操作・再測定をセットにする

納品時は、数値が変わったことと、利用者が必要な操作をできることを両方確認します。トップページが速くても、メニューからサービスページへ進めない状態では完了にできません。相談の導線なら、ボタンの移動先、入力、エラー表示、受付完了までを担当者と確認します。テスト送信をする場合は受信担当と日時を合わせ、実績に含めない記録を残してください。

改修後の完了チェック

表が収まらない場合は横にスクロールできます →

PSIのフィールドデータは過去28日間を扱います。変更直後には改修前の期間も含まれるため、直後のラボ確認と、後日の実ユーザーデータ確認を分けます。日付だけで改善完了とせず、表示された期間とデータの有無を見て判断してください。

出典：PageSpeed Insightsについて

検索順位や問い合わせ件数は、速度の指標とは別の欄で追います。同時に広告を増やした、記事を公開した、季節要因があった場合は、その条件も記録します。問い合わせが増えても、その変化を速度改修だけの成果と決めつけない運用にしておくと、次の投資判断に使える記録になります。

月次の点検では、対象URL、変更履歴、残る症状、次の確認日を一行で見返せる形にします。画像の追加や外部サービスの導入など、ページの構成を変えた際は再確認する担当を決めておきましょう。毎回すべてを調べ直すより、変更に関係する箇所から確認を始められます。

よくあるご質問