サイトが遅いと感じたら、まず遅いページと場面を特定します。画像を一括で圧縮したり、キャッシュ用のプラグインを増やしたりする前に、スマートフォンとPCで同じURLを測り、何が表示や操作を妨げているかを確認しましょう。この記事では、小さな事業者のホームページを想定し、測定、優先順位、画像・コード・キャッシュの見直し、公開後の確認までを順に説明します。
最初に、遅いページを同じ条件で測る
トップページだけが速くても、サービス紹介や問い合わせページが遅ければ利用者は困ります。まず「訪問が多いページ」「画像が多いページ」「問い合わせなど重要な操作を行うページ」から数ページを選びます。各URLをPageSpeed InsightsでスマートフォンとPCに分けて確認し、測定日、URL、端末、気になった箇所を記録してください。
PageSpeed Insightsには、実際の利用者のデータと、検査用の環境で測ったデータが表示されます。実利用データは直近28日間の傾向で、十分なデータがないページではサイト全体の値だけが出るか、値が表示されない場合もあります。検査用データは原因を探す手掛かりですが、1回の点数だけで利用者全員の体験を決めつけないでください。
確認する主な指標は、主要な内容が見えるまでのLCP、クリックやタップへの反応を示すINP、表示中の予期しないずれを示すCLSです。Googleが示す「良好」の目安は、実利用データの75パーセンタイルでLCPが2.5秒以内、INPが200ミリ秒以下、CLSが0.1以下です。どれか一つの数値だけを目標にせず、実際のページで読めるか、操作できるかも見ます。
測定する際は、読み込み直後の見た目だけでなく、メニューの開閉、ボタン、フォーム入力を試します。どの端末・操作で困るかが分かれば、制作会社や保守担当にも具体的に相談できます。
数値と画面を見て、直す場所を絞る
- LCPが遅い：最初に大きく見える画像、サーバーの応答、読み込みを妨げるCSSやフォントを確認します。どの要素がLCPになっているかを検査結果で確かめます。
- INPが悪い：タップ後の反応を妨げるJavaScriptや外部の埋め込み、重い処理を疑います。実際に遅い操作を再現してから対象を絞ります。
- CLSが大きい：読み込み中に画像、広告、埋め込み、文字が動かないか確認します。画像の幅と高さを指定し、必要な表示領域を先に確保します。
遅さの原因はページごとに異なります。たとえば商品写真が重いページと、予約フォームの動作が遅いページに、同じ設定変更をまとめて適用しない方が安全です。修正する項目を一つ選び、変更前の状態を残してから試します。
画像は「表示場所・大きさ・読み込み順」で見直す
画像の点検では、まず画面に大きく出る一枚から始めます。表示幅に対して極端に大きな元画像を送っていないか、スマートフォンでもPC用の大きなファイルだけを配信していないかを確認します。必要なら表示場所に合う寸法へ書き出し、WordPressのレスポンシブ画像機能が適切なサイズを選べる状態にします。
写真は画質を見ながら圧縮し、配信環境が対応する場合はWebPやAVIFも比較します。形式を変えれば必ず速くなるわけではありません。元画像より小さくなったか、細部が崩れていないか、実際の端末で表示できるかを確認します。個別の画像をどう選ぶかは画像圧縮の点検手順でも説明しています。
ページを開いた直後に見える大きな画像は、LCPの対象になることがあります。その画像を遅延読み込みにすると、表示開始がかえって遅れる場合があります。一方、画面の下の方にある画像にはブラウザ標準のloading="lazy"を使えます。画像のwidthとheightも指定し、読み込み前から表示領域を確保すると、画面のずれを抑えやすくなります。
CSSとJavaScriptは、必要なものを残して調整する
CSSはページの見た目を決め、JavaScriptはメニューやフォームなどの動きに関わります。読み込むファイルが多い、使っていない機能のコードが残っている、外部サービスの処理が重いといった場合は、表示や操作の妨げになります。ただし、ファイルを機械的に結合・圧縮すれば必ず改善するわけではありません。
制作・保守担当には、検査結果の「未使用のコード」「描画を妨げるリソース」「長い処理」などを見てもらい、実際に不要なものだけを外すよう依頼します。読み込み順やdefer、asyncの設定を変える場合は、依存関係を確認してください。問い合わせフォーム、メニュー、計測タグなどが動かなくなることがあります。
特にWordPressでは、テーマ、プラグイン、計測・チャットなどの外部サービスが同じページへコードを追加します。使っていないプラグインや埋め込みを調べ、必要な機能を確認してから整理します。速度改善のための変更でも、フォームや計測の動作確認を省かないことが大切です。
キャッシュとサーバー設定は、更新の仕組みと合わせる
キャッシュは、同じデータを毎回作り直したり取り直したりする負担を減らす方法です。画像やCSSなどの静的ファイルではブラウザキャッシュ、WordPressのページ表示ではサーバー側のキャッシュが役立つことがあります。ただし、更新した内容が古いまま表示されると困るため、公開後の反映方法もセットで決めます。
まず現在のサーバー、WordPress、既存のキャッシュ機能を確認します。同じ目的のプラグインを重ねる前に、どの層でキャッシュしているか、更新時に誰が削除するか、管理画面やフォームなどキャッシュしてはいけない部分は何かを整理してください。静的ファイルの有効期間を長くする場合は、変更時に新しいファイル名やバージョンで配信できるかも確認します。
CDNは配信距離や負荷の問題に役立つ場合がありますが、導入だけでどのサイトも速くなるわけではありません。利用者の地域、元サーバーの状態、画像やコードの重さを測ってから検討します。DNSやキャッシュ設定を伴うため、導入・変更時は復旧手順とフォームなどの動作確認を用意しましょう。
スマートフォンでは「表示できる」と「使える」を分けて確認する
レスポンシブデザインでも、スマートフォンへ大きな画像や不要なコードを送っていれば通信量は減りません。画面幅を縮めただけで速度が改善したと判断せず、スマートフォン側の実際の読み込みと操作を確認します。
確認するのは、見出しや画像がはみ出さないか、ボタンを押しやすいか、メニューとフォームが動くか、読み込み中に位置がずれないかです。通信が遅い場所や古い端末での利用も想定し、最初に必要な情報へたどり着ける構成を優先します。外部の動画、地図、チャットなどは便利ですが、そのページで本当に必要かを見直せます。
改善は一度に一つずつ、公開前後で比較する
- 対象を決める：実際に遅いURL、端末、操作を記録し、PageSpeed Insightsの実利用データと検査用データを区別する。
- 変更前を残す：画像の元ファイル、テーマや設定、測定結果を保存し、元に戻す方法を確認する。
- 一つ変える：最初の大きな画像、不要な外部コード、キャッシュ設定など、原因に近い項目から試す。
- 表示と動作を確かめる：PCとスマートフォンで見た目、メニュー、問い合わせ、計測を確認してから公開する。
- 同条件で比較する：同じURLと端末で再測定する。検査用の結果はすぐ比較できる一方、実利用データには反映まで時間がかかる。
速度の数値が良くなっても、文章が読みにくくなったり問い合わせが送れなくなったりすれば改善とは言えません。検索順位や売上の上昇も、速度変更だけで保証できません。表示・操作・問い合わせを守りながら、原因と効果が分かる単位で進めましょう。WordPressの更新や保守を含めて相談したい場合は、Bämの保守・管理をご覧ください。
よくある質問
PageSpeed Insightsの点数は100点を目指すべきですか？
点数は改善箇所を探すための目安です。100点だけを目的にすると、必要な写真や機能まで外してしまうかもしれません。実利用データ、重要な操作、ページの役割を合わせて判断します。
実利用データが表示されないページは、問題がないという意味ですか？
いいえ。対象URLの利用データが足りない場合などは表示されません。検査用データと実機での確認を使い、必要に応じてサイト全体の傾向も参考にします。
改善したのに、すぐ実利用データが変わらないのはなぜですか？
実利用データは過去の一定期間の体験を含みます。公開直後は古い期間のデータが残るため、検査用データで表示と動作を確かめたうえで、日を置いて同じURLを確認してください。
参考資料
- Google for Developers「PageSpeed Insights について」（2026年10月5日確認）
- web.dev「Web Vitals」（2026年10月5日確認）
- web.dev「Largest Contentful Paint を最適化する」（2026年10月5日確認）
- web.dev「Cumulative Layout Shift の最適化」（2026年10月5日確認）
- Google 検索セントラル「ページ エクスペリエンスと Google 検索結果への影響」（2026年10月5日確認）
