遅いウェブサイトのトラブルシューティング

このガイドでは、ウェブサイトのパフォーマンス問題を特定し、解決します。基本的な診断から始め、高度なトラブルシューティングへ進みます。

パフォーマンスを調べる前に、トラフィックが実際に Cloudflare を経由していることを確認してください。リクエストが Cloudflare を迂回している場合、問題は Cloudflare とは無関係であり、このガイドは役に立ちません。

Cloudflare 経由で返される応答には、必ず cf-ray ヘッダーが含まれます。このヘッダーを確認します。

curl -s -D- -o /dev/null https://www.example.com | grep -i cf-ray

(Invoke-WebRequest -Uri "https://www.example.com" -Method Head).Headers["cf-ray"]

cf-ray ヘッダー（例: cf-ray: 8a1b2c3d4e5f6g7h-SJC）があれば、トラフィックは Cloudflare を経由しています。ない場合は、DNS 設定を確認してください。

トラフィックをプロキシするには、ドメインが Cloudflare の IP アドレスに解決される必要があります。

dig +short www.example.com

Resolve-DnsName -Name www.example.com | Select-Object -ExpandProperty IPAddress

返される IP アドレスは Cloudflare の IP ↗ である必要があります。オリジンサーバーを直接指している場合、DNS レコードはプロキシされていません。

修正手順は次のとおりです。

1. Cloudflare ダッシュボード ↗ を開きます。
2. 遅いホスト名の DNS レコードを探します。
3. Proxy status が Proxied（オレンジの雲アイコン）になっていることを確認します。

パフォーマンス問題は、何が遅いかを特定できると解決しやすくなります。まず、次の情報を集めます。

1. 遅いリクエストを特定する - どの URL、アセット、API エンドポイントが遅いかを把握します。
2. 遅さを測る - 遅延を数値化します（例: 「この画像の読み込みに 5 秒かかる」）。
3. 問題を再現する - 遅さが一貫して起きており、一度限りでないことを確認します。

Observatory は、合成テストとリアルユーザーモニタリング（RUM）のデータを提供し、ウェブサイトのパフォーマンスを評価します。

RUM は特に重要です。メトリクスは実際の訪問者のブラウザーから取得されるため、サイトの体験を客観的に示します。ラボデータはデバッグに向くほど詳細ですが、実ユーザーが使うデバイスや接続性と常に一致するわけではありません。

1. Cloudflare ダッシュボードを開きます。

   Observatory を開く ↗

2. Observatory を選択します。

3. テストしたい URL を入力し、Run test を選択します。

Observatory は次の主要メトリクスを報告します。

リアルユーザーモニタリングでも似たメトリクスが報告されますが、Total Blocking Time (TBT) の代わりに Interaction to Next Paint (INP) が表示されます。

TBT はページ読み込み中だけを測ります。INP は、実訪問者がサイトで行うすべての操作を測ります。

Observatory の結果に基づき、関連する Speed の最適化 を有効にします。

• Brotli 圧縮 - 応答を圧縮し、転送を速くします
• Early Hints - 重要なリソースをプリロードします
• HTTP/2 と HTTP/3 - 多重化に対応した新しいプロトコルを使い、アセットごとに別接続を開くのではなく、1 本の接続で複数リクエストを送ります
• 画像最適化 - 画像を自動で最適化し、リサイズします
• Rocket Loader - JavaScript の読み込みを遅らせ、描画時間を改善します

Observatory と RUM のデータが特定の問題を示している場合は、ブラウザーの開発者ツールで個々のリソースを調べます。

1. ブラウザーの開発者ツールを開きます。
2. Network タブを開きます。
3. ページを再読み込みし、時間がかかっているリクエストを確認します。
4. Time または Duration で並べ替え、最も遅いアセットを特定します。
5. 遅いリソースの具体的な URL を控えます。

次の点を確認します。

• 大きな画像や動画
• 遅い API 呼び出し
• サードパーティスクリプト
• 描画を妨げるリソース

ウェブサイトが遅い場合、原因はオリジンサーバー側にあることがあります。Origin Analytics で、オリジンの動作を把握します。

Cloudflare ダッシュボードで次の操作を行います。

1. Speed > Origin Analytics を開きます。

   Origin Analytics を開く ↗

2. Origin Response Time のメトリクスを確認します。

3. 遅い応答のパターン（特定のパス、時間帯、地理的な地域）を探します。

オリジンの応答時間が長い場合、オリジンサーバーに負荷がかかっています。次を検討してください。

• ホスティングプランのアップグレード
• データベースクエリの最適化
• サーバー側キャッシュの導入

利用できるメトリクス、診断の流れ、オリジンのステータスコードの解釈は、Origin Analytics を参照してください。

ゾーンに Cloudflare Workers をデプロイしている場合、一致するリクエストごとに実行され、全体の応答時間に加算されます。遅い Worker は、TTFB が高くなるよくある原因です。

Workers がパフォーマンスに影響しているかを確認するには、次の手順を行います。

1. Cloudflare ダッシュボードで Workers & Pages を開きます。
2. ゾーンにデプロイされている Workers を確認します。
3. 各 Worker の Analytics で実行時間を確認します。
4. Workers を一時的に無効にし、遅さの原因かどうかを切り分けます。

Worker が遅い場合は、コードで次を確認します。

• 遅い外部 API 呼び出しや fetch() リクエスト
• 非効率なループやデータ処理
• await がなく、並列ではなく直列に実行されている箇所

特定リクエストの詳細なタイミングを知るには、コマンドラインツールでパフォーマンスを測ります。

curl -w "\n\nDNS Lookup: %{time_namelookup}s\nTCP Connect: %{time_connect}s\nTLS Handshake: %{time_appconnect}s\nTime to First Byte: %{time_starttransfer}s\nTotal Time: %{time_total}s\n" -o /dev/null -s https://www.example.com/slow-asset.jpg

$url = "https://www.example.com/slow-asset.jpg"
try {
    $timing = Measure-Command { 
        $response = Invoke-WebRequest -Uri $url -ErrorAction Stop
    }
    Write-Host "Total Time: $($timing.TotalSeconds)s"
    Write-Host "Status: $($response.StatusCode)"
} catch {
    if ($_.Exception.Response) {
        $statusCode = $_.Exception.Response.StatusCode.value__
        Write-Host "Error Status: $statusCode"
    }
    Write-Host "Error: $($_.Exception.Message)"
}

出力例（bash）:

DNS Lookup: 0.025s
TCP Connect: 0.045s
TLS Handshake: 0.120s
Time to First Byte: 0.350s
Total Time: 1.250s

curl のタイミング内訳は、次のとおりです。

地理的に異なる場所からテストするには、次のようなオンラインツールを使います。

• KeyCDN Tools ↗
• Uptrends ↗
• Dotcom-Tools ↗

キャッシュは、ウェブサイトのパフォーマンスを上げる最も効果的な方法の 1 つです。コンテンツがキャッシュされていると、Cloudflare は訪問者に近いデータセンターから直接配信し、オリジンサーバーへの往復をなくします。応答時間を数百ミリ秒から数ミリ秒まで下げられることがあります。

キャッシュされていないコンテンツは、訪問者から Cloudflare、さらにオリジンサーバーへと往復します。Cache Analytics でキャッシュの状況を把握し、さらにキャッシュできる箇所を見つけます。

特定アセットのキャッシュ状態を確認します。

curl -s -D- -o /dev/null https://www.example.com/asset.jpg | grep -i "cf-cache-status"

(Invoke-WebRequest -Uri "https://www.example.com/asset.jpg" -Method Head).Headers["cf-cache-status"]

取りうる値は次のとおりです。

一覧は Cloudflare のキャッシュ応答 を参照してください。

1. Cloudflare ダッシュボードを開きます。

   Overview を開く ↗

2. Cache Performance セクションを確認します。

3. Cache status equals MISS または DYNAMIC で絞り込み、キャッシュされていないコンテンツを特定します。

静的アセット（画像、CSS、JavaScript）のキャッシュステータスが DYNAMIC、BYPASS、MISS の場合は、原因を調べます。

デフォルトでは、Cloudflare は特定の ファイル拡張子 だけをキャッシュします。追加の静的コンテンツをキャッシュするには、次の手順を行います。

1. Caching > Cache Rules を開きます。
2. 特定のコンテンツをキャッシュ するルールを作成します。
3. 適切な Edge TTL を設定します。

Cache Rule が想定どおりに適用されない場合は、Cloudflare Trace でリクエストをシミュレートし、どのルールが一致するかを確認します。Trace は、特定 URL に対して Cloudflare の設定（Cache Rule、Page Rule、その他の設定を含む）がどう影響するかを示します。

特に次の場合に役立ちます。

• Cache Rule でキャッシュされるはずなのに、応答が DYNAMIC または BYPASS になる
• どのルールが優先されているか分からない
• 変更前に「もし〜なら」のシナリオを試したい

curl で TCP Connect や TLS Handshake の時間が長い場合、原因はアプリケーションではなくネットワーク側にあることがあります。

speed.cloudflare.com ↗ で次をテストします。

• ダウンロード速度とアップロード速度
• レイテンシ（ping）
• ジッター
• パケットロス

結果が悪い場合は、ローカルネットワークまたは ISP に問題があります。

MTR は traceroute と ping を組み合わせ、各ネットワークホップのレイテンシとパケットロスを示します。

mtr -rw www.example.com

次の点を確認します。

• 特定ホップの 高いレイテンシ（遅いネットワーク区間を示す）
• パケットロス（混雑や障害を示す）
• タイムアウト（ファイアウォールやルーティングの問題のことがある）

詳細は MTR の読み方 ↗ を参照してください。

オリジンサーバーにアクセスできる場合は、オリジンから Cloudflare の IP アドレス ↗ へ MTR を実行し、オリジンと Cloudflare のあいだのネットワーク経路をテストします。

mtr -rw 104.16.132.229

この経路でレイテンシやパケットロスが高いと、キャッシュミスしたすべてのリクエストに影響します。

リクエストが Cloudflare データセンターへどうルーティングされるかは、パフォーマンスに大きく影響します。

ドメインに /cdn-cgi/trace を付けて、どの Cloudflare データセンターがリクエストを処理しているかを確認します。

curl https://www.example.com/cdn-cgi/trace

Invoke-RestMethod -Uri "https://www.example.com/cdn-cgi/trace"

colo フィールドは、処理中のデータセンターを示す 3 文字の空港コードです（例: サンノゼなら colo=SJC）。データセンターとコードの一覧は Cloudflare ステータスページ ↗ で確認できます。

リクエストが Cloudflare に届くと、次の流れになります。

1. リクエストは anycast ルーティング ↗ に基づき、近くの Cloudflare データセンターへ送られます。
2. コンテンツがキャッシュされていれば、すぐに配信されます。
3. キャッシュされていない場合、Cloudflare はオリジンサーバーから取得します。

オリジンサーバーが、ユーザーを処理している Cloudflare データセンターから地理的に遠いと、キャッシュされていないリクエストは遅くなります。

ユーザーから遠いデータセンターへリクエストが送られている場合、Cloudflare の自動トラフィックエンジニアリングや、ユーザーの ISP によるルーティングが原因であることがあります。

Cloudflare は、最も近い拠点から配信して最良のパフォーマンスを目指しますが、最優先は信頼性です。パフォーマンスと信頼性が相反する場合、Cloudflare のシステムは近くの接続より安定した接続を優先します。

詳細は 地理的に最も近いデータセンターに Cloudflare トラフィックが送られない を参照してください。

想定外のルーティングのよくある原因は次のとおりです。

必要に応じて、次の対策を検討してください。

Argo Smart Routing はネットワーク状況をリアルタイムで分析し、最も速い経路でトラフィックを送ります。レイテンシを平均 30% 下げます。

Argo Smart Routing は Smart Shield の一部です。Smart Shield は、Cloudflare の複数のパフォーマンスおよび信頼性機能をまとめたものです。

Argo Smart Routing を有効にするには、次の手順を行います。

1. Cloudflare ダッシュボード ↗ を開きます。
2. Smart Shield のセットアップガイド に従い、機能を有効にします。

Argo は、次の場合に特に効果的です。

• オリジンがユーザーから遠い
• 特定の経路でネットワーク混雑が起きている
• 世界各地で一貫したパフォーマンスが必要

Argo Smart Routing の仕組みの詳細は、Argo Smart Routing のドキュメント を参照してください。

上記の手順を試してもパフォーマンス問題が続く場合は、Cloudflare サポートに連絡 してください。

サポートに連絡するときは、問題の切り分けに役立つ証拠をできるだけ添えてください。

• HAR ファイル - 遅いリクエストを捉えた HAR ファイルを生成 します。各リクエストの詳細なタイミングが分かります。
• Observatory の結果 - Observatory のテスト結果のスクリーンショットまたはリンクを共有します。
• RUM データ - Web Analytics を有効にしている場合は、パフォーマンス問題を示す関連メトリクスを共有します。
• curl の出力 - 遅いアセットについて、curl --write-out のタイミング内訳を含めます。
• MTR の結果 - ネットワークの問題が疑われる場合は、自分の場所から対象ドメインへの MTR 出力を含めます。
• 具体的な URL - 遅い URL を正確に列挙し、想定応答時間と実際の応答時間を添えます。

遅さを示す証拠が多いほど、サポートは問題を早く特定し、解決できます。

• Observatory - ウェブサイトのパフォーマンスをテストし、監視する
• Cache Analytics - キャッシュヒット率を分析する
• Cache Rules - キャッシュ対象を制御する
• Argo Smart Routing - ネットワークルーティングを最適化する
• トラブルシューティング用の情報収集 - 診断データを集める