CDNの速度が遅くなる原因とは？ウェブサイト高速化の調査・最適化方法を詳しく解説

先にサービス業者を変更するのではなく、まず遅延が発生している箇所を確認しよう

　　多くのサイトでは CDN を導入した後、監視画面上は「高速化されている」ように見えても、ユーザーの体感速度は依然として遅いままです。アフターサポートで最もよくある誤判断は、すべての問題をエッジノードの性能不足に帰してしまうことです。実際には、cdnの速度低下は単一の原因によるものではなく、DNS名前解決、接続確立、キャッシュヒット、オリジンサーバーへのリクエスト、ページリソースの構成のいずれかがボトルネックになっているケースがよくあります。

　　調査する際は、いきなりトップページ全体の読み込み時間だけを見るのは避けましょう。まず、DNS名前解決にかかる時間、TCP と TLS の接続確立時間、TTFB、静的リソースがキャッシュにヒットしているか、遅いのが全地域なのか一部地域なのか、画像が遅いのか API が遅いのかを分解して確認します。最初にボトルネックのある経路を特定してこそ、その後の最適化で手戻りが発生しません。

　　実際の対応では、「影響範囲の確認、ヒット率の確認、オリジンサーバーへのリクエストの確認、リソース容量の確認」の順で進めることをおすすめします。こちらのほうがはるかに効率的です。

まず判断する：サイト全体が遅いのか、それとも一部だけが遅いのか

　　この手順は基本的ですが、非常に重要です。遅延の種類によって、その後に調査すべき方向がまったく異なるためです。

• トップページ、一覧ページ、詳細ページのすべてが遅い場合は、DNS、証明書のハンドシェイク、オリジンサーバーの負荷、CDN のグローバル設定を優先的に確認します。
• 画像だけが遅い場合は、通常、画像容量、フォーマット、キャッシュルール、オリジンサーバーへのリクエスト頻度を確認します。
• API だけが遅い場合は、多くの場合すでに CDN の問題ではありません。動的リクエストをキャッシュできず、オリジンサーバー側の処理自体が遅い可能性があります。
• 特定の国や地域だけが遅い場合は、ノードのカバレッジ、越境回線の品質、通信事業者ネットワークの揺らぎを重点的に調査します。

　　アフターサポートの現場では、ユーザーの「サイトがとても重い」という一言だけでは情報量が不足しています。少なくとも、アクセス地域、アクセス時間、遅いのがページなのかバックエンド API なのか、断続的に発生するのか、すべての通信事業者で再現するのかを確認する必要があります。これらの情報を早く入手するほど、遠回りを避けられます。

ノードがあっても、必ず速くなるとは限らない

　　CDN について「ユーザーに近い」という点だけで理解している人は少なくありません。しかし、それは半分しか正しくありません。ノード数が多いからといってルーティングが適切とは限らず、ノードがユーザーに近くても、オリジンサーバーまでの経路が短いとは限りません。

　　まず、次の2つの現象を確認できます。1つ目は、地域によって TTFB に大きな差があるかどうか。2つ目は、特定地域で名前解決のたびに割り当てられるエッジノードが安定しているかどうかです。同じ地域で不適切なノードに頻繁に割り当てられると、アクセス体験は速くなったり遅くなったりします。この場合、単純に「ノードを追加」するだけでは解決できません。ルーティング戦略、回線の種類、現地のカバレッジ品質を確認する必要があります。

　　海外向けサイトでは、この問題がより一般的です。北米、欧州、東南アジアを対象とするサイトでユーザーが広範囲に分散している場合、単一地域だけを最適化しても効果はありません。主要なトラフィック市場ごとに測定する必要があります。アフターサポートでは、現地のネットワークだけで測定して結論を出してはいけません。

キャッシュヒット率が低いと、CDN は実質的に半分しか機能しない

　　これは最もよくあるケースの1つです。サイトに CDN を導入していても、キャッシュルールが適切に設定されていなければ、大量のリクエストが依然としてオリジンサーバーに送られ、ユーザーは当然高速化を実感できません。

　　調査時は、次の点を重点的に確認します：

1. 静的リソースにランダムなパラメーターが付いており、同じファイルが異なる URL として扱われていないか。
2. 画像、JS、CSS のキャッシュ時間が短すぎないか。数分しか設定されていない、またはキャッシュされていない状態になっていないか。
3. レスポンスヘッダーに、キャッシュに不利な制御フィールドが含まれていないか。
4. 本来キャッシュ可能なリソースを、認証が必要なパスや Cookie を付与するパスに配置していないか。

　　ここでは、実用的な判断方法があります。静的リソースのアクセス数が少なくないにもかかわらず、オリジンサーバーの帯域幅とリクエスト数が常に高い場合、ほぼ確実にヒット率に問題があります。アフターサポートでは、「キャッシュが有効になっているか」だけでなく、「どれだけヒットしているか、何がヒットしていないか、なぜヒットしていないか」を確認しましょう。

オリジンサーバーへのリクエストが遅いと、ノードの問題よりも体感に大きく影響する

　　初回のページ表示は遅いのに、更新すると速くなることがあります。これはブラウザーの不思議な挙動ではなく、通常はオリジンサーバーへのリクエストに時間がかかっているためです。CDN ノードにコンテンツがキャッシュされていなければ、オリジンサーバーから取得する必要があります。オリジンサーバーの処理が遅い、出口帯域幅が逼迫している、地域をまたぐリクエストの距離が遠いといった状況では、初回アクセスが明らかに遅くなります。

　　このタイプの問題は、次の順番で確認することをおすすめします：

　　オリジンサーバーの構成には問題がなくても、コンテンツ管理、資料ダウンロード、レポートページに大容量ファイルが多数配置されていると、オリジンサーバーへの負荷が突然高くなることがあります。たとえば、資料センターに電力網企業の納税計画問題に関する研究のようなドキュメントページを設置している場合、ファイル本体が大きく、キャッシュ時間も短いと、オリジンサーバーの処理速度が大きく低下しやすくなります。このような場合は、ダウンロードリソース専用のキャッシュ戦略を設定し、通常のページと混在させないようにする必要があります。

設定に問題がなくても、リソース自体が重すぎることがある

　　CDN が解決するのは転送効率であり、フロントエンド最適化の代替ではありません。ページが遅いとき、多くの保守担当者はまずサービス経路を調べますが、最終的にはページ自体に問題があることがよくあります。ファーストビューの大きな画像が圧縮されていない、スライド画像が多すぎる、スクリプトが過剰に読み込まれている、サードパーティーコードを読み込みすぎている、といった問題です。

　　リソース量が多すぎると、ノードの応答が速くても、ブラウザーはダウンロード、解析、実行に時間を要します。その結果、ユーザーが感じる速度は依然として遅いままです。この段階で確認すべきなのは CDN の管理画面ではなく、ページのリクエストウォーターフォールです。どのリソースが最も大きいのか、どれが最も遅いのか、どれがレンダリングをブロックしているのか、どれが重複して読み込まれているのかを確認します。特にマーケティングサイトや多言語サイトでは、言語ごとのテンプレートに同じスクリプトを重複して追加していることがあり、見つけにくい問題になりがちです。

HTTPS、リダイレクト、プロトコルの細部もファーストビューを遅くする

　　ユーザーが言う「表示が遅い」は、ページの内容が表示される前に発生していることがよくあります。たとえば、HTTP から HTTPS へのリダイレクト、裸ドメインから www へのリダイレクト、旧パスから新パスへのリダイレクトなど、複数のリダイレクトが重なると、所要時間が増加します。

　　また、証明書チェーンが長い、ハンドシェイク失敗後に再試行する、プロトコルネゴシエーションが不安定であるといった状況でも、TTFB が遅れます。保守時には、ブラウザーの開発者ツールや速度測定結果に表示されるリダイレクトチェーンを直接確認できます。トップページのリクエストが業務コンテンツに到達する前に2～3回もリダイレクトされている場合、これは小さな問題ではありません。できるだけ1回で完了するように整理すべきです。

CDN の問題と誤認されやすい動的 API も見落とさない

　　バックエンド担当者の中には、サイト全体が CDN 経由になっていれば API も速くなるはずだと考える人がいます。しかし、ログイン状態を扱う API、リアルタイム見積もり、在庫情報、フォーム送信などの動的リクエストは、キャッシュに適していないことが多くあります。これらが遅い場合、根本原因の多くはアプリケーション層、データベース、API の集約ロジック、またはサードパーティーサービスの呼び出しにあります。

　　判断方法は簡単です。静的リソースはすぐに表示されるのに API の待ち時間が長く、特にサーバーの応答を待つ時間が明らかに長い場合は、ノードの問題にこだわり続けるべきではありません。まず API の応答時間、スロークエリ、アプリケーションログを確認し、そのうえでエッジキャッシュ、API の分割、または縮退処理を行うかどうかを判断します。

ピーク時に遅くなる場合は、通常トラフィック構成と合わせて確認する

　　通常は正常なのに、広告を出稿したりキャンペーンを開始したりすると遅くなるサイトがあります。このタイプの問題は、帯域幅の数値だけでなく、トラフィックに大量の未キャッシュリソースへのリクエスト、悪意のあるクローリング、人気ファイルへのアクセス集中、または短時間に複数地域のユーザーが同時にアクセスするといった状況が発生していないかも確認する必要があります。

　　ピーク時に CDN のヒット率が明らかに低下する場合、リクエスト構成が変化したことを示しています。オリジンサーバーへのリクエスト帯域幅が上限に達している場合は、キャッシュとオリジンサーバーの負荷対策を調整する必要があります。特定のダウンロードページだけが遅い場合は、ドメインやキャッシュルールを個別に分ける必要があるかもしれません。電力網企業の納税計画問題に関する研究のようなコンテンツを掲載したリソースページは、アクセスピークとキャッシュ状況を個別に監視するのが適しており、通常ページの平均値に混ぜて確認してはいけません。

アフターサポート担当者向けの実践的な調査手順

　　実際に問い合わせに対応する際は、次の順番で進めることができます：

1. まず再現条件を収集する：地域、通信事業者、時間帯、ページの種類、初回アクセスだけが遅いかどうか。
2. 速度測定の経路を確認し、DNS、接続確立、TLS、TTFB、ダウンロード時間に分解する。
3. CDN のヒット率とオリジンサーバーへのリクエスト比率を照合し、ヒットしていないリソースの種類を特定する。
4. オリジンサーバーを直接測定し、応答、帯域幅、同時実行数、安全対策のいずれかがボトルネックになっていないかを確認する。
5. リダイレクト、証明書、プロトコル設定を確認し、不要なリダイレクトを減らす。
6. ページ層に戻り、大きな画像、スクリプト、サードパーティーリソース、レンダリングをブロックする読み込みを処理する。

　　このように調査すれば、「CDN を導入したのに遅い」という問題の大部分を切り分けることができます。経験上、まずヒット率とオリジンサーバーへのリクエストを改善し、その後にページリソースを処理するほうが、通常は効果が大きくなります。地域をまたぐアクセスや海外回線が複雑なサイトの場合は、測定地点を対象市場に分散させ、単一のネットワーク環境で実際のユーザー体験を代替しないようにしましょう。アフターサポートにおいて、cdn速度の問題で最も避けるべきなのは、十分な確認なしに対策を変更することです。最も効果的なのは、経路を区間ごとに調査し、遅い箇所に対して最適化を行うことです。