CDNアクセラレーションを有効にしてもサイトが遅い場合、まず何を確認すべきですか？

CDNアクセラレーションを有効にした後も、ユーザーから「トップページの表示が遅い」「商品画像がなかなか表示されない」「管理画面が時々タイムアウトする」といった声が寄せられると、多くの保守担当者はすぐにノードのカバレッジ不足やCDN事業者の性能不足を疑います。実際の調査では、CDNは静的リソースをより近くから配信するにすぎず、オリジンサーバーのプログラム遅延、キャッシュルールの無効化、ドメイン解決の迂回、またはサードパーティースクリプトによるファーストビュー表示の遅延を自動的に解決できるわけではありません。

特に海外市場向けの多言語コーポレートサイト、B2B問い合わせサイト、越境ECモールでは、訪問者が北米、欧州、東南アジアなど異なる地域に分布しています。同じページが北京でのテストでは正常でも、米国のモバイルネットワークで高速とは限りません。保守対応では、まず「サイトが遅い」という問題を検証可能な経路に分解するほうが、CDNプランを何度も切り替えるよりも通常は効果的です。

まず遅い箇所を確認する：ページが遅いことは、必ずしもCDNが遅いことを意味しない

まず実際のアクセス時のブラウザウォーターフォールを保存し、DNSルックアップ、最初の1バイトが返るまでの時間（TTFB）、主要リソースのダウンロード時間という3つの時点を重点的に確認することをおすすめします。HTMLドキュメント自体の待機時間が長く、その後の画像、CSS、JSのダウンロード速度が正常であれば、問題はエッジノードではなく、オリジンサーバー、アプリケーション、またはデータベースにある可能性が高いです。逆に、ドキュメントの応答は速いものの、大きな画像、フォント、スクリプトのダウンロードが待ち行列に入る場合は、キャッシュ戦略、リソースサイズ、同時読み込みを重点的に確認すべきです。

よくある誤解として、ページのステータスが「CDN接続済み」と表示されると、すべてのコンテンツが高速化されていると考えてしまうことがあります。実際には、動的API、パラメータ付きの画像リンク、管理画面のパス、一部のダウンロードファイルは、ルール設定によりオリジンサーバーへ戻る場合があります。保守担当者は、ヒット、ミス、キャッシュバイパスなど、レスポンスヘッダー内のキャッシュ状態を直接確認すべきです。項目はサービス事業者により異なりますが、重要なのは、リクエストが実際にエッジノードから応答されているのか、それとも毎回オリジンサーバーへ戻っているのかを確認することです。

オリジンサーバーの応答を最優先にし、「接続済み」という表示に惑わされない

オリジンサーバーの遅延には、通常いくつかの現れ方があります。アクセスピーク時にTTFBが明らかに上昇する、同じページでも初回アクセスは遅く更新後はやや速くなる、管理画面でコンテンツを公開した後にフロントエンドで短時間に頻繁なタイムアウトが発生する、APIリクエストが長時間待機状態のままになる、といったものです。その背景には、サーバーのCPU、メモリ、接続数の逼迫がある場合もあれば、CMSプラグイン、テンプレートクエリ、検索API、データベースインデックスの不適切さによる遅延がある場合もあります。

マーケティングサイトでは、トップページは下層ページより問題が起きやすい傾向があります。スライドバナー、おすすめ商品、フォーム検証、ポップアップツール、分析コードがすべてトップページに集中するためです。アクセスのたびに複数のデータベースモジュールをリアルタイムで読み込む場合、CSSと画像がすべてCDNにヒットしていても、ユーザーがファーストビューを見るまでの時間は依然として理想的ではありません。この場合、まずキャッシュ範囲を広げるのではなく、オリジンサーバーのログ、アプリケーションパフォーマンス監視、またはデータベースのスロークエリから証拠を探すべきです。

「サイト全体を強制キャッシュする」対応には特に慎重になる必要があります。商品価格、在庫、ログイン状態、ショッピングカート、問い合わせフォームのトークンなどは、通常、静的ページとして単純にキャッシュできません。より安全な方法は、公開ページ、動的API、管理画面パスを区別することです。公開され更新頻度の低いコンテンツには適切なキャッシュ期間を設定し、パーソナライズされたAPIは明示的にキャッシュをバイパスし、キャッシュ可能なページにはバージョン番号または能動的な更新メカニズムを採用して、改修後もユーザーに古いコンテンツが表示され続けることを防ぎます。

キャッシュヒット率が低い場合、多くはルールとリソース管理に問題がある

多くのサイトでは静的リソースのファイル名が長期間変わらず、バナー画像を更新しても banner.jpg のままです。ユーザーに古い画像を見せないために、保守担当者はキャッシュ時間を短く設定せざるを得ません。この方法は手軽ですが、CDNキャッシュが頻繁に失効します。より適した方法は、更新後のリソースにバージョンパラメータを追加するか、コンテンツフィンガープリント付きのファイル名を使用することです。これにより、ブラウザとエッジノードは旧バージョンを安心してキャッシュでき、新バージョンも適時に反映されます。

もう一つ見落とされやすい点はクエリパラメータです。一部のシステムでは、画像やスクリプトにタイムスタンプ、言語パラメータ、トラッキングパラメータが自動的に付加されます。CDNが各パラメータの組み合わせを新しいURLとして扱うと、キャッシュが細かく分断されます。一方で、すべてのパラメータを無造作に無視すると、商品絞り込み、画像処理、セキュリティ検証に影響する可能性があります。調査時には、実際のリクエストで出現頻度が最も高いパラメータを列挙し、リソースタイプごとに保持、無視、正規化のルールを策定すべきです。

画像も「CDNに置く」だけで終わりではありません。圧縮されていない商品原画像、ファーストビューでの自動再生動画、一度に数十枚読み込む詳細ページ画像は、いずれも帯域幅とメインスレッドを占有します。表示用画像については、デバイスサイズに合わせた適切な仕様を出力できます。ファーストビュー以外の画像は遅延読み込みでき、動画はサムネイル画像とユーザー操作による再生のほうが適しています。ここでの判断は非常に現実的です。デザインチームは鮮明さを求め、マーケティングチームは情報の完全性を求め、保守側は許容可能なファイルサイズと読み込み順序を提示する必要があり、ただ画質が損なわれるまで圧縮すればよいわけではありません。

DNS解決とドメイン設定は、地域をまたぐアクセスの見えにくい落とし穴になりがち

CDNノードがいくら多くても、前提はユーザーが正しく振り分けられることです。ドメインのCNAMEが完全に有効化されていない、DNSレコードが競合している、AレコードとCDNレコードが同時に残っている、IPv6設定が一致していない、といった問題は、一部のユーザーがCDNを迂回してオリジンサーバーへ直接接続する原因となります。典型的な現象は、ある地域では非常に速い一方、別の地域では継続的に遅い、社内ネットワークでは正常だが顧客のモバイルネットワークでは頻繁に失敗する、といったものです。

保守時には、ローカルで一度だけ名前解決を実行して結論を出してはいけません。対象市場のネットワーク環境からドメインの最終的な名前解決結果を確認し、www、ルートドメイン、モバイル端末用サブドメイン、画像ドメイン、ダウンロードドメインをそれぞれ検証すべきです。HTTPS証明書チェーンとリダイレクト回数もあわせて確認する必要があります。ページが http から https へ、さらにルートドメインから www へ、その後言語ディレクトリへリダイレクトされる場合、ユーザーは実際にコンテンツを取得する前にすでに何度も往復しています。

サイトが中国本土と海外のユーザーの両方にサービスを提供している場合は、デプロイ状況とコンプライアンス状況も確認する必要があります。中国国内向けのサイトでは、接続、サーバー移行、主体変更を行う際、ICP届出情報と実際のサービス設定を一致させる必要があります。新規ICP届出、変更、接続移管などの手続きに関わる場合は、事前に中国国内ICP届出サービス番号を通じて書類と手続きの連携を確認し、ドメイン、主体、接続情報の不一致によって公開時期が受動的に遅れることを避けられます。

サードパーティーリソースによるファーストビューの遅延は、マーケティングサイトで頻発する問題

広告ピクセル、オンラインチャット、地図、CAPTCHA、SNS埋め込み、行動分析、A/Bテストツールは、通常、自社CDNの制御範囲にはありません。外部スクリプトの応答が遅いと、後続のレンダリングをブロックする場合があります。複数のタグマネージャーが重複して読み込まれると、問題はさらに増幅されます。遅いリクエストのドメインが自社サイトに属さない場合、責任をすべてCDN設定に帰すべきではありません。

対応原則は、リード獲得とアトリビューションに実際に関わるスクリプトを残し、過去から残るコードを整理することです。ファーストビューの表示に影響しないツールは後から読み込めます。地域によってアクセスが制限される、または時折失敗するサードパーティーサービスには、代替手段を用意する必要があります。特に貿易向けサイトでは、中国国内でよく使われるコンポーネントをそのまま海外サイトに移植することに注意が必要です。海外ユーザーのアクセス経路はより長く、外部での一度の待機でも、フォーム送信前のユーザーの忍耐力に直接影響する可能性があります。

同じ手順で調査し、効果のない変更を避ける

実際のチケット対応では、「ページドキュメント—キャッシュ状態—DNS振り分け—リソースウォーターフォール—オリジンサーバーログ」の順序で進められます。まずHTMLが遅いかを確認し、次に静的リソースがヒットしているかを判断します。アクセスが実際にCDNへ到達していることを確認してから、プログラム、データベース、サードパーティーサービスをあらためて確認します。変更を1つ完了するたびに、同じ地域、同じネットワーク条件で再テストすべきです。そうしなければ、ネットワークの変動を最適化の効果と誤認しやすくなります。

易営宝は、多言語サイト構築、越境ECモール、海外プロモーションの場面に長年対応する中で、通常、サイトパフォーマンスを広告ランディングページ、インデックス登録・クロール、フォームコンバージョンと同じ一連の経路として捉えています。CDNはその一部であり、万能な修正策ではありません。優先して解決すべきなのは、ログ、レスポンスヘッダー、実際のアクセス経路によって証明できるボトルネックです。この点を正確に特定してこそ、その後にオリジンサーバー、キャッシュルール、リソース戦略のいずれを調整する場合でも、手戻りを繰り返さずに済みます。