CDNを入れても速くならない理由10選【WordPress高速化の落とし穴】

CDN（Content Delivery Network）は、Webサイトのコンテンツを利用者に近い拠点から配信し、通信時間やオリジンサーバーへの負荷を減らすための仕組みです。

WordPressでもCloudflare、Amazon CloudFrontなどのCDNを利用することで、画像・CSS・JavaScriptなどの配信を効率化できる場合があります。

ところが、

「CDNを導入したのに、ほとんど速くならない」

というケースは珍しくありません。

これはCDN自体が悪いとは限らず、キャッシュ設定、WordPressの処理速度、キャッシュHIT率、画像やJavaScriptの重さなど、別の場所がボトルネックになっていることがあります。

この記事では、WordPressにCDNを導入しても高速化を実感できない代表的な原因を10個に分けて解説します。

1 原因① CDNが実際にはWebアクセスの経路に入っていない

最初に確認したいのは、CDNを契約・設定しただけで満足してしまい、実際のWebアクセスがCDNを経由していないケースです。

たとえばCloudflareでは、Webサイト用のA・AAAA・CNAMEレコードがProxiedになっていなければ、Cloudflareのプロキシを経由しません。

CloudflareのDNS画面では、Webサイト用レコードがオレンジ色の雲になっているか確認します。

ただし、メール用ホスト名までオレンジ雲にすればよいという意味ではありません。
メール用のDNS設定はWebサイトとは別に確認する必要があります。

1.1 別のCDN用URLを使用する構成の場合

CDNによっては、

www.example.com
↓
cdn.example.com

のように静的ファイル用URLを分ける構成もあります。

この場合、WordPress側の画像やCSSが実際にCDN用URLから読み込まれているか確認しましょう。

まず「CDNが本当に使われているのか」を確認することが第一歩です。

2 原因② キャッシュHIT率が低い

CDNを利用していても、毎回オリジンサーバーまで取りに行っているのであれば、高速化の効果は限定的です。

CDNでは、

• キャッシュから返せたリクエスト
• オリジンサーバーへ取りに行ったリクエスト

の割合を確認することが重要です。

Cloudflareの場合はレスポンスヘッダーの CF-Cache-Status でキャッシュ状態を確認できます。

代表的な状態には、

• HIT：Cloudflareのキャッシュから配信
• MISS：キャッシュ対象だが、その時点ではキャッシュに存在しなかった
• BYPASS：条件やレスポンスによってキャッシュされなかった

などがあります。

HITの場合は Age ヘッダーが付くこともあります。

2.1 確認例

curl -I https://example.com/wp-content/uploads/example.jpg

Cloudflareを利用している場合は、

CF-Cache-Status: HIT

などを確認できます。

3 原因③ HTMLをキャッシュしていないため、WordPressが毎回ページを生成している

画像・CSS・JavaScriptがCDNから高速配信されても、HTML自体をWordPressが毎回生成している場合、HTMLの応答速度はオリジンサーバーの性能に左右されます。

Cloudflareでは、標準設定で画像やCSS、JavaScriptなどの静的ファイルはキャッシュ対象になりますが、HTMLやJSONは標準ではキャッシュされません。

そのため、通常のWordPressページは、

Cloudflare
↓
Webサーバー
↓
PHP
↓
WordPress
↓
データベース
↓
HTML生成

という処理が発生します。

3.1 CloudflareでWordPressのHTMLまでエッジキャッシュしたい場合

CloudflareではCache Rulesを利用してキャッシュ対象を調整できます。

また、WordPress向けにはAutomatic Platform Optimization（APO）という仕組みも用意されています。

APOとCloudflare公式WordPressプラグインを利用すると、WordPressの記事更新時のキャッシュ更新や、ログイン中ユーザーのキャッシュ回避などが考慮されます。

WordPress全体のHTMLを独自ルールで無条件にキャッシュするより、安全に運用しやすい方法の一つです。

3.2 HTMLを何でもキャッシュしてはいけない

WordPressにはキャッシュに注意が必要なページがあります。

• 管理画面
• ログインページ
• ログインユーザー向けページ
• お問い合わせフォーム
• 検索結果
• 会員ページ
• WooCommerceのカート・決済ページ
• ユーザーによって内容が変化するページ

HTMLキャッシュを設定する場合は、これらの動的ページを不用意にキャッシュしないことが重要です。

4 CloudFrontではHTMLキャッシュにLambda@Edgeが必須ではない

Amazon CloudFrontでもHTMLをキャッシュできます。

古い解説では、

CloudFront
＋
Lambda@Edge
＝
HTMLキャッシュ

のように説明されていることがありますが、HTMLをキャッシュするためだけにLambda@Edgeが必須というわけではありません。

CloudFrontではCache BehaviorやCache Policy、オリジンサーバーが返す Cache-Control などによってキャッシュ動作を制御できます。

Lambda@EdgeやCloudFront Functionsは、通常のキャッシュ設定だけでは実現できない独自処理が必要な場合に検討します。

5 原因④ Cookie・クエリ文字列・ヘッダーによってキャッシュが細分化されている

CDNでは「同じURLだから必ず同じキャッシュを使う」とは限りません。

設定によっては、

• Cookie
• URLのクエリ文字列
• HTTPヘッダー

などもキャッシュを区別するための情報として使用されます。

たとえば、

example.com/page/?a=1
example.com/page/?a=2
example.com/page/?a=3

がすべて別のキャッシュとして扱われれば、同じページに近い内容でもキャッシュが分散してHIT率が下がることがあります。

Cookieについても「Cookieがあるから必ずキャッシュできない」というわけではありません。

重要なのは、そのCookieやパラメータによってレスポンス内容が本当に変化するのかです。

キャッシュキーへ不要なCookie、ヘッダー、クエリ文字列まで含めると、キャッシュHIT率が下がります。

6 原因⑤ キャッシュ時間が短すぎる・削除しすぎている

キャッシュ対象になっていても、TTLが非常に短かったり、頻繁にキャッシュを全削除していたりすると、MISSが増えます。

たとえば更新のたびに、

全URLのキャッシュを削除

している場合、更新直後は大量のページが再びMISSになります。

可能であれば、更新したページや関連するURLだけを削除する方が効率的です。

一方で、TTLをむやみに長くすればよいわけでもありません。

CSS、JavaScript、画像、HTMLでは適切なキャッシュ期間が異なります。

「長期間キャッシュすること」と「更新時に正しくキャッシュを無効化できること」をセットで考える必要があります。

7 原因⑥ オリジンサーバーのTTFBが遅い

CDNでキャッシュHITすればオリジンサーバーへアクセスせずに済む場合があります。

しかし、

• キャッシュMISS
• ログインユーザー
• 動的ページ
• キャッシュ対象外ページ
• キャッシュ期限切れ

では、オリジンサーバーの速度がそのまま影響します。

WordPress側のTTFBが遅い場合は、CDNだけでは解決できないことがあります。

7.1 WordPress側で確認したいポイント

• PHPのバージョンが適切か
• 重いプラグインがないか
• データベースクエリが遅くないか
• autoloadされるoptionが肥大化していないか
• 外部APIへの通信待ちがないか
• ページキャッシュが利用できる構成か
• サーバーのCPUやメモリが不足していないか

CDNを入れたあともTTFBが遅い場合は、まずキャッシュHIT時とMISS時を分けて測定すると原因を判断しやすくなります。

8 wp-cronをサーバーcronへ変更すれば必ずTTFBが速くなるわけではない

WordPressのWP-Cronはアクセスをきっかけに実行される仕組みなので、アクセス時の処理を減らす目的でサーバー側のcronへ変更する構成もあります。

ただし、

「TTFBが遅いなら、とりあえずWP-Cronをリアルcron化すれば直る」

というものではありません。

TTFBが遅い場合は、PHP、データベース、外部通信、プラグイン、ページキャッシュなどを含めて原因を調べる必要があります。

9 原因⑦ キャッシュが複数あることではなく、連携できていない

WordPressでは、

ブラウザキャッシュ
↓
CDNキャッシュ
↓
レンタルサーバーのキャッシュ
↓
WordPressキャッシュプラグイン
↓
WordPress

のように複数のキャッシュ層が存在することがあります。

「キャッシュは必ず1ヶ所だけにする」という考え方は正しくありません。

複数のキャッシュを組み合わせること自体は可能です。

問題になりやすいのは、

• WordPressの記事を更新した
• WordPress側のキャッシュだけ削除された
• CDNには古いHTMLが残っている

というように、キャッシュ削除が連携していない状態です。

複数のキャッシュを利用する場合は、

• どこで何をキャッシュしているのか
• 更新時にどのキャッシュが削除されるのか

を把握しておきましょう。

10 原因⑧ 画像・CSS・JavaScriptそのものが重い

CDNはファイルを効率よく届けることはできますが、ファイルそのものを必ず軽量化してくれるわけではありません。

たとえば5MBの大きな画像をCDNから配信しても、利用者はその画像データをダウンロードする必要があります。

また、大量のJavaScriptをCDNから素早くダウンロードできても、ブラウザで実行する時間は別に必要です。

10.1 確認したいポイント

• 必要以上に大きな画像を使用していないか
• 適切な画像形式を利用しているか
• レスポンシブ画像が機能しているか
• 不要なJavaScriptを読み込んでいないか
• 使用していないCSSが大量にないか
• Webフォントを読み込みすぎていないか
• ファーストビューの巨大画像がLCPを遅らせていないか

11 Cloudflare PolishとCDNキャッシュは別の機能

CloudflareのPolishは画像のメタデータ除去や圧縮などを行う画像最適化機能です。

これは、

「Cloudflare CDNを利用すれば自動的にすべての画像が最適化される」

という意味ではありません。

また、画像のリサイズ・形式変換・最適化などにはCloudflare Imagesの画像変換機能もあります。

CDNによる配信と、画像そのものの最適化は分けて考えましょう。

12 Cloudflareで画像URLを書き換える必要があるとは限らない

CloudflareでWebサイト自体をProxiedにしている場合、通常のWordPress画像URLでもCloudflareを経由します。

そのため、

https://example.com/wp-content/uploads/photo.jpg

を、

https://cdn.example.com/photo.jpg

へ必ず書き換えなければCDNが使えない、というわけではありません。

どのようなURL構成が必要かは、利用しているCDNの方式によって異なります。

13 原因⑨ CDNを経由すること自体がボトルネックになっている

CDNは利用者に近い場所からコンテンツを届けることで効果を発揮します。

しかし、すべてのサイトでCDNを導入した瞬間に高速化するとは限りません。

たとえば、

• 利用者がほぼ日本国内だけ
• オリジンサーバーも日本国内にある
• もともとのサーバー応答が非常に速い
• キャッシュ対象が少ない

といったサイトでは、CDN導入前後で大きな差が出ない場合もあります。

「このCDNの東京POPは遅い」などと先に決めつけるのではなく、実際の利用者に近い環境で測定することが重要です。

13.1 Cloudflare Argo Smart Routingについて

CloudflareにはArgo Smart Routingがあります。

これは特定の日本拠点へ接続先を変更するための機能ではなく、リアルタイムのネットワーク情報をもとに、Cloudflareネットワーク上でより効率的な経路を利用するための機能です。

ネットワーク経路がボトルネックになっている場合には改善につながる可能性がありますが、WordPressのPHP処理や巨大な画像まで改善する機能ではありません。

14 原因⑩ 測定方法が間違っている

実際にはCDNが機能しているのに、測定方法の問題で「速くなっていない」と判断してしまうことがあります。

たとえばキャッシュを削除した直後の最初のアクセスはMISSになり、その結果だけを測定するとCDNの効果を正しく評価できません。

また、PageSpeed InsightsやLighthouseの点数はCDNだけで決まるものではありません。

評価には、

• LCP画像
• JavaScriptの実行時間
• CSS
• Webフォント
• レイアウトシフト
• サーバー応答
• ネットワーク状況

など多くの要素が関係します。

15 CDN導入後はHITとMISSを分けて測定する

CDNの効果を調べるときは、

1. CDNを経由していることを確認する
2. 対象ファイルがキャッシュ可能か確認する
3. 最初のMISS時の速度を確認する
4. 2回目以降のHIT時の速度を確認する
5. オリジンサーバーのTTFBも別に確認する

というように分けると原因を判断しやすくなります。

Cloudflareでは CF-Cache-Status を利用できます。
Amazon CloudFrontでは管理画面のキャッシュ統計などを利用してHIT・MISSの割合を確認できます。

16 Cloudflareで新しくキャッシュルールを作るならCache Rules

古いCloudflareの記事では、

Page Rules
Cache Everything

を使った設定が多く紹介されています。

しかし現在、Page Rulesは非推奨となっており、新しくキャッシュ制御を設定する場合はCache Rulesを中心に検討します。

Cache Rulesでは、

• キャッシュ対象・対象外
• Edge TTL
• Browser TTL
• Cache Key

などを条件に応じて設定できます。

17 「CDNのMinifyをON」はCloudflareでは古い情報

古いCloudflare高速化記事では、

Auto Minify
HTML ON
CSS ON
JavaScript ON

という設定が紹介されていることがあります。

CloudflareのAuto Minifyはすでに非推奨となっているため、現在の記事でCloudflare高速化の必須設定として紹介するのは適切ではありません。

CSSやJavaScriptを小さくしたい場合は、WordPress側や制作時のビルド工程など、現在利用している環境に合った方法を検討しましょう。

18 CDNを入れても速くならないときの確認順序

1. Webアクセスが本当にCDNを経由しているか確認する
2. 画像・CSS・JavaScriptのキャッシュ状態を確認する
3. HIT率を確認する
4. Cookie・クエリ文字列・ヘッダーでキャッシュが分散していないか確認する
5. HTMLをエッジキャッシュする必要があるか判断する
6. キャッシュMISS時のオリジンTTFBを確認する
7. キャッシュ削除が各レイヤーで正しく連携しているか確認する
8. 画像・CSS・JavaScript自体の重さを確認する
9. CDN導入前後を同じ条件で比較する
10. PageSpeed Insightsの点数だけで判断しない

19 まとめ：CDNは「入れるだけ」で速くなるものではない

CDNはWordPress高速化に役立つ仕組みですが、導入しただけですべての問題が解決するわけではありません。

特に重要なのは、

• CDNを実際に経由しているか
• キャッシュHIT率が十分か
• キャッシュキーが細分化されすぎていないか
• HTMLをキャッシュする必要があるか
• オリジンサーバー自体が遅くないか
• 画像やJavaScriptが重すぎないか

を切り分けて確認することです。

Cloudflareを利用している場合、まず CF-Cache-Status を確認すると、CDNがどのようにリクエストを処理しているのかを判断しやすくなります。

WordPressのHTMLまでCloudflareのエッジから配信したい場合はAPOやCache Rulesも選択肢になりますが、管理画面、ログインユーザー、フォーム、カートなどの動的コンテンツを不用意にキャッシュしないよう注意が必要です。

また、複数のキャッシュを使うこと自体が悪いわけではありません。
重要なのは、各キャッシュの役割を理解し、WordPress更新時に正しくキャッシュを削除できる構成にすることです。

CDNを導入しても速くならないときは、「もっと高速化機能をONにする」のではなく、HIT・MISS・TTFB・ページ自体の重さを一つずつ測定して原因を特定することが、最も確実な改善方法です。