サーバーが日本にあるWordPressサイトを海外から開くと、通信の往復に時間がかかり、画像やCSSの多いページほど表示が遅くなります。CDN（コンテンツ配信ネットワーク）を使うと、世界各地の拠点（エッジ）にファイルの複製を置き、利用者に近い場所から配信できるため、この距離による遅れを小さくできます。この記事では、海外の読者が多いサイトを想定して、CDNの導入方式の選び方、キャッシュしてよいもの・いけないものの切り分け、WordPress側の設定、地域ごとの効果の確かめ方を説明します。
海外アクセスが遅くなる理由とCDNで改善できる範囲
ページを表示するには、HTML、CSS、JavaScript、画像、フォントといった多数のファイルを取得します。1回の往復が日本国内なら数十ミリ秒でも、欧米からだと100ミリ秒を大きく超えることがあり、ファイルの数だけその遅れが積み重なります。
CDNが効くのは、主に次の2点です。
- 静的ファイル（画像・CSS・JS・フォント）の配信：エッジから返るので、往復の距離が短くなります。
- HTMLのキャッシュ：設定すれば、ページ本体もエッジから返せます。ここまでできると、海外での初回表示の待ち時間（TTFB）が大きく縮みます。
一方で、ログイン後の管理画面、コメント投稿、ECサイトのカートや決済のように利用者ごとに内容が変わる部分は、キャッシュできません。これらはオリジン（元のサーバー）の処理速度に左右されるため、サーバー側の高速化と組み合わせて考える必要があります。
導入方式を選ぶ
WordPressでCDNを使う方式は大きく2つです。
DNSごとCDNを経由させる方式（リバースプロキシ型）
Cloudflare のように、ドメインのDNSをCDN側に向け、サイトへのアクセスをすべてCDN経由にする方式です。URLを書き換える必要がなく、静的ファイルは標準でキャッシュされます。HTMLまでキャッシュしたい場合は、キャッシュルールの設定や、WordPress向けの追加機能を使います。CDNがSSLの終端にもなるため、オリジン側の証明書との組み合わせ（後述）に注意が要ります。
静的ファイルだけ別ドメインから配信する方式（プル型）
Amazon CloudFront や Bunny CDN などで「プルゾーン」を作り、cdn.example.com のような配信用ドメインから画像やCSSを配信する方式です。DNSを移す必要がなく、既存の構成を変えにくい場合に向いています。WordPress側では、出力するURLを配信用ドメインに書き換える設定が必要です。WP Rocket、LiteSpeed Cache、W3 Total Cache などのキャッシュプラグインにはCDNのURLを指定する項目があり、Bunny CDN のように公式プラグインを提供しているサービスもあります（2026年10月現在。項目名や機能はバージョンにより異なります）。
どちらの方式でも、データベース内の画像URLを一括置換してCDNのドメインに書き換えるのはおすすめしません。出力時に書き換える方式なら、CDNをやめるときに設定を外すだけで元に戻せます。
キャッシュしてはいけないものを先に決める
HTMLまでキャッシュする場合、設定を誤ると「他人のログイン状態やカートの中身が表示される」といった事故につながります。最初に、キャッシュの対象外にするものを決めておきます。
/wp-admin/配下とwp-login.php- ログイン中の利用者（
wordpress_logged_in_で始まるCookieを持つリクエスト） - コメント投稿者のCookieがあるリクエスト
- WooCommerce などを使っている場合は、カート・決済・マイアカウントのページと、関連するCookieを持つリクエスト
- プレビュー、検索結果、フォーム送信後のページなど、動的に変わるページ
Cloudflare のWordPress向け最適化機能のように、こうした除外を前提にHTMLキャッシュを行う仕組みもあります。自分でキャッシュルールを書く場合は、上記の条件を漏れなく除外してください。
WordPress側で整えておく設定
静的ファイルのキャッシュ期間を長くする
WordPressが読み込むCSSやJSには ?ver=6.x のようなバージョン付きのクエリ文字列が付きます。CDN側でクエリ文字列をキャッシュキーに含める設定にしておけば、テーマやプラグインを更新したときにURLが変わり、古いファイルが残りません。そのうえで、オリジンが静的ファイルに長めの Cache-Control を返すようにしておくと、エッジにも利用者のブラウザにも長く保持されます。
更新時にキャッシュを消す仕組みを用意する
HTMLをキャッシュする場合、記事を更新しても古いページが配信され続けることがあります。Cloudflare の公式プラグインや、CDN連携機能のあるキャッシュプラグインを使うと、記事の更新時に該当URLのキャッシュを自動で削除（パージ）できます。手動で全削除する運用にすると、削除直後はすべてのリクエストがオリジンに集中するため、更新頻度の高いサイトでは自動パージを検討してください。
SSLの組み合わせを正しくする
リバースプロキシ型では、CDNとオリジンの間の通信方式を選びます。Cloudflare の場合、CDN〜オリジン間を暗号化しない「Flexible」を選ぶと、WordPress側がHTTPSへ転送しようとしてリダイレクトが繰り返される問題が起きやすくなります。オリジンにも有効な証明書を入れ、証明書を検証する「Full (strict)」で運用するのが基本です。
訪問者の本当のIPアドレスを受け取る
CDN経由になると、サーバーから見た接続元はCDNのIPアドレスになります。そのままだと、セキュリティプラグインのログイン試行制限やアクセス解析が誤作動します。Cloudflare なら CF-Connecting-IP ヘッダーに元のIPが入るので、Apache の mod_remoteip や Nginx の real_ip モジュールで、CDNのIP範囲からのアクセスに限ってこのヘッダーを信頼する設定を入れます。
フォントを別ドメインから配信する場合
プル型でWebフォントを配信用ドメインから読み込むと、ブラウザがクロスオリジンとして扱い、Access-Control-Allow-Origin ヘッダーがないとフォントが表示されないことがあります。CDN側またはオリジン側でこのヘッダーを返すように設定してください。
設定がうまく動いているか確認する
まずレスポンスヘッダーで、エッジから返っているかを確認します。
# 2回目以降のリクエストでキャッシュに当たっているかを見る
curl -sI https://example.com/wp-content/themes/your-theme/style.css | grep -iE "cf-cache-status|x-cache|age|cache-control"Cloudflare なら cf-cache-status: HIT、CloudFront なら x-cache: Hit from cloudfront のような表示がキャッシュから返った目印です。MISS が続く場合は、キャッシュ対象の設定やオリジンの Cache-Control を見直します。HTMLをキャッシュしているなら、ログイン中にもヘッダーを確認し、キャッシュの対象外（BYPASS など）になっていることを確かめてください。
次に、海外での効果を測ります。WebPageTest のように計測地点を選べるサービスを使えば、北米・欧州・アジアなど複数の地域からTTFBや表示完了までの時間を比べられます。導入前後で同じ地点・同じURLを測ると、効果が分かりやすくなります。Search Console の Core Web Vitals レポート（画面上の表記は変わることがあります）は実際の利用者のデータを集計するため、反映までに数週間かかる点も覚えておいてください。
まとめ
- CDNは利用者に近いエッジから配信し、海外アクセスで積み重なる往復の遅れを減らす
- 方式はDNSごと経由させるリバースプロキシ型と、静的ファイルだけ配信するプル型がある
- HTMLをキャッシュするなら、管理画面・ログイン中・カートなどの除外を最初に決める
- キャッシュ期間、更新時のパージ、SSLの組み合わせ、実IPの受け取りをWordPress側でも整える
- ヘッダーと複数地域からの計測で、キャッシュの効き方と効果を確認する