公開: 2026年9月21日
WordPressサイトが遅いと感じて、キャッシュ系のプラグインを入れてみても、思ったほどPageSpeed Insightsの数値が変わらないことがあります。
今回は同じWordPressテストページで、NitroPackとWP-Optimizeをそれぞれ試し、PageSpeed Insightsのモバイル測定でどこまで変化したかを確認しました。
最初に結論を言うと、今回のページではNitroPackが最も大きく改善しました。ただし、キャッシュプラグインを入れれば必ずLCPが解決するわけではありません。
今回の結果
- NitroPack Freeでは、Performanceが74から90〜92まで改善
- WP-Optimizeはサーバー応答の改善は見られたものの、Performanceは73〜74で大きく変わらず
- ファーストビュー画像のpreloadだけでは、Performanceは74〜75程度の変化
- キャッシュだけでなく、LCP要素の読み込みと描画遅延まで確認する必要がある
検証条件
この比較は、筆者が用意したWordPressテスト環境で実施したものです。
テーマ・画像・サーバー・導入済みプラグインによって結果は変わるため、同じ数値を保証するものではありません。同じページに対して施策ごとの差を確認しています。
- 測定環境：Google PageSpeed Insights
- 測定対象：モバイル
- 測定回数：各条件で3回
- 確認した指標：Performance、FCP、LCP、TBT、CLS
- WP-Optimizeでは画像最適化とデータベースのクリーンアップは実行していません
比較した条件は次の4つです。
- 最適化なし
- NitroPack Free（Strongモード、Cache Warmup有効）
- WP-Optimize（ページキャッシュ有効）
- ヒーロー画像の手動preload
測定結果
| 条件 | Performance | 主な確認結果 | 注意点 |
|---|---|---|---|
| 最適化なし | 74 | FCP 1.2〜1.3秒 / LCP 7.4〜9.3秒 | LCPが遅い |
| NitroPack Free | 90〜92 | FCP 1.0秒 / LCP 2.9秒 | CLS 0.133 |
| WP-Optimize | 73〜74 | サーバー応答は改善 | LCP描画遅延は残る |
| 画像preload | 74〜75 | 重要画像の先読みはできた | 改善は限定的 |
NitroPackではLCPが大きく改善した
NitroPackをFreeプラン・Strongモードで有効化したところ、Performanceは74から90〜92まで上がりました。
最も大きく変わったのはLCPです。最適化なしでは7.4〜9.3秒だった値が、測定時には2.9秒まで短縮されています。
今回のページでは、最初のテキストが表示されるまでのFCPよりも、ファーストビューの大きな画像が表示されるまでの時間が課題でした。NitroPackはキャッシュだけでなく、画像や配信、CSS・JavaScriptの最適化をまとめて扱うため、このページでは大きな差になったと考えられます。
ただし、無料版ではNitroPackのバッジが表示され、CLSは0から0.133へ変化しました。
実機で確認した範囲では大きな違和感はありませんでしたが、設定後はスコアだけでなく実際の画面も確認しておくべきです。
WP-Optimizeでは応答は改善してもLCPは残った
WP-Optimizeでは、ページキャッシュを有効にして測定しました。
LCPの内訳では、サーバーがHTMLを返すまでの時間は改善していました。ただ、ヒーロー画像を画面へ描画するまでの遅れが残り、Performanceは73〜74で最適化前とほぼ変わりませんでした。
画像ファイルの取得が極端に重いわけではなく、CSSやJavaScript、アニメーションなどによるレンダリング遅延が主な要因になっている場合、キャッシュだけでは解決しにくいことがあります。
WP-Optimizeが意味のないプラグインということではありません。サーバー応答が遅いサイトでは、ページキャッシュだけでも効果が出ることがあります。ただ、今回のようにLCP要素の描画に時間がかかっているページでは、別の確認も必要になります。
ヒーロー画像のpreloadだけでは十分ではなかった
ファーストビューの背景画像にpreloadとfetchpriority="high"を追加し、ブラウザが重要画像を早く見つけられるようにしました。
結果はPerformanceが74から74〜75程度で、大きな改善にはなりませんでした。
画像の読み込み開始を早める施策としては正しいものの、今回のページでは画像取得後の描画遅延の影響がより大きかったようです。
LCP対策は、画像を軽くする、先読みする、キャッシュする、のどれか一つだけで終わらないことがあります。
WordPress高速化で最初に確認したいこと
1. キャッシュが有効になっているか
サーバー応答が遅い場合は、ページキャッシュだけでも効果が出ることがあります。
ただし、キャッシュを入れたあともLCPが遅いなら、次の原因を確認する必要があります。
2. LCP要素は何か
PageSpeed Insightsでは、LCPになっている画像や要素を確認できます。
ファーストビューの大きな画像、スライダー、背景画像、大きな見出しがLCPになることが多いところです。まず対象を特定しないと、対策の優先順位を決めにくいです。
3. 画像が遅いのか、描画が遅いのか
LCPが遅い理由は画像容量だけではありません。
- 画像の読み込み開始が遅い
- 画像の容量が大きい
- CSSやJavaScriptが描画を待たせている
- アニメーションやスライダーの初期化を待っている
- 背景画像がHTMLから見つけにくい
画像を軽くしても改善しない場合は、描画遅延を疑った方がいいかもしれません。
4. 数字だけでなく実際の表示も確認する
スコアが上がっても、レイアウトが一瞬動いたり、画像やメニューの表示が崩れたりすると本末転倒です。
今回のNitroPackでも、LCPは改善しましたが、無料版のバッジによるCLSが発生しました。
高速化の設定を変えたあとは、必ずスマホとPCで実際の表示も確認しておくべきです。
まとめ
今回のテストでは、NitroPackはPerformanceを74から90前後まで改善し、LCPも大きく短縮しました。
一方、WP-Optimizeのページキャッシュではサーバー応答の改善は確認できたものの、ファーストビュー画像の描画遅延は残りました。
WordPress高速化では、ひとつのプラグインを入れて終わりにしないことが大切です。
- まずキャッシュを確認する
- LCP要素を特定する
- 画像取得と描画遅延を分けて見る
- 数値と実際の表示を両方確認する
この順番で見ていくと、「何となく遅い」状態から、直すべき場所を絞り込みやすくなります。
※本記事は筆者のテスト環境での測定記録です。現時点でアフィリエイト用の追跡リンクは使用していません。