HP の表示が遅い原因の切り分け——画像・サーバー・プラグインの順に見る

結論から書くと、ホームページの表示が遅いときは、まず測って遅い部分を確かめ、画像 → サーバー → プラグイン（外部から読み込むものを含む）の順に見ます。画像はページの中でデータ量が大きくなりやすく、確かめやすい部分です。画像で説明がつかなければサーバーの応答の速さを見て、最後に WordPress のプラグインやテーマ、外部のサービスの読み込みを一つずつ切り分けます。

この記事では、PHP のバージョンを切り替えて表示されなくなった場合と、ホームページの月額保守の全体は扱いません。前者は「レンタルサーバーで PHP のバージョンを切り替えたら動かなくなったときの切り分け」、後者は「ホームページの月額保守は何をしているのか——更新・バックアップ・SSL・監視と契約の確かめ方」で説明しています。

まず測る——PageSpeed Insights と開発者ツール

原因を探す前に、数字で測ります。直した後に比べるため、最初の結果を残しておきます。

PageSpeed Insights

Google の PageSpeed Insights に URL を入れると、2種類のデータが出ます。

• 実際のユーザーのデータ: Chrome の利用者から集めた過去28日間のデータです。アクセスが少ないページでは、サイト全体のデータになるか、表示されません。
• ラボのデータ: Lighthouse で読み込みを再現した結果です。原因を調べるのに役立ちますが、実行するたびに点数が変わることがあります。

実際のユーザーのデータでは、Core Web Vitals の3つの指標を見ます。web.dev によると、モバイルとパソコンに分けた読み込みの 75 パーセンタイル（4分の3の読み込みがこの値以下になる値）で、次の値が目安です。

表示の遅さに直接関わるのは LCP です。Search Console を使っていれば、Core Web Vitals レポートで、遅いページを似たページのグループごとに確かめられます。

ブラウザの開発者ツール

Chrome の開発者ツールのネットワーク パネルでは、読み込んだファイルごとに転送量（Size）とかかった時間（Time）が分かります。

1. 再読み込みのボタンを長押しして「キャッシュの消去とハード再読み込み」を選び、初めて来た人と同じ条件にする
2. 「スロットリング」で回線を遅くして、スマートフォンでの読み込みに近づける
3. Size の大きい順に並べ、大きな画像や、ほかのドメインから読み込んでいるファイルを探す
4. いちばん上の行（ページの HTML）の Time が長ければ、サーバーの応答を疑う

画像——大きさ・形式・遅延読み込み

web.dev の画像の形式の解説は、画像は HTML や CSS、JavaScript などと比べて、通常は多くのバイト数を必要とするとしています。まず画像から確かめます。

大きさ。 web.dev のレスポンシブ画像の解説は、パソコン用の大きさの画像をモバイル端末に配信すると、必要なデータの2〜4倍を使う可能性があるとしています。WordPress については、Lighthouse の画像の大きさの監査の説明が、メディア ライブラリから挿入して適切な大きさの画像が使われるようにし、表示の場所が十分にある場合を除いて「Full Size」の画像は使わないよう勧めています。

形式。 Lighthouse の画像の形式の監査の説明は、AVIF と WebP は JPEG や PNG より圧縮率と画質に優れているとし、古い iPhone では表示できないことにも触れています。形式を変えたら、スマートフォンでも表示を確かめます。

遅延読み込み。 web.dev の遅延読み込みの解説は、画像に loading="lazy" を付けると画面外の画像の読み込みを遅らせられる一方、開いたときに画面内に見える可能性が高い画像、特に LCP の画像は遅延読み込みしないよう注意しています。最初に見えるメインの画像まで遅延読み込みにすると、かえって遅くなります。画像に width と height を指定すると、レイアウトのずれも防げます。

画像を軽くしても LCP が変わらないことがあります。web.dev の LCP の最適化の解説は、LCP をサーバーの最初の応答（TTFB）、画像の読み込み開始までの遅れ、読み込みの時間、表示までの遅れの4つに分け、画像を圧縮しても短くなった時間が別の部分に移るだけの場合があるとしています。画像を直しても変わらなければ、次にサーバーを見ます。

サーバー——応答時間・PHP のバージョン・プラン・混雑

TTFB は、ページを開き始めてから、サーバーの応答の最初の1バイトが届くまでの時間です。web.dev は、大まかな目安として、ほとんどのサイトで 0.8 秒以下を目指すとし、1.8 秒を超えると不良としています。TTFB には、リダイレクト、DNS の参照、接続、サーバーの処理の時間が含まれます。

プランと混雑

web.dev の TTFB の最適化の解説は、ほかの最適化の前にまずホスティングを検討するよう書き、共有ホスティングは一般的に速度が遅くなるとしています。WordPress の最適化のドキュメントも、サーバーのアクセス量や、ログインの総当たり攻撃などの不正なアクセスが負荷を上げるとし、共用サーバーでプランのリソースの上限に達しているなら上限の高いプランに変えると役立つ場合があるとしています。プランを変える前に、時間帯を変えて測り、管理画面で使用状況を見られれば確かめます。

PHP のバージョンとキャッシュ

同じドキュメントは、新しい PHP には通常、性能の改善も含まれるとし、WordPress の動作環境は PHP 8.3 以上を推奨しています。ただし、切り替えるとテーマやプラグインが動かなくなることがあるので、冒頭の記事のとおり検証してから切り替えます。

WordPress のドキュメントは、すぐに効果を出したいならキャッシュから始めるよう書いています。ページを静的なファイルとして保存して配信し、サーバーの処理を減らす仕組みで、レンタルサーバーの機能として用意されていることもあります。一方で web.dev は、キャッシュはサーバー側の遅さを隠すため、キャッシュされたページだけを測ると TTFB の問題に気づかないことがあると注意しています。

リダイレクトについては、同じ web.dev の解説が、https を付けていないリンクや末尾のスラッシュの違いで起きる転送を、自分で直せるものとして挙げています。サイト内のリンクは、転送されない最終の URL で書きます。

プラグインと外部の読み込み——数ではなく重いものを探す

プラグインとテーマ

WordPress の最適化のドキュメントは、プラグインの数と性能の両方がサイトの性能に大きく影響するとし、最初に見る場所としてプラグインを挙げています。テーマも大きく影響するとしています。数を減らすだけでは原因に当たらないことがあるので、どれが重いかを特定します。

1. バックアップを取り、できれば本番のコピー（検証用の環境）で試す
2. プラグインを一つずつ停止し、そのたびに同じ条件で測る（ドキュメントも、選んで停止しながら性能を測るよう勧めています）
3. 停止して大きく変わったプラグインは、そのドキュメントやサポート フォーラムを確かめるか、同じ機能の別のプラグインを探す
4. 使っていないプラグインは、停止だけでなく削除する

停止すると問い合わせフォームなどの機能も止まります。本番で試すなら、影響の小さい時間に、元に戻す手順を決めてから行います。

外部から読み込むもの

SNS のボタン、動画の埋め込み、チャット、広告、アクセス解析などは、ほかの会社のサーバーからプログラムを読み込みます。web.dev のサードパーティの JavaScript の解説は、こうしたスクリプトは特にパフォーマンスに問題を生じさせる可能性があるとし、同じ機能を2つのサービスで入れない（アクセス解析を2つ入れない）こと、不要なものを定期的に見直して削除することを勧めています。読み込み方によっては、外部のサーバーの不調でページの表示まで止まることもあるとしています。ネットワーク パネルで自社以外のドメインから読み込んでいるものを洗い出し、今も使っているかを確かめます。

どの手順でも、一度に変えるのは一つにして、変えるたびに同じ条件で測り直します。同時に変えると、どれが効いたのか分からなくなります。

h-system でできること

h-system のサイト運用代行ライトプランでは、他社が制作したホームページも含めて、デザインを作り替えずに運用をお引き受けしています。稼働の監視やサーバー・基盤まわりの更新対応、不具合時の一次対応といったサーバー管理、タイトル・見出し・構造の整理などデザインを変えない SEO の内部改善、テキスト・画像の差し替えなど軽微な更新の月数回までの代行が内容です。表示の遅さに関わる作業のうち、どれがプランの対象になるかはご契約の際に確認し、範囲を超える作業は内容を伺ったうえで別途ご相談となります。特定の検索順位やアクセス数はお約束しておらず、料金は月額制の個別見積りです。