南米にCDNのノードがあるのに、なぜウェブサイトの表示が遅いのでしょうか？

南米にCDNを導入しているのにサイトが遅い場合、通常は3つの点を確認する必要があります。訪問者が適切なノードに接続されているか、リクエストがキャッシュにヒットしているか、キャッシュにヒットしない場合にオリジンサーバーへの接続がスムーズかどうかです。ノード分布図に南米の拠点が表示されていても、サービスを提供できることを示すだけで、特定のアクセスが実際に有効な高速化の恩恵を受けたことを証明するものではありません。

調査の際は、対象のページ、アクセス時刻、都市、通信事業者を記録してから、ブラウザーのネットワークリクエスト記録を確認します。「ブラジルの顧客から遅いと言われた」や国内での速度測定結果だけでは、ネットワーク経路、サーバーの応答、ページ自体の読み込み遅延を切り分けるのは困難です。

まず、接続が遅いのか、最初の1バイトまでが遅いのか、ページの表示が遅いのかを切り分ける

ブラウザーの開発者ツールでNetworkパネルを開き、ブラウザーキャッシュを無効にして再読み込みします。ページのドキュメント、ファーストビューの大きな画像、主要なスクリプトを重点的に確認してください。これにより、ブラウザーのローカルキャッシュとCDNキャッシュの影響をより簡単に切り分けられます。

• DNS、接続、またはTLSの段階に明らかな時間がかかる：ドメイン名の解決、ノードの振り分け、アクセス回線を優先して確認します。
• 最初の1バイトまでの待ち時間が長い：エッジでの処理、キャッシュミス、オリジンサーバーへのネットワーク、またはオリジンサーバー側の計算処理が関係している可能性があります。すぐにサーバーの性能が原因だと判断することはできません。
• ドキュメントはすぐに表示されるのに、コンテンツがなかなか表示されない：大きな画像、レンダリングを妨げるスクリプト、フォント、サードパーティーコンポーネントを確認します。

たとえば、製品ページのテキストは表示されているのにメイン画像の読み込みが遅い場合は、画像のリクエストを確認し、ページドキュメントのキャッシュを調整し続けるのではなく、画像のリクエストを調べます。ページ全体が最初の応答を待っている場合は、CDNからオリジンサーバーまでの経路を調査します。

南米にノードがあっても、実際のリクエストが適切な場所に到達するとは限らない

南米では、国や都市、通信事業者によってネットワーク相互接続の状況が異なります。地理的に近いノードが、必ずしもよりスムーズなアクセス経路になるとは限りません。ネットワークによっては、他の地域を経由する場合もあります。振り分けは、再帰DNS、通信事業者間の相互接続、ノードの負荷の影響を受けることもあります。

まずCDNコンソールで、対象地域にビジネスドメインが有効化されていることを確認します。次に権威DNSの設定を確認し、現地での実際の名前解決結果がサービスプロバイダーの要件を満たしているか照合します。CNAMEで接続している場合は、レコードが旧プラットフォームやオリジンサーバーを指したままになっていないことを確認してください。

続いて、レスポンスヘッダー内のノード識別子、CDNログ、現地でのテストを組み合わせて、リクエストが実際にどこで処理されたかを確認します。ノード識別子の意味はプラットフォームによって異なるため、IPアドレスの位置情報データベースだけで判断したり、1回のpingをウェブページ全体の表示体験とみなしたりしてはいけません。

テストは、主要顧客がいる都市とネットワークを対象に実施してください。同じページが固定回線では正常なのにモバイルネットワークでは遅い場合、通信事業者の経路をさらに確認する必要があるでしょう。IPv6を有効にしている場合は、IPv4とIPv6を個別に比較し、特定の経路の問題が全体の平均値に埋もれないようにします。

キャッシュヒット率が高くても、そのページがキャッシュにヒットしているとは限らない

コンソール上の全体ヒット率は、多数の小さな画像によって高くなっている一方で、広告のランディングページや製品詳細ページでは頻繁にオリジンサーバーへアクセスしている可能性があります。遅いリクエストごとにキャッシュの状態を確認してください。手掛かりとしては、Cache-Control、Age、プラットフォームが提供するヒット識別情報などがあります。これらの情報は、各プラットフォームのルールに照らして解釈する必要があります。

オリジンサーバーへのアクセスが繰り返し発生する原因としては、オリジンサーバーがprivateまたはno-storeを返す、リクエストにCookieが含まれるとバイパスルールが適用される、URLパラメーターがキャッシュキーに含まれる、多言語版やモバイル版が細分化されてキャッシュの種類が増えすぎる、といったケースがあります。アクセス頻度の低いページも、キャッシュの期限切れや削除によって再びオリジンサーバーへアクセスすることがあります。

海外向けのマーケティングでは、広告のトラッキングパラメーターに特に注意が必要です。同じランディングページでも、異なるパラメーターを付けるたびに別個のキャッシュが作られると、実際の再利用率が低下します。コンテンツに影響しないことが確認できたトラッキングパラメーターについては、キャッシュキーの設定を調整できます。ただし、言語、通貨、仕様、ユーザーIDを決定するパラメーターを無視してはいけません。

キャッシュを最適化する前に、コンテンツの境界を明確にする必要があります。公開画像、スタイルシート、スクリプトは通常、長めのキャッシュ期間に適しています。問い合わせフォームの送信、カート、ログイン状態、個別価格は、それぞれ個別に設定してください。すべてのリクエストを強制的にキャッシュすると、情報が混在したり、送信時に異常が発生したりするおそれがあります。

キャッシュヒット時は速く、ミス時は遅い場合、オリジンサーバーへの経路をさらに調べる

同じ地域、近い時間帯に、同じリソースへ繰り返しリクエストを送り、ヒット状況とあわせて所要時間を比較します。キャッシュミス時に明らかに遅く、ヒット時には正常に戻る場合は、オリジンサーバーへのアクセスを重点的に調べます。初回アクセスの遅さはDNSや接続確立などの影響を受けることもあるため、2回の読み込みを体感で比べるだけで結論を出してはいけません。

オリジンサーバーへのアクセス時間は、エッジノードからオリジンサーバーへの接続が遅いのか、オリジンサーバーがリクエストを受け取ってからコンテンツを生成するまでが遅いのかに分けて確認します。前者では、オリジンサーバーの設置地域、地域間ネットワーク、接続の再利用、オリジンサーバーのファイアウォールを確認します。後者では、アプリケーションログ、データベースクエリ、ページが他のAPIを同期的に呼び出しているかどうかを確認します。

オリジンサーバーがアジアにあり、顧客が南米に集中している場合、動的リクエストでは地域をまたぐ長い往復時間が発生する可能性があります。静的コンテンツのキャッシュを増やしても、この待ち時間は解消できません。ビジネスに応じて、地域別オリジンサーバー、階層型キャッシュ、動的コンテンツの経路最適化を検討できますが、サーバーを移行する際は、他の市場、データ同期、運用コストもあわせて考慮する必要があります。

ページが開いても、マーケティング用コンポーネントが操作を遅くすることがある

ウェブサイト構築、SEO、広告配信、ソーシャルメディアからの集客を同じサイトで行っている場合、オンライン接客ツール、動画の埋め込み、分析スクリプト、フォント、フォームのAPIは、別々のドメインから読み込まれることがあります。メインサイトにCDNを導入しても、こうした外部リクエストが自動的に高速化されるわけではありません。

リクエストのウォーターフォール図でファーストビューに必要な要素を特定し、まずメイン画像を圧縮して画面サイズに適した画像を出力し、必須でないコンポーネントの読み込みを遅らせます。速度測定のスコアを上げるためだけにアクセス解析コードを削除するのではなく、調整後に広告の効果測定、問い合わせフォーム、購入フローが正常に機能することを確認してください。

変更のたびに前後の比較結果を残します。同じ地域、ネットワーク、ページを使用し、キャッシュヒット時とミス時の表示をそれぞれ記録するとともに、フォームの送信や重要なコンテンツの更新も確認してください。サービスプロバイダーに調査を依頼する際は、アクセス時刻、リクエストURL、ノード識別子、キャッシュの状態、リクエスト追跡IDを添えると、問題箇所をより早く特定できます。

主要顧客のネットワークが継続的に不適切なノードへ振り分けられている、または現地の相互接続品質を改善できないことを示す証拠がある場合に限り、CDNの変更を検討する明確な根拠があります。ボトルネックが動的API、キャッシュルール、サードパーティースクリプトにある場合は、対応する箇所を先に修正してから、ノードのカバー範囲が十分かどうかを評価してください。