WordPress サイトを速くする方法：実践ガイド

WordPress サイトが遅い原因が、一つの設定だけにあることはまれです。サーバーがページの生成に時間をかけすぎていることもあれば、大きすぎる画像がメインコンテンツの表示を遅らせていることも、すべて読み込まれたように見えた後でスクリプト群がメニューの反応を鈍らせていることもあります。問題ごとに必要な対策は異なります。

このガイドは、開発者と一緒に進める明確な手順を知りたい経営者やサイト担当者向けです。目標は、実際の訪問で速いと感じられるサイト、つまり顧客が余計な待ち時間なく読み、閲覧し、問い合わせ、購入できるサイトです。例は説明のためのものであり、架空のクライアント案件の成果ではありません。

「速い WordPress サイト」とは実際にどういうことか？

3つの瞬間を考えてみてください。ページが応答し始める瞬間、役立つコンテンツが見える瞬間、そして操作要素が訪問者に反応する瞬間です。「読み込み完了」はこの3つを表していません。すでに使える状態なのにバックグラウンドでアクセス解析を取得し続けているページもあれば、読み込みが終わってもフィルターを開くと固まるページもあります。

Google の Core Web Vitals で「良好」とされる基準は、75パーセンタイルで評価して LCP が2.5秒以下、INP が200ミリ秒以下、CLS が0.1以下です。これは体験の目標であり、検索順位の約束ではありません。違いについては Google の Core Web Vitals に関するガイダンスをご覧ください。

1. 何かをインストールする前に基準値を決める

代表的な URL を少数選びます。トップページ、サービスページ、長い記事、主要なコンバージョンの流れなどです。ネットショップなら、カテゴリー、商品、カート、チェックアウトも含めましょう。キャッシュの挙動やページの内容が異なることがあるため、匿名の訪問者とログイン中のユーザーは分けてテストします。

PageSpeed Insights で、利用できるフィールドデータと、シミュレーションによる Lighthouse のテスト結果を区別します。フィールドデータは対象となった実際の訪問を表し、ラボテストは管理された条件で問題を再現するのに役立ちます。フィールドデータが不足しているページは、監査にその旨を記録します。オリジン単位の概要は、すべての URL が同じように動く証明にはなりません。

日付、URL、端末のプロファイル、接続設定、キャッシュの状態、テスト結果を保存します。最速の結果を選ぶのではなく、比較可能な計測を繰り返しましょう。顧客から不満の出ている操作を短く録画しておくと、スコアだけでは見えない問題がわかることがあります。

変更の前に、復元できるバックアップとステージング環境のコピーを作ります。引き続き動作しなければならない機能を書き出しておきましょう。ページが速くなってもお問い合わせフォームが壊れていては、ビジネス上の要件を満たせません。

2. 応答の経路を直す：ホスティング、キャッシュ、オリジンの処理

ブラウザのネットワークパネルで、ドキュメントのリクエストから確認します。応答が遅い場合、その待ち時間が毎回の訪問で起きるのか、主にキャッシュミスのときに起きるのかを見極めます。次に、サーバーのリソース、PHP の実行、データベースの動き、ページの生成中に呼び出される外部サービスを調べます。

ホスティングは、約束された転送量だけでなく、アプリケーションの要件とサポートの質で選びましょう。確認したいのは次のような点です。ステージングと検証済みのバックアップは提供されるか。どの PHP バージョンに対応しているか。遅いリクエストやリソースの飽和を確認できるか。キャッシュのルールでチェックアウトが壊れたとき、誰が助けてくれるか。計測によって現在のプラットフォームが制約になっているとわかった場合に、プラットフォームの変更は正当化されます。

設定する前に3種類のキャッシュを理解する

• ブラウザキャッシュは、再訪問者が変更のない静的ファイルを再利用できるようにします。更新が確実に届くよう、CSS、スクリプト、画像にはバージョンを付けます。
• ページキャッシュは生成済みのレスポンスを保存し、公開ページをリクエストのたびに作り直さずに済むようにします。サーバー、対応するプラグイン、CDN のいずれかに置けます。
• オブジェクトキャッシュは、アプリケーションのデータやクエリ結果を再利用します。永続オブジェクトキャッシュは適した処理ではリクエストをまたいで役立ちますが、HTML ページ全体のキャッシュの代わりにはなりません。

これらの層を整理しましょう。キャッシュごとに担当を決め、編集者がコンテンツを変更したり公開を取り消したりした後の無効化をテストします。同じリソースを書き換えたり、同じレスポンスをキャッシュしたりするプラグインを複数入れると、障害の原因がわかりにくくなります。

企業サイトに「すべてをキャッシュする」という一律のルールを適用してはいけません。アカウントページ、パーソナライズされたレスポンス、カート、チェックアウト、決済のコールバックには、意図した扱いが必要です。Cookie、メソッド、クエリパラメーター、除外ルールを開発者やホスティング会社と確認しましょう。独立した2つのセッションでテストし、ある顧客が別の顧客の情報を受け取れないことを確かめます。

キャッシュのない経路も改善する

キャッシュは期限が切れ、削除され、ヒットしないこともあります。すべての遅延をウォームキャッシュの陰に隠すのではなく、遅いクエリや重いプラグインのフックをプロファイルしましょう。可能なら外部 API の処理をページの描画から切り離し、上限のあるタイムアウトを設け、ビジネス上許容できる場合に限ってキャッシュしたフォールバックデータを保持します。サポート対象の PHP を使い、アップグレード前に互換性を確認します。

根拠のないデータベースのインデックスやサーバーのメモリ設定を本番にそのまま持ち込まないでください。実際の負荷を調べ、変更をテストし、ロールバックできるようにしておきます。WordPress の最適化ハンドブックは、最初の参考資料として役立ちます。

3. メインコンテンツを早く表示する

トレースで実際の LCP 要素を特定します。あるページでは写真、別のページでは見出しかもしれません。正しい対策は、画像のサイズ、遅れて発生するリソースのリクエスト、スタイルシート、フォントのどれかによって変わるため、これは重要です。

目立つ写真には、使い道のある幅をいくつか用意し、WebP や AVIF を元の形式と比較します。表示サイズで品質を確認しましょう。商品の細部、文字、顔、グラデーションでは、それぞれ違う圧縮設定が必要になることがあります。今後のトリミングやサイズ変更がすでに劣化したコピーから始まらないよう、元画像はメディアの管理フローに残しておきます。

srcset と正確な sizes 属性を使い、ブラウザに適切な画像を選ばせます。WordPress のメディアライブラリの画像関数は、各サイズの画像とメタデータがあればレスポンシブなマークアップを生成できます。独自テンプレートではその利点が失われることがあるので、出力された HTML を確認しましょう。

<!-- Example for an image displayed up to 720px wide. -->
<img src="/media/service-960.webp"
  srcset="/media/service-480.webp 480w,
          /media/service-960.webp 960w,
          /media/service-1440.webp 1440w"
  sizes="(max-width: 760px) calc(100vw - 40px), 720px"
  width="1440" height="900"
  loading="eager" fetchpriority="high"
  decoding="async"
  alt="Technician inspecting a commercial ventilation unit">

width と height はアスペクト比を確保するもので、CSS で画像を可変幅にすることもできます。この例は LCP になりそうな画像向けであり、ページ内のすべての画像に当てはまるものではありません。最初の表示領域より下にある補助的な画像は遅延読み込みにし、すべての画像に高い優先度を与えるのは避けます。重要な画像の URL は、初期 HTML で見つけられるようにしましょう。

文字の多い画像には特に注意が必要です。スプレッドシートの小さなスクリーンショットは、軽くても読めないことがあります。重要な情報には HTML の表を、適した図には SVG を使いましょう。配信と品質確認の詳細はレスポンシブ画像のガイドで説明しています。

4. サイトを壊さずにテーマとプラグインの処理を減らす

シンプルに見えるページでも、複数のスライダー、アイコンフォント、アニメーションライブラリ、ウィジェットのスタイルを読み込んでいることがあります。テンプレートごとに、実際に何がリクエストされ実行されているかを監査しましょう。読み込まれるものをすべて圧縮しようとする前に、重複した機能を取り除きます。

プラグインの数だけでは、よい診断になりません。重い連携が一つあるだけで、範囲の明確な小さいプラグインいくつか分より負荷が大きいこともあります。各プラグインが何をしていて、どこで必要で、誰が保守しているかを記録します。無効化はステージングでテストし、トップページに見えるウィジェットがないからといって使われていないと決めつけないでください。

リソースは必要な場所でだけ読み込みます。お問い合わせフォームのスクリプトはお問い合わせページだけ、商品ギャラリーのライブラリは商品ページだけで十分なこともあります。スクリプトを遅延させるときは依存関係の順序を守りましょう。認証、決済、同意管理、主要なナビゲーションのコードを、よく確認せずに遅らせてはいけません。

5. 読み込みだけでなく操作への反応も速くする

遅い操作を再現します。モバイルメニューを開く、フィルターを展開する、バリエーションを選ぶ、フォームを送信する、といった操作です。メインスレッドのトレースを見れば、遅延の原因が JavaScript の実行なのか、繰り返されるレイアウト計算なのか、大きな描画の更新なのかがわかります。

まず処理の量を減らします。変わった部分だけを再描画し、不要なイベントリスナーを取り除き、スタイルを変えた直後にレイアウトの寸法を何度も読み取らないようにします。それでも計算が大きいなら、上限のある単位に分割し、その合間にブラウザが応答できるようにします。ワーカーは適した計算には役立ちますが、通常の DOM の更新を直接行うことはできません。

サードパーティのチャット、トラッキング、地図、動画の埋め込みも同じように見直しましょう。適切な場合は任意の機能を必要になったときに読み込み、機能と同意の要件は守ります。すぐに読み込まれる地図の埋め込みを、わかりやすい「地図を読み込む」ボタンに置き換えるほうが、小さな装飾アイコンを圧縮するより効果的なこともあります。

技術的な枠組みは Google の INP 最適化ガイドにまとまっています。実務上の受け入れテストはシンプルで、開発者のパソコンだけでなく、低価格帯のスマートフォンでも操作が軽快に感じられることです。

6. レイアウトのずれと不要な転送をなくす

画像、広告、埋め込みの領域を確保します。読者が操作を始めた後に、コンテンツの上へバナーを差し込むのは避けましょう。遅れて読み込まれるフォントが改行位置を変え、操作要素を動かしていないか確認します。代替フォントと意図的なフォントの読み込み方針によって、文字を読みやすく保ちつつ動きを抑えられます。

フォントファミリー、ウェイト、文字セットは、サイトが本当に必要とするものだけにします。リソースのプリロードは、ウォーターフォールで早期の発見が役立つとわかってから行いましょう。むやみなプリロードは、優先したかったリソースと競合します。

背景動画を CSS で隠しても、ダウンロードを確実に防げるわけではありません。動くコンテンツが必須でない場合は、軽いポスター画像と明示的な再生操作を選びましょう。完成したデザインは、モーション軽減の設定を有効にした状態と、キーボード操作でテストします。

7. リリース前にチェックアウト、公開作業、フォームを確認する

合否で判定する短いリリース用チェックリストを用意します。メニューの操作、サイト内検索、フォームの入力チェック、送信の成功、メールをテストします。WooCommerce では、適切なテスト環境で、バリエーション、クーポン、税金、カートの更新、チェックアウト、決済の確認をテストします。同意に依存する連携は、同意した状態と拒否した状態の両方で確認しましょう。

次に、記事を編集して画像を差し替えます。キャッシュが無効化され、初めての訪問者も再訪問者も正しいバージョンを見られることを確認します。ログイン中のセッションも別にテストします。キャッシュの挙動は製品の一部であり、正しいと仮定してよい設定ではありません。

理解しやすいまとまりで変更をデプロイし、基準のテストを繰り返して結果を記録します。速度だけでなくエラーも監視しましょう。公開されているフィールドの計測値に変更が反映されるには時間がかかるため、一度の再読み込みがうまくいっただけで、サイト全体が改善したと宣言しないでください。

最初の1週間の現実的なプラン

1. 1日目：計測する。重要な URL を選び、ラボの結果を取得し、顧客の不満を再現します。バックアップとステージングを確認します。
2. 2日目：オリジンを調べる。キャッシュされない遅いリクエストをプロファイルし、安全なキャッシュの範囲をホスティング会社と決めます。
3. 3日目：メインコンテンツを直す。アクセスの多いテンプレートで、画像のサイズと発見のされ方を直し、避けられる描画の遅れを取り除きます。
4. 4日目：操作をテストする。役立つ操作を妨げている重いスクリプトやサードパーティの機能に対処します。
5. 5日目：確認してリリースする。機能テストを行い、ロールバックできる状態でデプロイし、新しい基準値を記録します。

これは推奨する順序であり、5日間での完了を保証するものではありません。複雑なネットショップや大きくカスタマイズされたアプリケーションでは、何度か繰り返す必要があるかもしれません。計測された効果、実装の手間、顧客の行動の流れへのリスクで作業の優先順位を決めましょう。

出典と参考資料

• WordPress：パフォーマンスの最適化
• Google：Largest Contentful Paint の最適化
• Google：Interaction to Next Paint の最適化
• Google：Core Web Vitals と Google 検索
• WordPress 高速化チェックリスト47項目

どこから始めればよいか迷ったら、WordPress のパフォーマンス監査と最適化をご覧ください。遅い URL と、特に重要な顧客の操作をお知らせいただければ、スコアだけよりも良い出発点になります。