ホームページがいつまでも読み込み中のままで、更新すると急に速くなる。テキストは表示されたのに画像だけがなかなか表示されない。オフィスからは正常にアクセスできるのに、モバイル回線を使っているユーザーは長時間待たされる。これらはいずれも「Webサイトが遅い」と感じる状況ですが、原因がある場所はそれぞれ異なる可能性があります。

Webサイトの表示が遅い場合は、まずDNS名前解決と接続確立を確認し、次に最初の1バイトが返るまでの待ち時間を確認します。その後、画像、スクリプト、API、ブラウザでのレンダリングを調べます。 どの段階に時間が集中しているかを把握することで、最適化すべき対象がネットワーク経路なのか、オリジンサーバーなのか、キャッシュなのか、フロントエンドコードなのかを判断できます。

CDN07では、設定を変更する前に、まず1回分のアクセスを最初から最後まで記録することを推奨しています。すでにCDNを利用している場合でも、実際のリクエスト経路に沿って調査する必要があります。

Webサイトのどこが遅いのか、まず現象から調査範囲を絞る

「トップページの表示に5秒かかった」とだけ記録するのは十分ではありません。同じ合計時間でも、背後にある原因は異なる可能性があります。

この表は調査の入口を決めるためのものであり、診断そのものに代わるものではありません。画面が真っ白になる現象は、HTMLが返される前に発生することもあれば、リソースのダウンロード完了後に発生することもあります。

調査を始める前に、具体的なURL、発生時刻、地域、通信キャリア、デバイス、ログイン状態を記録してください。同じ条件で何度かテストし、最も速かった結果だけではなく、失敗した結果や遅かった結果も残します。

商品ページだけが遅く、トップページや静的ファイルは正常である場合、「すべてのページが遅い」ケースとは調査範囲が異なります。まず影響を受けているリクエストを特定し、その後の調査に明確な方向性を持たせます。

DNS、接続、最初の1バイトまでの時間を記録する方法

ブラウザの開発者ツールでは、1つのリクエストを複数の段階に分けて確認できます。まず、以下の概念を区別しておきましょう。

これらの段階を単純に合計すれば、ページ全体の表示時間になるわけではありません。画像、スクリプト、APIは並行してリクエストされることがあり、一部の接続は再利用されます。ページがいつ表示されるかは、重要なリソースとその依存関係によって決まります。

Chromeを例にすると、次の手順で記録できます。

1. 開発者ツールを開き、Network（ネットワーク） パネルに移動します。
2. No throttling（スロットリングなし） が選択されていることを確認し、意図せず低速ネットワークのシミュレーション設定が残っていないようにします。
3. リダイレクトチェーンを確認する場合は、Preserve log（ログを保持） を有効にしてからページを更新します。
4. タイプが Document/Doc のメインドキュメントを見つけ、Timing（タイミング） を開きます。
5. DNS、接続、Waiting (TTFB)、Content Downloadを記録し、その後、ファーストビューに影響する他のリクエストを確認します。

ブラウザキャッシュの影響を比較する場合は、Disable cache（キャッシュを無効化） を有効にして、もう一度テストできます。ただし、これはCDNキャッシュを消去することとは異なり、DNSや接続状態がすべてリセットされるわけでもありません。WebサイトがService Workerを使用している場合は、レスポンスがこのブラウザ側のプログラムから提供されていないかも確認してください。Chrome Networkの操作と各タイミングの説明

DNS名前解決が遅い場合、何を確認すべきか

DNS名前解決が遅いということは、クライアントが接続を開始する前にすでに時間を消費している可能性があります。まず、遅いのがメインサイトのドメインなのか、それとも画像、フォント、アクセス解析などに使われている別のドメインなのかを確認します。

次に、ドメイン管理画面のレコードを確認します。サイトを最近移行していないか、CNAMEが現在の接続先を指しているか、AレコードとAAAAレコードが現在のデプロイ構成と一致しているかを確認してください。AレコードはIPv4アドレス、AAAAレコードはIPv6アドレスに対応するため、それぞれ個別に確認する必要があります。

nslookupがインストールされているWindows、macOS、Linux環境では、サンプルドメインのレコードを次のように確認できます。

nslookup -type=A example.com
nslookup -type=AAAA example.com

example.com を自分のドメインに置き換えてください。これらのクエリはDNS設定を変更せず、このコマンドで使用されるDNSサービスから返された結果を表示するだけです。そのため、セキュアDNSを使用しているブラウザの結果とは異なる場合があります。パラメータの使い方については、BINDのnslookupドキュメントを参照してください。

結果を見る際は、DNSサーバー自身のアドレスと、ドメイン名の問い合わせ結果を区別してください。AまたはAAAAレコードが取得できたことは、その問い合わせでアドレスが返されたことを示すだけであり、Webサイトが正しくCDNに接続されていることを単独で証明するものではありません。タイムアウトや名前解決エラーが発生した場合も、ドメイン名の綴り、DNSサービス、権威DNSレコードを確認する必要があります。

地域によって異なるIPアドレスが返されても、必ずしも異常ではありません。CDNのトラフィック制御によって異なる結果になることがあります。逆に、同じIPアドレスが表示されたとしても、すべてのユーザーが同じネットワーク経路を利用していることを意味するわけではありません。

特定のネットワークだけでDNS名前解決が繰り返し遅い場合は、まずその環境の問い合わせ結果を保存して比較してください。複数のネットワークで異常が発生している場合は、権威DNSサービスとレコードの経路を確認します。「DNS問い合わせを1回減らす」ことだけを目的に、サービスプロバイダーが要求しているCNAMEを削除しないでください。

ブラウザに独立したDNS時間が表示されない場合、キャッシュや接続の再利用が関係している可能性があります。これは、初回アクセスにDNSルックアップのコストがなかったことを意味するものではありません。

接続確立が遅いからといって、サーバー設定に問題があるとは限らない

DNS名前解決が完了した後も、クライアントは接続を確立する必要があります。一般的な新規HTTP/1.1またはHTTP/2 HTTPS接続では、TCP接続とTLSハンドシェイクが行われます。HTTP/3ではQUICが使用されるため、同じTCPベースの内訳をそのまま適用することはできません。

接続フェーズが長い場合は、リモートアドレス、プロトコル、ユーザーのネットワーク、発生した時間帯を記録し、再試行、パケットロス、輻輳、接続数制限、TLS設定などの問題がないかを確認します。

ここでは、見落としやすい3つの違いがあります。

ブラウザからCDNエッジへの接続と、CDNからオリジンサーバーへの接続は同じではありません。 オリジンサーバーとは、実際にコンテンツを保存したりアプリケーションを実行したりするバックエンドシステムです。CDNを導入した後、ブラウザ側の記録で直接確認できるのは通常、エッジノードまでの経路です。反対側のオリジンへの接続やオリジンフェッチについては、サーバー側の情報を組み合わせて判断する必要があります。

Pingが測定しているのは別の種類の通信です。 Pingでは、HTTPSハンドシェイク、アプリケーションのキュー待ち、データベースクエリ、リソースのダウンロード、スクリプトの実行などは確認できません。そのため、Ping値が低いからといってページが高速に表示されるとは限りません。

入口でのリダイレクトにも時間がかかります。 HTTPからHTTPSへリダイレクトし、その後、ルートドメインからwwwへ、さらに言語別ページへリダイレクトすると、最終的なHTMLが返されるまでに複数のレスポンスが発生する場合があります。それぞれのリダイレクトが本当に必要かを確認し、サイト内リンクは正しい最終URLを直接指定するようにしてください。

特定の通信キャリアやピーク時間帯だけ大幅に遅くなる場合は、昼間の固定回線と夜間のモバイル回線の結果を単純に比較するのではなく、近い時間帯に同じURLを比較してください。地域をまたぐサービスでは、中国大陸ユーザーから海外Webサイトへアクセスする際の最適化方法も参考にしながら、異なるネットワーク間で比較テストを行うことができます。

TTFBが高い場合、ネットワークとオリジンサーバーの問題をどう切り分けるか

TTFBはTime to First Byteの略で、レスポンスの最初の1バイトが到着し始めるまでの待ち時間を示す指標です。ただし、ツールによって計測開始時点が異なる場合があります。

ページナビゲーションのTTFBには、最初の1バイトが届く前のDNS名前解決や接続などが含まれる場合があります。一方、Chrome NetworkのWaiting (TTFB)は、リクエスト送信後の待ち時間を示し、ネットワークの往復時間も含みます。2つの値を比較する前に、同じ計測定義であることを確認してください。web.devによるTTFBの定義

そのため、TTFBが1秒だったとしても、サーバーがアプリケーションコードの実行に1秒かかったと直接判断することはできません。CDNを経由するリクエストでは、この時間にエッジでの処理、オリジンへのフェッチ、中間プロキシなどが含まれる場合もあります。

公開静的ファイルと動的リクエストを比較する

同じ時間帯に、アプリケーションページと小さな公開静的ファイルを比較してください。

静的ファイルは高速なのに、特定のAPIだけが繰り返し長時間待たされる場合は、そのAPIのアプリケーション処理、データベースクエリ、外部サービスへの呼び出し、キュー待ちを優先して確認します。ただし、両者でキャッシュやバックエンド経路が異なる可能性があるため、最終的にはログによる確認が必要です。

複数の種類のリクエストが遅い場合は、それらが共通して通過するネットワーク、プロキシ、オリジンサーバーのリソースを確認します。トップページだけをテストして、システム全体の問題だと判断しないでください。

CDN導入後、リクエストが実際にキャッシュから配信されているか確認する

CDNは、キャッシュ可能なレスポンスを配信ノードに保存できます。キャッシュヒットが発生すれば、一部のリクエストは再びオリジンサーバーへアクセスする必要がありません。一方、キャッシュミスや再検証が必要な場合は、オリジンへのフェッチが発生することがあります。基本的な仕組みについては、CDNキャッシュとコンテンツ配信の仕組みを参照してください。

遅いリクエストについて、リクエスト経路、キャッシュルール、レスポンスヘッダー、ログを確認します。キャッシュ状態を示すフィールドは製品ごとに異なるため、具体的な意味については各プロバイダーのドキュメントを確認してください。一般的なレスポンスヘッダーが見当たらないからといって、それだけでキャッシュされていないと判断することはできません。

公開リソースと個人データは分けて扱う必要があります。ログイン状態、ショッピングカート、アカウント情報などについて、TTFBを短縮するためだけにサイト全体の共有キャッシュを有効にしてはいけません。キャッシュルールは認証状態とレスポンス内容の境界を考慮して設定してください。HTTPキャッシュと共有キャッシュの解説

リクエストIDでブラウザとサーバー側の記録を対応付ける

可能であれば、リクエストIDを使ってエッジ、Webサーバー、アプリケーションのログを関連付けます。共通のIDがない場合でも、少なくとも時刻、パス、ステータスコードを一致させて確認します。

ブラウザでは長時間待っているのに、アプリケーション側の処理時間が短い場合は、アプリケーションログだけでは確認できない別の要因を調査する必要があります。アプリケーション側の記録自体が遅い場合は、データベース、外部API、計算処理などをさらに調べます。

オリジンサーバーの負荷が異常に高い場合は、アプリケーションリクエストが想定していたCDNの入口を迂回していないかも確認してください。CDNを導入していても直接アクセス可能な経路が残っている場合は、オリジンIPアドレスの露出とアクセス保護を調査する方法も確認できます。負荷が上昇しただけで攻撃が発生したと判断しないでください。

HTMLは高速なのに、なぜ画像やページ全体は遅く感じるのか

HTMLが高速に返されたということは、メインドキュメントのリクエストが良好に処理されたことを示すだけです。ファーストビューでは、画像、CSS、JavaScript、アプリケーションAPIなどをまだ待っている可能性があります。

重要なリソースを確認するときは、まず2つの時間を見ます。リクエストがいつ開始されたのか、そして開始後に完了までどのくらいかかったのか。

ファーストビューの画像のダウンロード開始が非常に遅い場合、リソースの検出や依存関係に問題がある可能性があります。たとえば、JavaScriptの実行後に画像がページへ挿入される場合、画像サイズを小さくして改善できるのはダウンロード部分だけであり、それ以前の待ち時間は解消できません。

ファーストビューの主要コンテンツが大きな画像である場合は、ブラウザがその画像を十分早く発見できるかを確認してください。画面外の画像向けの遅延読み込みをそのまま適用しないよう注意が必要です。LCP（Largest Contentful Paint）は、ビューポート内の主要コンテンツがいつ表示されたかを確認するのに役立ちますが、それですべての機能が利用可能になったことを意味するわけではありません。ファーストビューのリソースとLCPを最適化する方法

リソースのダウンロード開始は早いのに、その後のダウンロードに長時間かかる場合は、次の点を確認します。

• 画像の解像度と形式が、実際の表示サイズに適しているか。
• テキストリソースが適切な圧縮方式を使用しているか。
• ファーストビューではまだ必要としていない大量のファイルを一度に読み込んでいないか。
• リソース用ドメインが想定どおりのCDNとキャッシュ設定を使用しているか。

リソースのダウンロードが完了した後もページの動作が重い場合は、Performanceパネルでスクリプトとレンダリングを確認します。JavaScriptが長時間ブラウザのメインスレッドを占有すると、ファイル転送が高速になっていても、ユーザーがコンテンツをすぐに見られなかったり、ページを操作できなかったりする場合があります。

サードパーティ製のフォント、アクセス解析、カスタマーサポート用スクリプトも個別に確認してください。メインサイトをCDNに接続したからといって、これらの独立したドメインまで自動的に最適化されるわけではありません。

curlで再確認し、同じリクエストのどこで時間がかかっているのかを確認する

ブラウザはページ全体の依存関係を確認するのに適しており、curlは特定のURLを再確認するのに適しています。以下のコマンドは、LinuxまたはmacOSの一般的なShell環境で使用でき、通常のGETリクエストをテストします。

curl -sS -o /dev/null \
  --connect-timeout 10 --max-time 30 \
  -w 'status=%{http_code}\ndns=%{time_namelookup}\nconnect=%{time_connect}\ntls=%{time_appconnect}\nready=%{time_pretransfer}\nfirst_byte=%{time_starttransfer}\ntotal=%{time_total}\n' \
  'https://www.example.com/'

URLを自分のページに置き換えてください。-o /dev/null はダウンロードしたコンテンツを破棄し、-sS は進捗表示を非表示にしながらエラーメッセージを保持します。2つのタイムアウトパラメータは、それぞれ接続フェーズと処理全体の待ち時間を制限します。Windowsでは、対応するcurl.exe、出力先、Shellの改行構文を使用する必要があり、この複数行コマンドをそのままコピーして使用することはできません。

出力される時間の単位は秒です。ここでのdns、connect、tlsなどの名前は読みやすくするためのラベルであり、波括弧内のcurlフィールドに対応しています。これらは多くの場合、処理開始時点から計測される累積時間であり、互いに足し合わせることはできません。curl公式タイミングフィールドのドキュメント

以下は説明用のサンプルであり、CDN07の顧客環境で実測した値ではありません。

103などの暫定レスポンスがなく、新規接続、プロキシなし、リダイレクトなしの通常のHTTP/1.1またはHTTP/2 HTTPSリクエストを想定すると、隣接するタイムスタンプから次のように判断できます。TCP接続は約0.08秒、TLSハンドシェイクは約0.13秒、転送準備完了から最初の1バイトまでが約1.20秒、最初の1バイト以降が約0.08秒です。

このデータから、次に優先して確認すべきなのは、リクエスト送信後のネットワーク、プロキシ、オリジンへのフェッチ、アプリケーション処理であることが分かります。ただし、この1.20秒をそのままサーバーの実行時間とみなすことはできません。

ステータスコードも必ず併せて確認してください。200だからといって、返された内容が想定しているページであるとは限りません。301または302の場合はリダイレクトを確認する必要があり、このコマンドはリダイレクトを自動的には追跡しません。403、502、504の場合は、該当するアクセスエラーまたは上流側の異常を先に対処します。失敗やタイムアウトが発生した場合、不完全なタイミング情報を正常なサンプルとして扱わないでください。

curlはページ内の画像を引き続きダウンロードすることも、JavaScriptを実行することもありません。そのため、curlで高速だったからといって、ページ全体が高速であるとは限りません。

テスト条件が変わっただけではなく、本当に最適化できたかを確認する方法

設定を変更した後は、同じURL、ログイン状態、同程度のネットワーク条件で再テストしてください。ブラウザキャッシュが有効かどうかも明確にし、レスポンスのステータスと内容も引き続き確認します。

以前遅かった段階を重点的に比較します。DNSの時間が短くなったか、最初の1バイトまでの待ち時間が改善したか、重要な画像の読み込み開始が早くなったかを確認してください。合計時間の短縮だけを見るのは避けます。変化がブラウザキャッシュや一時的なネットワーク変動による可能性があるためです。

地域差が大きいWebサイトでは、主要ユーザーが利用しているネットワークを少なくともカバーしてください。モバイル端末の問題については、実際のスマートフォンで再現テストを行います。デスクトップブラウザでの低速ネットワークシミュレーションは条件を統制するのに役立ちますが、特定の通信キャリアが実際に利用する経路や、実際のスマートフォン性能を完全に再現するものではありません。

技術サポートへ問題を引き継ぐ場合は、URL、発生時刻、地域と通信キャリア、ブラウザとデバイス情報、Timingのスクリーンショット、リクエストIDを準備してください。HARファイルやログをエクスポートした後も、トークンや個人情報などの機密情報を確認して削除する必要があります。ツールのデフォルトのマスキングだけに頼らないでください。

よくある質問（FAQ）

Webサイトは初回アクセスが遅く、2回目は速くなります。なぜですか？

ブラウザキャッシュ、CDNキャッシュ、DNSキャッシュ、接続の再利用、アプリケーションのウォームアップなどが関係している可能性があります。2回のリクエストが実際に送信されたか、レスポンスがどこから返されたか、どの段階の時間が短縮されたかを比較することで、原因を切り分けられます。再アクセスで速くなったというだけで、CDN設定が正しいと判断することはできません。

TTFBが1秒を超えたら、サーバーの性能が不足しているのでしょうか？

必ずしもそうではありません。まず計測の定義を確認し、そのうえでネットワーク、プロキシ、オリジンへのフェッチ、アプリケーションログを確認します。アプリケーション処理が短いのであれば、サーバーをアップグレードしても主要なボトルネックが改善しない可能性があります。遅いクエリやキュー待ちが明確であれば、バックエンド処理を対象に改善する必要があります。

Pingは低いのにWebページの表示が遅いのは正常ですか？

そのような組み合わせは起こり得ます。両者は異なる対象を測定しているためです。HTTPSリクエスト、最初の1バイトまでの時間、リソースサイズ、スクリプト実行を引き続き確認してください。Ping値が低くても、これらの段階に問題がないとは限りません。

CDNを導入してもWebサイトが遅い場合、サービスプロバイダーを変更すべきですか？

まず、遅いリクエストが本当にCDNを経由しているか、キャッシュに適しているか、オリジンへのフェッチが遅くなっていないか、フロントエンドの処理がページ表示をブロックしていないかを確認してください。問題が特定の配信ノードやネットワーク経路に継続的に集中し、同一条件で比較した証拠がある場合にのみ、他の選択肢との比較を進めるのが適切です。

Webサイトが一部の地域だけ遅い場合、原因をどう確認できますか？

近い時間帯に同じURLを使って異なるネットワークを比較し、名前解決結果、リモートアドレス、ステータスコード、各段階の所要時間を記録します。また、IPv4とIPv6のどちらが使用されているかも確認してください。別地域から1回測定しただけでは長期的な原因を特定できません。また、地域差だけを根拠にアクセスがブロックされていると判断することもできません。

キャッシュを削除すれば、Webサイトはずっと速くなりますか？

いいえ。ブラウザキャッシュを削除すると、次回アクセス時にファイルを再度ダウンロードすることになる可能性があります。CDNキャッシュを削除すると、オリジンへのアクセスが増える場合もあります。キャッシュ内容や状態に異常があると疑われる場合にのみ、必要な範囲を対象として処理し、その結果を確認してください。

Webサイトの高速化は、どこから始めればよいですか？

トラブルシューティングでは、次の4点を覚えておいてください。

• まず具体的なリクエストと、どの段階に時間がかかっているかを特定してから、変更すべき対象を決めます。
• 最初の1バイトまでの時間が長い場合は、ネットワークとサーバー側の証拠を組み合わせて判断し、直接サーバーの問題だと決めつけないでください。
• HTMLが高速に返された後も、重要なリソースとブラウザでのレンダリングを確認します。
• CDN導入後の効果は、同じ条件で検証し、1回だけの速度テストを根拠に判断しないでください。

次のステップとして、まずNetworkパネルを開き、遅いリクエストのTiming記録を1件保存してから、curlで同じURLを再確認してください。問題がオリジンサーバー側の処理に集中している場合はアプリケーションログを調査し、コンテンツ配信や地域をまたぐアクセスに集中している場合は、CDN07のDDoS保護CDNサービスの導入方法も確認し、実際のリクエスト経路に基づいて設定と最適化の方向性を評価してください。