Server

表示速度改善の基本と最初に見るポイント

執筆・編集:遊馬 祥一郎公開:内容更新:

表示が遅いと感じても、画像・通信・JavaScript・サーバーのどこが原因かはページによって違います。まず症状を記録し、計測結果から1か所ずつ直す流れを整理します。

1. 変更する前に、同じページを同じ条件で測る

トップだけでなく、画像の多い記事、比較表のある記事など、困っているページのURLを選びます。「最初の画像が遅い」「検索ボタンの反応が遅い」「読み込み中に文章が動く」を区別し、端末・ブラウザ・確認日を記録してください。

PageSpeed Insightsに公開URLを入力し、モバイルとデスクトップを分けて確認します。会員専用ページや秘密のURLを外部の計測サービスへ入力しないでください。

総合スコアだけでなく、遅い要素や改善候補を確認します。当サイトの進め方としては、同じ条件で複数回測り、最も良い1回だけを採用せず、値のばらつきも残す方法を提案します。異なる端末条件の結果を、そのまま改善前後として比較しないようにしましょう。

2. 実際の利用者データとラボテストを分けて読む

PageSpeed Insightsには、条件を満たす場合に表示される過去28日間の実際の利用者データと、テスト環境で行うラボ計測があります。ページ単位かサイトのオリジン単位かも確認してください。利用者データが足りず表示されないことは、速度が悪いという判定ではありません。変更直後に過去の集計全体が切り替わるわけでもありません。GoogleのPageSpeed Insightsの説明を参照できます。

Core Web Vitalsの「良好」の目安
指標何を見るか・目安
LCP画面内の主な内容が表示されるまで。2.5秒以下。
INPクリックなどの操作に対する応答性。200ミリ秒以下。
CLS予期しないレイアウトのずれ。0.1以下。秒数ではありません。

上の基準は、モバイル・デスクトップを分けた75パーセンタイルで評価します。1回のテスト結果だけで実際の利用者全体の合否を決めません。通常のLighthouseのページ読み込みテストにあるTBTはINPそのものではなく、処理の詰まりを調べる手がかりです。出典: GoogleのWeb Vitals解説(2026年9月10日確認)。

3. 症状から、最初に調べる場所を絞る

次の表は原因を断定するものではなく、調査の入口です。計測で示された要素と、実際に困っている操作が一致するかを確認します。

症状と確認する候補
症状先に確認すること
主な画像や見出しが遅いLCPの対象要素、画像の容量・取得開始、表示を待たせるCSSやフォント、サーバー応答を確認します。
検索やメニューの反応が遅いその操作中のJavaScript処理や外部スクリプトを確認します。プラグインの個数だけで原因を決めません。
文章やボタンが途中で動く画像・埋め込みの表示領域、フォントの切り替え、後から追加される要素を確認します。
ページ全体の応答を待つ同じ時間帯の複数ページで再現するか、キャッシュの有無、サーバー側の処理を調べます。契約変更は切り分けの後に検討します。

4. 画像は容量・表示領域・読み込み順を確認する

大きな画像が見つかったら、元画像を残したうえで、表示に必要な寸法と品質に調整します。軽くした後も文字や商品写真が読めるか確認してください。すべての画像に一律の容量上限を当てはめるのではなく、用途と計測結果で判断します。

画像の幅・高さなどで表示領域をあらかじめ確保すると、読み込みに伴うずれを抑える助けになります。具体的な確認は画像サイズとレイアウトのずれを確認する記事へ進めます。

画面外の画像は遅延読み込みの候補ですが、最初から見える主要画像まで一律にloading="lazy"にしないでください。特にLCPになる画像は読み込みを遅らせないようにします。出典: ブラウザの画像遅延読み込みの解説。

5. スクリプトとキャッシュは、役割を確認して変更する

使っていない機能でも、何か別の処理が依存している可能性があります。変更前のコピーを取り、検証環境で1つずつ試します。WordPressの検証環境で確認する項目も参考になります。複数の最適化機能をまとめて有効にすると、不具合の原因を追いにくくなります。

広告・同意管理・フォーム・計測のスクリプトを、スコアのためだけに削除しないようにしましょう。遅延や読み込み順を変える場合も、必要な操作が動くかを確認します。テスト目的で自分の広告をクリックしてはいけません。

キャッシュは速さだけでなく、最新の内容を返すことも重要です。ログイン情報、フォームのトークン、予約公開ページなどを一律に長期間キャッシュする設定は避け、サイトの構成に合わせて確認します。更新が見えない場合は古い表示が残るときの確認手順で、ブラウザ・サーバーなどを順に切り分けます。

6. 変更後は、速さと使えることの両方を確かめる

  1. 条件を合わせて再計測: 同じURL・端末設定で、変更前と同じ項目を確認します。
  2. 操作を確認: スマホのメニュー、記事検索、比較表、フォームの入力・送信処理など、変更が影響する部分を確認します。送信テストは専用環境・テスト用宛先で行い、本番の問い合わせ実績と混ぜません。
  3. 見た目を確認: 画像の欠落、文字の読みにくさ、表示のずれ、押せないボタンがないか見ます。
  4. 結果を記録: 変えた項目、計測条件、値のばらつき、操作確認、戻す方法を残します。悪化した場合は変更を戻して原因を確認します。

記録例: 「記事上部の画像を縮小。モバイルのラボLCPを同条件で3回計測し、3.4〜3.8秒から2.8〜3.1秒になった。画像の文字とメニュー操作を確認済み。利用者データは集計待ち」。この数値は当サイトの計測実績ではありません。

スコアが上がっても、それで収益や検索順位が上がったことにはなりません。まず、読者が内容を読めて目的の操作を完了できることを優先し、月次点検の記録へ結果を残しましょう。

運営者の実務メモ

遅いサイトの原因で一番多かったのは画像

表示が遅いサイトで一番多かった原因は画像です。スマホで撮った写真を、サイズを変えずにそのまま載せているケースがよくありました。次に多いのが、WordPressのプラグインの入れすぎと、使っていないプラグインの放置です。

運営者の実務経験にもとづくメモです。すべてのサイトに当てはまるとは限りません。

公開日: 2026-04-25

最終更新日: 2026-10-14

追記履歴

  • 2026-04-25 初版公開
  • 2026-09-10 計測の手順、実測とラボの違い、症状別の確認表、変更後の検証方法を追加。原因を計測前に断定する説明を修正
  • 2026-10-14 運営者の実務経験にもとづくメモを追加