CDN（コンテンツ配信ネットワーク）を入れると、画像・CSS・JavaScript などを利用者に近い拠点から配信できるため、オリジンサーバーの負荷と転送時間を減らせます。ただし、入れただけで速くなるとは限らず、「何をどのくらいの期間キャッシュさせるか」をオリジン側で正しく指示することが効果の大半を決めます。この記事では、導入前の計測、CDN の方式選び、キャッシュ設定、WordPress 特有の注意点、導入後の確認までを順に説明します。
導入前に「今どこが遅いか」を計測する
CDN が効くのは、主に「静的ファイルの転送」と「サーバーから遠い利用者への配信」です。PHP の処理やデータベースが遅くて HTML の生成に時間がかかっている場合は、静的ファイルだけを CDN に載せても体感はあまり変わりません。まず現状を数値で残しておきます。
- PageSpeed Insights で対象ページを計測し、LCP（最大コンテンツの描画）と、ラボデータの「サーバーの応答時間」に関する指摘を記録する
- 開発者ツールの Network タブで、HTML の TTFB（最初の1バイトまでの時間）と、サイズの大きいファイルを確認する
- 可能なら、サーバーから物理的に遠い地域からも計測する
# HTML の TTFB と合計時間を見る（数回実行して傾向を見る）
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s total: %{time_total}s\n" https://example.com/TTFB が大きい場合は、CDN と並行してページキャッシュやオブジェクトキャッシュの導入を検討します。PageSpeed Insights のフィールドデータ（実際の利用者のデータ）は過去28日分の集計なので、改善が反映されるまで時間がかかる点も覚えておいてください。
CDN の方式を選ぶ
WordPress でよく使われる構成は、大きく2つに分かれます。
1つ目は、DNS をCDN 事業者に向けてサイト全体を通す方式です。Cloudflare のプロキシ機能が代表例で、ドメインのネームサーバーを切り替える（またはCNAME で向ける）だけで、静的ファイルが自動的にキャッシュされます。HTML まで含めて CDN を通るので、WAF や DDoS 対策も同時に効きますが、SSL の設定やアクセス元 IP の扱いなど、サイト全体に影響する設定が増えます。
2つ目は、静的ファイル専用のホスト名（例: cdn.example.com）を用意し、そこだけを CDN から配信する方式です。Amazon CloudFront、Bunny.net、KeyCDN などが該当します。HTML は今までどおりオリジンから返し、画像や CSS の URL だけを CDN のホスト名に書き換えます。影響範囲が限定されるので、既存サイトに段階的に入れやすいのが利点です。
どちらが向いているかは、DNS を移管できるか、WAF も同時に欲しいか、HTML のキャッシュまで踏み込むかで決まります。各社の機能や無料枠の範囲は頻繁に変わるため（2026年10月現在）、契約前に公式ドキュメントで確認してください。
オリジン側でキャッシュの期間を指示する
CDN は、オリジンが返す Cache-Control ヘッダーを見て、どのくらいキャッシュするかを決めるのが基本です。ここが空だったり no-cache だったりすると、CDN を通しても毎回オリジンに取りに行くため効果が出ません。
WordPress はテーマやプラグインの CSS・JavaScript に ?ver=6.x のようなバージョン付きクエリを付けて読み込むので、ファイルを更新すると URL が変わります。そのため静的ファイルには長めの期間を指定しても、更新が反映されないという問題は起きにくくなります。
nginx の例です。既存の server ブロック内、PHP の location とは別に置きます。
location ~* \.(?:css|js|woff2?|svg|png|jpe?g|gif|webp|avif|ico)$ {
add_header Cache-Control "public, max-age=2592000";
access_log off;
try_files $uri =404;
}つまずきやすいのは、nginx の add_header の継承です。location の中で1つでも add_header を書くと、server レベルで設定したセキュリティヘッダーなどはその location に引き継がれません。必要なヘッダーは同じ location に書き直してください。
Apache の場合は mod_expires を使います。
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType text/css "access plus 30 days"
ExpiresByType application/javascript "access plus 30 days"
ExpiresByType image/webp "access plus 30 days"
ExpiresByType image/png "access plus 30 days"
ExpiresByType image/jpeg "access plus 30 days"
ExpiresByType font/woff2 "access plus 30 days"
</IfModule>設定を変える前には、設定ファイルのバックアップを取り、nginx -t や apachectl configtest で文法を確認してから再読み込みします。
WordPress でキャッシュしてはいけないもの
静的ファイルだけを配信する方式なら問題は少ないですが、HTML まで CDN でキャッシュする場合は、ログイン中の画面や個人ごとに内容が変わるページを除外する設定が必須です。除外を誤ると、ある人の管理バーやカートの中身が別の人に表示されるといった事故につながります。
/wp-admin/配下と/wp-login.php- プレビュー（
preview=trueが付く URL） - ログイン中を示す Cookie（
wordpress_logged_in_で始まるもの）や、パスワード保護ページ用のwp-postpass_を持つリクエスト - コメント投稿者の Cookie（
comment_author_で始まるもの） - WooCommerce を使う場合のカート・チェックアウト・マイアカウントと、カート関連の Cookie
Cloudflare の公式 WordPress プラグインや、WP Rocket・W3 Total Cache・LiteSpeed Cache などのキャッシュ系プラグインには、CDN 連携やキャッシュ削除（パージ）の機能があります。記事を更新したときに CDN のキャッシュを消す仕組みがないと、古い内容が残り続けるので、HTML をキャッシュするならパージ連携とセットで導入します。設定項目の名前や無料版で使える範囲はプラグインのバージョンで変わるため、目的（URL の書き換え、パージ、除外ルール）で探してください。
CDN 経由にしたときに起きやすい問題
アクセス元 IP がすべて CDN の IP になる
サイト全体を CDN に通すと、オリジンから見た接続元は CDN の拠点になります。アクセスログ、セキュリティプラグインの IP 制限、ログイン試行の制限が CDN の IP を対象にしてしまうため、本来の利用者 IP を取り出す設定をします。nginx では realip モジュールを使い、信頼する CDN の IP 範囲だけからヘッダーを受け付けます。
# Cloudflare の場合の例。IP 範囲は https://www.cloudflare.com/ips/ の最新一覧で置き換える
set_real_ip_from 173.245.48.0/20;
# ...一覧の残りの範囲も列挙する
real_ip_header CF-Connecting-IP;任意の送信元からのヘッダーを信用すると、IP の偽装を許すことになるので、範囲の指定を省かないでください。
リダイレクトが繰り返される
CDN とオリジンの間を HTTP で接続し、WordPress 側は HTTPS へリダイレクトする構成にすると、ページが開かず「リダイレクトが繰り返されました」と表示されることがあります。Cloudflare なら SSL の暗号化モードを、オリジンにも証明書を入れたうえで厳格な検証を行うモード（Full (strict) など）にするのが基本です。
フォントや一部の画像が読み込まれない
CSS から別ホスト名のフォントを読むと、ブラウザが CORS の許可を求めます。静的ファイル用ホスト名を分けた場合は、フォントファイルに Access-Control-Allow-Origin を返す設定が必要です。
導入後に効いているか確認する
レスポンスヘッダーで、CDN のキャッシュに当たっているかを確認します。
curl -sI https://example.com/wp-includes/css/dist/block-library/style.min.css | grep -iE "cf-cache-status|x-cache|age|cache-control"Cloudflare なら cf-cache-status: HIT、CloudFront なら x-cache: Hit from cloudfront が出ていればキャッシュから返っています。初回は MISS になるのが普通なので、2回以上実行して確かめます。何度試しても MISS や BYPASS の場合は、オリジンの Cache-Control か、CDN 側のキャッシュルールを見直します。
最後に、導入前と同じ条件で PageSpeed Insights と curl の計測をし、数値を比べてください。順位やコンバージョンの改善は他の要因にも左右されるため、まずは TTFB・LCP・オリジンの負荷という直接の指標で効果を判断するのが現実的な進め方です。
まとめ
- 先に計測し、遅さの原因が静的ファイルの転送か HTML の生成かを見分ける
- サイト全体を通す方式と、静的ファイル専用ホスト名の方式があり、影響範囲が異なる
- 効果を決めるのはオリジンの
Cache-Control。nginx のadd_headerの継承に注意する - HTML をキャッシュするなら、管理画面・ログイン Cookie・カートなどを除外し、パージ連携を入れる
- 実 IP の取り出し、SSL モード、フォントの CORS を確認し、導入後はヘッダーで HIT を確かめる