WordPress 高速化：47項目のチェックリスト

根拠にもとづく順番でチェックリストを使う

この47項目のチェックリストは、WordPress サイトのための実務的な監査表です。特定の読み込み時間やスコアを約束するものではありません。ホスティング、コンテンツ、訪問者の端末、ビジネス要件はサイトごとに違います。問題のあるユーザー体験から出発し、関係する項目を選び、一度に一種類の変更だけを検証しましょう。

高度なサーバーチューニングより先に、計測で確認したボトルネックに取り組みます。小さなリクエストを減らせてもチェックアウトが壊れるなら、ラボのスコアが上がったとしてもそれは後退です。

基準値を決める

1. トップ、記事、アーカイブ、商品、チェックアウトの代表的な URL を選び、ログイン中と匿名のセッションを含めます。
2. 後の計測と比較できるよう、ホスティングのリージョン、端末、回線条件、ブラウザ、リリースのバージョンを記録します。
3. 再現可能なラボテストを複数回実行し、最速の結果だけでなく結果の幅を残します。
4. フィールドデータがあれば実ユーザーの LCP、INP、CLS を確認し、URL 単位のデータとオリジン単位のデータを区別します。
5. ドキュメントのリクエストを調べ、DNS、接続、サーバー応答の遅延を切り分けます。
6. 初回読み込み時だけでなく、遅い操作を再現しながらメインスレッドのトレースを記録します。
7. 実際の LCP 要素と、それを表示するのに必要なリクエストの連鎖を特定します。
8. 復元できるバックアップを作成し、変更後も動かなければならない主要なユーザーフローを決めておきます。

オリジンの処理を減らす

9. サポート対象で、サイトと互換性のある PHP バージョンを使います。本番の前にステージングでアップグレードを検証します。
10. OPcache の状態と容量を確認します。デプロイで明示的にキャッシュを無効化しない限り、タイムスタンプの検証を無効にしないでください。
11. サーバー設定を変える前に、遅い PHP の処理経路と繰り返されるデータベースクエリをプロファイルします。
12. ページ描画中のリモート API リクエストを見直し、適切なキャッシュと上限のあるタイムアウトを使います。
13. ホスティング会社と永続オブジェクトキャッシュについて確認し、コンテンツ変更時の無効化を検証します。
14. 公開 HTML は安全な場合に限りキャッシュし、認証済み、カート、チェックアウト、パーソナライズされたレスポンスは対象外にします。
15. 異なる2人のユーザーが互いのキャッシュデータを受け取れないことを確認します。
16. 同時実行数を増やす前に、代表的な負荷のもとで CPU、メモリ、ワーカーの飽和状況を調べます。
17. スケジュールタスクの実行を検証します。WP-Cron をシステムのスケジューラーに移す場合は、実行漏れや失敗したジョブを監視します。
18. インデックスを追加する前にクエリプランを確認し、書き込みへの負荷を評価して、代表的なデータのコピーでテストします。
19. サイズの大きい自動読み込みオプションは、それを所有するプラグインとあわせて見直します。対象を絞った整理の前にバックアップを取ります。
20. 大きなクエリはページ分割し、上限のないコレクションをメモリに読み込まないようにします。

描画と操作性を改善する

21. 未使用のスクリプトやスタイルを削除するのは、メニュー、フォーム、チェックアウト、エディターの要件を確認してからにします。
22. 互換性のあるスクリプトは依存関係の順序を保ったまま遅延させます。async は順序どおりの実行の代わりにはなりません。
23. 描画をブロックするスタイルを調べます。クリティカル CSS を使う場合は、すべてのテンプレートと画面サイズでテストします。
24. LCP 画像は JavaScript で後から挿入せず、初期 HTML で見つけられるようにします。
25. LCP 画像は遅延読み込みにしないでください。高い取得優先度は選択的に使い、その後ウォーターフォールを確認します。
26. 重い JavaScript は計測した単位に分割し、必要に応じて合間にブラウザへ処理を譲ります。
27. レイアウトの読み取りと書き込みをまとめ、強制的な再レイアウトの繰り返しを避けます。
28. 不要なサードパーティのウィジェットを削除し、任意のものは挙動と同意ルールが許す場合に限り遅延させます。
29. 画像、埋め込み、広告の領域を、リソースが届く前に確保します。
30. 代替フォントのメトリクスとレイアウトのずれを確認し、font-display を意図して使います。
31. キーボード操作やモーション軽減の設定でも、操作要素を使えるようにします。
32. 長いページや性能の低い端末でもテストします。トップページが速くても、すべてのテンプレートが速いとは限りません。

適切なサイズのリソースを配信する

33. 画像の幅は、表示される領域と想定されるピクセル密度に合わせて選びます。
34. 決まった削減率を当てにせず、実際のファイルで AVIF、WebP、既存の形式を比較します。
35. レスポンシブな srcset の候補と、レイアウトを反映した sizes の値を用意します。
36. 画面外の画像は遅延読み込みにし、適切な場合は非同期デコードを使います。
37. 重要なラベルや説明は HTML で残します。画像内の小さな文字は読みにくいためです。
38. フォントはセルフホストするなどしてリクエストを最小限にし、サイトに必要なウェイトと文字セットだけを読み込みます。
39. リクエストのウォーターフォールを確認したうえで、本当に重要なリソースだけをプリロードします。
40. テキスト系リソースが gzip や Brotli で配信されているか確認し、圧縮済みの画像を再圧縮しないようにします。
41. バージョン付きの静的リソースには長期キャッシュを使い、内容が変わったら URL を変更します。
42. 動画は意図して読み込みます。CSS で非表示にするだけでは、ダウンロードが止まる保証はありません。

リリースを検証する

43. 最適化を有効にしたら、ログイン、検索、お問い合わせフォーム、カート、チェックアウトをテストします。
44. 編集したページで、キャッシュヘッダーとコンテンツの無効化を確認します。
45. 同じ条件で基準のラボテストを繰り返し、改善と後退の両方を記録します。
46. フィールドの指標は時間をかけて追います。リリースは移動する集計期間にすぐには反映されません。
47. パフォーマンス予算を設定し、変更履歴を残して、後の劣化をリリースと結びつけられるようにします。

出典と参考資料

• WordPress：最適化
• Google：LCP の最適化
• Google：INP の最適化

あわせて読みたい

TTFB と Core Web Vitals の診断やレスポンシブ画像の配信について詳しく読む。