Webサイトの応答時間が急に遅くなったときの調べ方。監視データから原因を切り分ける手順

Webサイトのレスポンスタイム（応答時間）が急に遅くなったときは、監視履歴で「いつから・どのURLが・どれくらい遅いか」を確認し、HTTPコードと測定条件を揃えてから通信経路とサーバー側の処理を切り分けることが基本です。原因が不明な段階で画像圧縮やキャッシュ設定を変更しても、遅延の原因と無関係なら改善につながりません。

例えば、通常は250ms前後で応答していたURLが、ある時刻から1,800ms、2,400msと連続して遅くなったとします。監視値の急変は調査の有力な手掛かりですが、その数字だけでは「CPU不足」「WordPressの更新が原因」などと断定できません。200 OKのまま遅いのか、503やタイムアウトも増えているか、すべてのページで遅いのかによって確認先が変わります。

この記事では、突然の応答時間悪化から原因候補を絞る実務手順を解説します。応答時間の推移、対照表、Chrome DevToolsとcurlによる再測定、サーバー・DB・CDNなどの確認、修正前後の検証まで順に扱います。単純な履歴の読み方はWebサイト監視履歴の見方を参照してください。

応答時間は何を測っているかを最初に確認する

同じ「レスポンスタイム」という名前でも、監視サービスによって計測の開始点と終了点が異なります。調査前に数値の定義を確認し、違う方式の結果を一つのグラフで比較しないことが重要です。

HTTP応答時間とページ全体の表示速度は別のもの

外部HTTP監視で200 OKが素早く返っても、実際のブラウザーでは画像・CSS・JavaScriptの読み込みや描画に時間がかかる場合があります。逆に、画面表示は遅くても最初のHTTP応答は速いことがあります。

TTFB（Time to First Byte）は、リクエストの開始からレスポンスの最初のバイトを受け取るまでの指標です。ページ遷移に対するTTFBにはリダイレクト、DNS、接続・TLS、サーバーの応答準備などが関係します。ブラウザーの「Waiting (TTFB)」は、そのリクエストで最初の応答を待つ区間の表示です。測定範囲が違えば値も変わるため、外部監視の「応答時間」と同義には扱いません。

表示体験を表すLCPは、画面内の大きなコンテンツが描画されるまでの時間であり、TTFBとは別の指標です。一次資料としてGoogleのTTFB解説とLCPの解説が参考になります。今回は一般的な画像・JS最適化の総論ではなく、急なHTTP応答の悪化を起点に調べます。

昨日と今日の計測条件を一致させる

URL、HTTPメソッド、リダイレクト追跡、監視拠点、タイムアウト、認証状態、計測間隔が変わっていると、数字の差はサイトの性能悪化とは限りません。変更があった場合は同じ条件の履歴を探して比較します。

例えば、トップページから検索ページへ監視URLを変更すれば、処理内容が異なるため単純比較できません。時刻がJSTかUTCかも合わせてください。異なるタイムゾーンのままサーバーログやデプロイ時刻と突き合わせると、事象の前後関係を間違えます。計測条件が分からないときは「条件の一致は未確認」と記録しておきます。

応答時間が急に遅くなったときの初動7ステップ

急な遅延では、最初に証拠を残し、対象範囲と継続性を調べます。以下の順番ならサーバー管理権限がなくても始められ、必要な情報を保守会社や開発担当者へ渡せます。

1. 急変した時刻を特定する。最後の通常値、最初の遅延値、直近の応答時間を並べ、監視時刻とタイムゾーンを確認します。
2. HTTP結果を併せて見る。200が続く遅延と、503・504・タイムアウトが混じる状態を分けます。欠測を0msとみなしません。
3. 継続性を調べる。一度だけのスパイクか、複数回連続した遅延かを前後の履歴から確認します。
4. 影響するURLを列挙する。トップだけか、検索・ログインなど特定機能か、同じサーバーの別サイトも遅いかを比べます。
5. 可能なら別環境と比べる。別回線・監視地点で同時刻の結果がある場合に照合します。ただし測定方式が違う数字を直接合算しません。
6. 変更履歴を調べる。更新、デプロイ、定期処理、DNS・CDN変更と悪化時刻を突き合わせます。時刻が近いだけで原因とは断定しません。
7. 担当者へ根拠を渡す。対象URL、時刻、通常値・異常値、HTTP結果、影響範囲、確認済み事項と未確認事項を共有します。

申込みやログインなど重要な操作が失敗しているなら、単なる性能改善ではなく障害対応として扱います。反対に手動で大量の連続アクセスを行うと、調査自体が負荷やレート制限を引き起こすおそれがあります。再現のためのアクセスは最小限にし、本番のキャッシュ全削除やWAF停止を最初の手段にしないでください。

応答時間の推移から見分ける4つの変化パターン

応答時間は一行だけではなく時系列で確認すると、急変が継続したのか、一定時間だけ起きたのかを区別しやすくなります。ただし推移の形は原因そのものを証明しません。

以下は説明のために作成した架空の監視データです。2026年10月24日に実際のサイトで発生した障害記録ではありません。同じURL・同じ監視地点で5分間隔に計測したと仮定します。

この例で確実に言えるのは、10時10分には250ms、10時15分には1,850msの応答を観測したことです。実際に遅延が始まった秒単位の時刻や、各計測の間ずっと遅かったかどうかは、この表だけでは確定できません。サーバーログと突き合わせて調査範囲を絞ります。

段差のように突然遅くなった場合

それまで安定していた値がある時刻から高い水準に移り、その後も同程度の遅延が続く形です。アプリ更新、構成変更、キャッシュ動作の変化、データベース負荷などの変更点を調べる入口になります。

変更履歴と時刻を並べ、該当する処理や接続先が実際に変わったかを確認します。例えばデプロイが同じ時刻にあっても、コード変更と遅延の関係をログや処理時間で裏付けるまで原因とは書きません。

時々だけ大きく遅くなる場合

ほとんどの観測は通常水準なのに、数回だけ高い値が現れる形です。瞬間的な接続待ち、外部APIの遅延、突発的なDB問い合わせ、アクセス集中、監視地点の一時的な通信遅延などが候補になります。

平均値だけでなく、最大値や、サンプル数が十分にある場合はP95なども参考にします。少数の値から計算した高パーセンタイルには限界があるため、件数と期間を明記します。一部のユーザーだけが困っているなら、平均が正常でも影響がないとは限りません。

毎日決まった時刻に遅くなる場合

深夜や毎時の決まった分などに繰り返す形では、バックアップ、データ集計、定期同期、WordPressの定期処理などの実行時刻を確認します。

処理の予定時刻だけではなく実際の開始・終了時刻、CPUやDB接続数、アプリログも比較します。処理を止める場合はその業務への影響と復旧方法を確認してから判断します。

特定ページまたは特定地点だけ遅い場合

トップページは通常なのに検索結果や会員ページだけ遅い、あるいは特定地域でだけ遅い形です。ページ固有の処理、キャッシュ、データベース、CDNや経路の違いに着目します。

検索ページだけが遅いなら検索条件やクエリを、地域差があるなら地点別の同条件の測定を見ます。監視地点が一つしかなければ、その地点の記録だけでは地域差があると断定できません。

DNS・TLS・TTFB・転送時間のどこで遅いかを調べる

応答時間全体を段階に分けられると、問題の位置を絞りやすくなります。外部監視が総時間しか記録していない場合は、Chrome DevToolsやcurlなど別の計測方法を追加します。

GoogleのTTFB解説とChrome Networkの公式説明では、それぞれの段階と計測項目が説明されています。ChromeのWaiting (TTFB)が長いときは初回応答までの待機を確認しますが、それだけでアプリのコードが原因とは言えません。

また、最初のバイトは早くても本文の受信が長ければ、応答サイズや転送経路を確認します。最初のHTMLと画像・スクリプトの処理は別です。ブラウザーで画面全体が遅いときは、HTTP監視の結果だけで結論を出さず、Waterfallなどで読み込み順を確認してください。

応答時間の症状と原因候補の対照表

監視データの異常は、原因の証明ではなく調査先を選ぶためのサインです。下表では典型的な現象を整理し、同時に確認すべき証拠を記載します。

例えばCPU使用率と応答時間が同時に増えていても、CPU増加が直接の原因かどうかは別途検証が必要です。原因を確定するには、時刻・処理内容・リソース状態・変更前後の再測定など複数の証拠を照合します。証拠不足なら原因は「調査中」と記録します。

200・503・504・タイムアウトの違いを確認する

HTTPコードと応答時間は必ずセットで読みます。エラー応答を速く返した場合でも、サイトが正常だったとは限りません。コードを取得できなかった場合に、架空のコードを補ってはいけません。

200 OKのまま遅くなった場合

200 OKはHTTP要求に成功応答が返ったことを意味します。ページの重要な操作が正常なこと、ユーザーに速度の影響がないことまでは意味しません。

例えばログインや検索が遅い場合、トップページを監視して200が出ていても問題が残る可能性があります。対象操作の応答時間や利用者の影響を確認し、必要に応じてページ別の記録を取得します。200 OKでもサイトに不具合がある理由では、HTTPステータスと実際のコンテンツが異なることを詳しく説明しています。

503・504が混じる場合

503 Service Unavailableは、サービスが要求を処理する準備ができていないことを示すHTTP応答です。過負荷や一時的なメンテナンスなどが考えられますが、原因は個別に調べます。

504 Gateway Timeoutは、ゲートウェイまたはプロキシーが上流サーバーから必要な応答を時間内に受け取れなかったことを表します。504が記録されたら、どの機器・サービスが返したコードか確認し、上流の応答時間やエラーログを見ます。参照：MDN 503、MDN 504。

監視側タイムアウトは504とは限らない

監視ツールが自分の制限時間に達してHTTP応答を取得できなかったケースは、504というHTTPレスポンスを受信したケースとは異なります。記録にコードがなければ「HTTPコード未取得」と扱います。

タイムアウトの設定が短すぎる場合と、実際に応答が遅い場合も区別が必要です。直前直後の成功結果や別の監視地点、サーバーログを確認します。しきい値をむやみに延ばすと本当の障害を見つけるのが遅くなる場合があります。

サーバー・アプリ・データベースの内部記録を調べる

外部監視で遅延の時間帯を絞れたら、管理権限を持つ担当者が内部記録を調べます。権限のない方は以下を依頼項目としてまとめると、保守会社との調整に役立ちます。

Webサーバーのアクセスログとエラーログ

最初に対象URLのアクセス数、ステータス、日時、処理時間、上流へ接続できたかを確認します。ただしWebサーバーの標準設定ですべての時間情報が残っているとは限りません。

Nginxでは、構成に応じてリクエスト全体の処理時間を示す $request_time、上流への接続時間を示す $upstream_connect_time、上流から応答ヘッダーを受けるまでの $upstream_header_time、上流から応答を受信する時間を示す $upstream_response_time などをログに出せます。現在のログ形式でそれらが記録されているかを先に確認します。

参照：Nginx公式のログ管理ガイド。新しい記録を追加するために本番設定を変える際は、影響範囲と設定の検証が必要です。障害中に推測で設定を変更せず、まず残っているログを保全してください。

アプリケーションの待機・外部APIの処理時間

動的なページだけ遅い場合は、アプリケーションのワーカー待ち、同時接続、認証、外部API呼び出し、例外やリトライなどを調べます。ページ内のどの処理が長いかを記録できれば、優先して確認する場所が分かります。

外部API待ちの場合、CPU使用率が大きく上がらなくてもページの応答時間が伸びることがあります。反対にCPU使用率が高いからといって外部APIの遅延を除外することもできません。可能なら同じリクエストに対するトレースや各処理の所要時間を照合します。

DBの遅い問い合わせ・接続待ち・ロック

特定の検索、一覧、会員処理が重いときは、クエリ実行時間、索引の利用状況、実行計画、DBロック、同時接続数、接続プールの待機などを調査します。

データ増加でクエリの実行計画が変わったり、特定条件の検索だけ負荷が高くなったりすることもあります。ただし調査のために本番へ重いSQLを何度も投げることは避けてください。ログ・監視・安全な実行計画確認など、影響の小さい手段を優先します。

CPU・メモリ・ディスク・ワーカーの状態

CPUの飽和、メモリ不足に伴うスワップ、ディスク入出力待ち、ストレージの空き容量、ワーカーや接続数の上限は、応答時間に影響する候補です。

ここでも確認すべきなのは遅延の時刻と内部指標の変化が重なっているかです。調査時点でCPUが低いとしても、過去のスパイクがなかった証拠にはなりません。監視履歴で観測した時刻と同じ時間帯の内部時系列データが必要です。

CDN・DNS・WAFなど通信経路を切り分ける

サーバー内部の応答が通常どおりでも、ブラウザーや外部監視からの通信が遅い場合は、通信経路上の要素を調べます。CDNやWAFなどの保護・配信機能を無断で停止しないことも重要です。

キャッシュ応答とオリジン応答を分ける

同じURLでもCDNキャッシュから返る要求と、オリジンサーバーへ送られる要求では処理経路が異なります。キャッシュのヒット・ミス、エッジの応答、オリジンへの接続時間を確認できるなら比べます。

ログインページや個人情報を含む応答では、キャッシュさせないことが安全上正しい場合もあります。速くするために認証ページを無理に共有キャッシュへ載せる判断はしないでください。キャッシュ削除で一時的に挙動が変わっても、それだけでは根本原因の証明になりません。

特定拠点だけ遅い場合はDNSやWAFも候補

監視地点ごとの差、DNS解決時間の増加、403や429の混入があれば、名前解決・通信経路・WAF・レート制御などを検討します。

WAFのログで該当時刻に規則が発動していないか、CDNのエラーやリダイレクトが増えていないかを確認します。公開URLとオリジンIPはCDN利用時に一致しない場合があるため、DNS応答だけで接続先の全体を判断しないようにします。

Chrome DevToolsで通信の遅い部分を確認する

ブラウザーで遅延を再現できる場合は、Chromeの開発者ツールを使ってページの通信を確認できます。HTTP応答の遅延と、画像・スクリプト読み込みの遅延を分けることが目的です。

NetworkのTimingを見る手順

Chromeで対象ページを開き、F12などで開発者ツールを表示して「Network」を選びます。画面を再読み込みし、ドキュメントのリクエストを選んで「Timing」を確認します。

DNS Lookup、Initial connection、Waiting (TTFB)、Content Downloadなどの時間を比べると、どの区間が長いかを確認できます。ブラウザーのキャッシュが使われたか、シークレットモードか、ログイン状態はどうかも記録してください。Chrome DevTools公式リファレンスにはNetworkパネルの項目が掲載されています。

ドキュメント自体のTTFBが通常なのに画面が遅い場合は、Waterfall上で大きな画像や読み込みの遅いJavaScript、長い処理がないかを確認します。HTTP監視の応答時間が急変していないなら、原因の調査対象がクライアント側にある可能性もあります。

再現条件を揃えて比較する

キャッシュを無効化すると普段のユーザー体験とは異なる場合があります。比較する際はキャッシュの条件、アクセス回線、ブラウザーバージョン、ログイン状態、対象URLを揃えます。

再現しなかったときは「現在の条件では再現せず」と記録してください。監視が検知した過去の遅延がなかったと判断する根拠にはなりません。時刻や接続経路が違うだけで結果が変わる場合もあります。

curlでDNS・TCP・TLS・初回応答・総時間を測る

HTTPリクエストの各段階の時間をコマンドで確認したい場合は、curlの書式指定機能を使えます。Windows PowerShellの場合は、環境による別名の違いを避けるためにcurl.exeを明示すると分かりやすくなります。

curl.exe -sS -o NUL -w "HTTP: %{http_code}\nDNS: %{time_namelookup}s\nTCP: %{time_connect}s\nTLS: %{time_appconnect}s\nFirst byte: %{time_starttransfer}s\nTotal: %{time_total}s\n" "https://example.com/"

ここに示したexample.comはコマンド構文の説明用です。利用権限のある実際の監視対象URLに置き換えてください。macOSやLinuxで同じ考え方のコマンドを実行する場合は、出力先としてNULではなく /dev/null を使えます。

time_namelookup は名前解決完了まで、time_connect はTCP接続完了まで、time_appconnect はHTTPSなどの接続準備完了まで、time_starttransfer は最初のバイトを受け取るまで、time_total は処理全体の完了までを示す累積時間です。これらは個別の時間区間ではないため、各値を足し算してはいけません。各変数の定義はcurl公式マニュアルで確認できます。

GETとHEAD、リダイレクト条件を揃える

curlの -I を使うとHEADリクエストになります。GETとHEADではサーバーの処理が異なる場合があるため、GET監視の値と直接比較するなら、同じメソッドを使うことを優先してください。

301や302などの転送があるときは、転送前だけを調べるのか、 -L で転送先まで追うのかを決めて記録します。転送条件が変われば最初の応答と総時間の意味も変わります。転送先の監視方法は301・302リダイレクト先を監視する方法も参考になります。

原因候補が分かった後に確認すること

原因と考えられる処理を修正しても、一度の応答が速くなっただけで完全に解決したとは言えません。修正前と同じ条件で比較し、別のページや機能に新しい問題がないか確認します。

対応記録には観測と推測を分けて書く

調査時の最低限の記録は、対象URL、観測時刻、通常の応答時間、遅延時の応答時間、HTTP結果、影響範囲、実施した確認です。仮説と判明した事実を分けると、引き継ぎや再発時の確認が容易になります。

例えば「10:15に1,850msを観測。10:20、10:25も2,000ms超。HTTP 200を確認。10:12にアプリ更新があったが関連は未確認」と記録できます。これは架空の文例です。原因を断定していないため、後から新しい情報が得られても記録を修正しやすくなります。

回復した時間帯と再発しないことを確認する

再起動やキャッシュ状態の変化によって一時的に速くなることがあります。遅くなる条件が再発していないか、一定期間の監視で確認してください。

曜日、時間帯、監視地点、対象URL、検査方式を合わせて比較すると、対策前後の違いを解釈しやすくなります。統計を出す場合は測定件数も併記し、タイムアウトや未計測を0msとして平均に含めないようにします。

単発ノイズと継続遅延を区別する運用を決める

調査結果を今後の監視へ反映するなら、通常の応答時間と、重要な業務への影響を基準にして確認手順を決めます。全サイト一律のms基準を根拠なしに設定しないことが重要です。

通知しきい値や再試行条件は、異常の見逃しと誤検知の両方に影響します。死活監視の誤検知を減らす方法とWebサイト監視のアラート設計で、運用の考え方を分けて説明しています。

エンリンクの監視履歴を調査の入口にする

エンリンクではHTTP/HTTPSの稼働状況と応答時間、SSL証明書の期限、監視履歴などを確認できます。監視対象のURLの状態を継続して保存し、普段の水準と急な変化を比較するための入口になります。

ただし応答時間だけから、CPU不足、データベース障害、通信経路などの根本原因を自動的に特定できるわけではありません。必要ならChromeやcurlでの計測、サーバーやアプリのログを追加で確認してください。エンリンクの監視結果とサーバー内部の実測は異なるデータです。

公式の機能一覧と料金プランを2026年10月24日に確認したところ、無料プランは最大5サイト・1日2回、スタンダードは最大20サイト・最短15分、ビジネスは最大50サイト・最短5分、プロは最大100サイト・最短1分の定期監視として案内されています。設定上の間隔は障害検知までの時間を保証するものではありません。

複数のWebサイトを管理している方は、エンリンクの無料登録から、重要なサイトの状態と応答時間の記録を始められます。問題がないときの履歴を残しておくと、急な異常を比較する基準として役立ちます。

よくある質問

応答時間が急に悪化した際に、監視画面だけでは判断しにくい点をまとめます。

200 OKなら放置しても問題ありませんか？

200 OKはHTTP応答が成功したことを示すだけで、速度や機能が十分であることを保証しません。

同じURLの通常時と比べて大きく遅くなっているなら、影響範囲を確認してください。特にログインや申込みなど重要な機能は、HTTPコードに加えて実際の操作も確認する必要があります。

何msを超えたら異常と判断すべきですか？

すべてのWebサイトに適用できる一律の異常値はありません。ページの用途と、同条件での通常時の分布を基準にします。

固定の基準値だけに頼らず、急変の大きさ、遅延の継続時間、エラー率、利用者への影響を合わせて判断してください。監視間隔が長い場合は、短時間の悪化を観測できない可能性もあります。

自分のパソコンでは速いのに監視が遅いのはなぜですか？

監視地点、時刻、回線、DNS、キャッシュ、認証状態、アクセス経路などが異なる可能性があります。

現在のブラウザーで速いという結果だけでは、過去の監視記録が間違っていた証拠になりません。両方の測定条件を並べ、同時刻の複数の結果があれば比較してください。

タイムアウトはHTTP 504と同じですか？

同じではありません。監視ツール側の待機上限到達と、ゲートウェイから実際に返るHTTP 504は別です。

HTTPコードが未取得なら、そのように記録します。原因を調べるには監視ツールのエラー種別、サーバーログ、上流への接続記録を確認します。

応答時間が急に遅くなるとSEO順位が下がりますか？

短時間の外部監視結果だけで、検索順位への影響を断定することはできません。

外部監視の応答時間と、検索エンジンが評価する実際の表示体験は同じではありません。検索パフォーマンスへの影響を調べたい場合は、Search Consoleなどを対象ページ・対象期間を揃えて確認してください。

まとめ：応答時間の急変は順番に原因を絞る

レスポンスタイムが急に遅くなったときは、監視数値の変化を出発点に、同じ条件でどの区間が長くなったかを確認するのが基本です。

まず急変時刻とHTTP結果、影響するURL、継続性を確認し、その後にDNS・接続・TTFB・本文受信、サーバー・アプリ・DB・CDNの記録へ進みます。原因が分からない段階で設定を大きく変えず、確認済みの事実と原因候補を分けて残してください。

応答時間が通常水準に戻った場合も、修正前と同じ条件で一定期間の回復を確認します。複数サイトの稼働状況と履歴を継続して把握したい場合は、エンリンクの無料登録もご利用いただけます。