ステップ1：最適化する前に測定する
サイトをPageSpeed Insights（pagespeed.web.dev）にかけ、4つの数値を記録しましょう。LCP（Largest Contentful Paint、主要なコンテンツが表示されるまでの時間）、INP（Interaction to Next Paint、応答性）、CLS（Cumulative Layout Shift、視覚的な安定性）、ページの総重量です。GoogleのCore Web Vitalsのしきい値：LCPは2.5秒未満、INPは200ミリ秒未満、CLSは0.1未満。これらは2021年以降、順位に直接影響します。これらのしきい値を下回れば「良好」、しきい値と4秒／500ミリ秒／0.25の間は「改善が必要」、それより悪ければ「不良」です。WordPressの速度を最適化する目的はすべて、これら3つの数値をグリーンゾーンに移すことです。GTmetrixのスコアやその他の集計評価を信じないでください。それらはGoogleの実際のシグナルと対応していません。
ステップ2：ホスティングがボトルネックでないか確認する
WebPageTestで、読者の地理からのTTFB（Time To First Byte）を確認しましょう。TTFBが1秒を超える場合、ホスティングがボトルネックです。フロントエンドの最適化では直りません。よくある原因：サーバーが過負荷の安い共有ホスティング、読者とは別の大陸にあるホスティング、PHPのopcacheの欠如（PHP 7以降のどのバージョンでもデフォルトで有効になっているはずです）。最も安い解決策は、同じプランレベルでより速いホスティングに乗り換えることです。月50,000ビュー未満なら、LiteSpeed CacheのあるHostinger Businessが400ミリ秒未満のTTFBを実現します。それ以上のトラフィックなら、Google Cloudのプレミアム層のKinstaまたはWP Engineが、一貫して300ミリ秒未満のTTFBを実現します。ホスティングの乗り換えはプラグインのインストールより手間がかかりますが、改善はたいてい劇的です。
ステップ3：ページキャッシュは最大の単一の最適化
デフォルトでは、WordPressはリクエストごとにPHP＋MySQLから各ページを生成します。ページキャッシュは生成されたHTMLを保存し、後続の訪問者に直接配信します。通常10〜20倍速くなります。LiteSpeedベースのホスティング（Hostinger、ほとんどのBluehost、A2 Turbo、NameHero）では、LiteSpeed Cache（無料）をインストールしてください。サーバーレベルのキャッシュと統合されます。Apache／Nginxのホスティングでは、WP Rocket（年59ドル）をインストールしてください。最高品質のキャッシュプラグインで、その価格に見合います。無料の代替（W3 Total Cache、WP Super Cache）も機能しますが、より多くの設定が必要です。ページキャッシュを有効にしたら、PageSpeed Insightsで再テストしてください。TTFBが劇的に下がるはずです。
ステップ4：画像の最適化は2番目
画像はしばしばWordPressページの重量の60〜80%を占めます。捕らえるべき2つの勝利：（1）圧縮：各画像はアップロード前に圧縮すべきです。当サイトの画像圧縮ツールを使うか、ShortPixel／Smushをインストールしてアップロード時に自動圧縮してください。目標：ヒーロー画像は200KB未満、コンテンツ画像は100KB未満。（2）最新のフォーマット：JPG／PNGの代わりにWebP（またはAVIF）を配信してください。WebPは同じ品質で25〜35%小さくなります。ShortPixelとSmush Proは自動的に変換します。あるいは、Cloudflareの画像最適化が画像をその場で書き換えます。（3）遅延読み込み：折り返し以下の画像は、スクロールして到達したときにのみ読み込むべきです。WordPress 5.5以降はloading='lazy'を自動的に追加します。ソースを表示して機能していることを確認してください。（4）幅の属性：CLSを避けるため、画像には常に明示的なwidth/heightを設定してください。
ステップ5：CSS/JSの圧縮とバンドル監査
ほとんどのキャッシュプラグイン（WP Rocket、LiteSpeed Cache）はCSS/JSの圧縮を含んでいます。有効にしてください。最大の勝利は、使われていないスクリプトを遅延させるか削除することです。トップページでChrome DevTools→Coverageタブを実行してください。CSSとJSのどのバイトが実際に使われているかを示します。典型的な結果：CSSの50〜80%が未使用、JSの30〜60%が未使用。解決策：（a）より軽いテーマを使う（GeneratePressやKadenceは30KB未満のCSSを配信します）、（b）使っていないプラグインを無効にする（しばしば未使用スクリプトの原因）、（c）Asset CleanUpのようなプラグインを使い、必要としないページでスクリプトを無効にする（例：Contact Form 7は、/contactでしか使っていなくてもデフォルトであらゆる場所に読み込まれます）。
ステップ6：プラグイン監査：遅いものを見つける
すべてのアクティブなWordPressプラグインは各ページ読み込みで実行され、クエリ、JavaScript、CSSを追加する可能性があります。ほとんどの遅いサイトは30〜50以上のアクティブなプラグインを抱えており、その半分はもう使っていません。Query Monitor（無料）を使って、どのプラグインが最も多くのデータベースクエリを行うかを確認してください。New Relicの無料層またはKinstaのAPMを使って、どのプラグイン関数が最も時間がかかるかを確認してください。歴史的な主要な原因：Jetpack（多くのことを行い、そのすべてを各リクエストで行います）、トラフィックのピーク時に実行される肥大化したバックアップ系プラグイン、共有ボタンのないページでもCSS/JSを読み込むソーシャル共有プラグイン、リアルタイムでファイルスキャンを行うセキュリティプラグイン。1つのプラグインを無効にし、パフォーマンスを再テストし、その機能がコストに見合ったかを判断してください。
ステップ7：データベースの最適化
WordPressは時間とともにデータベースにゴミを蓄積します。投稿のリビジョン、期限切れのトランジェント、スパムコメント、孤立したメタデータです。WP-Optimize（無料）をインストールし、一度データベースのクリーンアップを実行してください。妥当な月次メンテナンス：60日より古いリビジョンを削除（安全のため最近のものは残す）、期限切れのトランジェント、スパムキュー。高トラフィックのサイトでは、データベースの最大の勝利はオブジェクトキャッシュです。RedisまたはMemcachedが、コストのかかるMySQLクエリの結果をメモリに保存し、繰り返しの作業を避けます。ほとんどのマネージドWordPressホスティングは上位層でRedisを含みます。基本的な共有ホスティングでは、これは利用できません。
ステップ8：グローバルな読者向けのCDN
CDN（コンテンツ配信ネットワーク）は、静的アセット（画像、CSS、JS）を訪問者の近くのエッジ拠点にキャッシュします。米国にホストされた米国だけの読者には、CDNはわずかな改善をもたらします。グローバルな読者には、CDNは不可欠です。アセットのレイテンシを200〜500ミリ秒から20〜50ミリ秒に削減します。Cloudflareの無料層はほとんどのニーズをカバーします。1GBあたり0.01〜0.05ドルのBunnyCDNは、優れたパフォーマンスを備えた有料のアップグレードです。特に画像については、Cloudflare ImagesまたはBunny Image Optimizerが、その場でリサイズしフォーマットを変換できます。
ステップ9：もう一度測定して反復する
大きな変更のたびに、PageSpeed Insightsを再実行してください。目標は段階的な進歩です。ほとんどのサイトは1回の変更で「不良」から「良好」には移りません。完全な最適化のパスの後の典型的な結果：共有ホスティング上のWooCommerceストアがLCP 4〜6秒からLCP 1.5〜2.5秒に。マネージドホスティング上のコンテンツブログがLCP 2〜3秒からLCP 0.8〜1.5秒に。上記すべての後でLCPが3秒を超えたままなら、ボトルネックはおそらくテーマです。さらに最適化する前に、より軽いテーマ（GeneratePress、Kadence、Astra）に切り替えてください。