DevTools Waterfall の読み方：どこで遅くなっているか

入門 | 15分 で読める | 2026.07.10

公式ドキュメント
開発ツールパフォーマンスNetwork

今回やること

NetworkのWaterfallは、通信の時間軸を表示する場所です。

Waterfallを見ると、何が遅いのか、どの順番で読み込まれているのかが分かります。

Step 1: Networkを開いてリロードする

DevToolsを開き、Networkタブを選びます。

Cmd/Ctrl + Shift + I

その後、ページをリロードします。

Cmd/Ctrl + R

Waterfall列に、各ファイルの読み込み時間が横棒で表示されます。

Step 2: 長い棒を探す

まずは、横に長いリクエストを探します。

よく遅くなるもの:

  • 大きい画像
  • 外部フォント
  • 外部スクリプト
  • API通信
  • リダイレクト

長い棒がある場合、そのリクエストをクリックして詳細を見ます。

Step 3: SizeとTimeを見る

同じ遅さでも原因は違います。

状態考え方
Sizeが大きいファイル自体が重い
Timeが長い通信や待ち時間が長い
Sizeは小さいが遅いサーバ応答や外部接続が遅い可能性

画像が数MBあるなら、まず画像最適化を考えます。

Step 4: Timingを見る

リクエストをクリックし、Timingを見ると内訳が分かります。

見る項目:

  • Queueing
  • Stalled
  • DNS Lookup
  • Initial connection
  • SSL
  • Waiting for server response
  • Content Download

すべてを暗記する必要はありません。まずは、どこが長いかを見ます。

Step 5: Waitingが長い場合

Waiting for server response が長い場合、サーバが返事をするまで時間がかかっています。

考えること:

  • API処理が重い
  • DBが遅い
  • 外部API待ち
  • サーバが遠い
  • キャッシュされていない

静的ファイルでは短く、動的APIでは長くなることがあります。

Step 6: Content Downloadが長い場合

Content Download が長い場合、返ってきたファイルのダウンロードに時間がかかっています。

考えること:

  • 画像が大きい
  • JavaScriptが大きい
  • CSSが大きい
  • 通信環境が遅い

この場合は、ファイルサイズ削減が効きやすいです。

Step 7: 順番を見る

Waterfallは、読み込み順も分かります。

たとえば、重要な画像が後ろの方で読み込まれていると、ファーストビューの表示が遅く感じます。

確認すること:

  • HTMLが先に読まれているか
  • CSSがブロックしていないか
  • 重要画像が遅れていないか
  • 外部スクリプトが先に詰まっていないか

実践メモ: Waterfallは「何が重いか」だけでなく「何が先に読まれているか」を見るための道具です。

まとめ

DevTools Waterfallでは、長いリクエスト、Size、Time、Timing、読み込み順を確認します。

表示が遅い時は、感覚で直す前に、Waterfallで画像、JS、CSS、API、外部リソースのどれが詰まっているかを見ます。

次に読む記事

Timing内訳の判断表

長い区間意味確認先
Queueing同origin接続や優先度待ち同時request、Priority
DNS Lookup名前解決host、接続再利用
Initial connectionTCP/TLS確立protocol、接続先
Waiting (TTFB)送信後から先頭byteserver処理、upstream
Content Downloadbody受信Size、圧縮、回線

棒全体の長さだけでは修正担当を決められません。TTFBが長いrequestへ画像圧縮をしても、待機時間の中心は変わりません。 反対にdownloadが長い大画像をserver処理の問題として扱うのも誤りです。

DevTools Waterfallを開始待ち、接続、Request送信、Response待ち、Downloadに分け、長い区間と依存Requestの開始順を確認する図

Waterfallの確認方法

同じURLでも初回はDNS・TLS、再訪はcacheや接続再利用が働きます。Disable cacheの有無、hard reloadか通常遷移か、network throttling、service workerを記録します。外部fontがCSSの完了後に始まる、hero画像が遅いscriptの後に発見されるなど、開始順は依存関係の証拠になります。

修正前後は同じprofileで複数回測り、極端な一回だけを採用しません。request数、転送量、対象resourceの開始時刻、TTFB、downloadを比較します。速くなった根拠はWaterfallの色ではなく、狙った区間と依存順が変わったことです。

参考リソース

ケース：hero画像の開始が遅い

画像のdownloadは短いのに表示が遅いなら、圧縮だけでは改善しません。Waterfallでrequest開始位置を見ます。CSS backgroundから遅く発見される、scriptがURLを設定する、API後にDOMへ追加するならbrowserが画像を知る時点が遅れています。

document、CSS、script、画像をInitiator順に並べ、画像開始前に待つresourceを探します。HTMLのimgで早く発見できるか、first viewportの一枚だけpreloadすべきか判断します。全画像のpreloadは帯域競合を増やします。

第三者scriptの転送とmain thread実行は別なので、実行時間はPerformanceで確認します。比較では発見時刻、開始、TTFB、download終了を分けます。圧縮で受信だけ短縮したのか、HTML変更で開始が前倒しされたのかを説明し、最後にLCPへ反映したか確かめます。

API待機と依存関係を読む

APIが階段状に始まる時、serverが順番に遅いとは限りません。frontendが一件目をawaitして二件目を作る依存か、独立requestを直列実行しているかInitiatorと開始時刻で確認します。独立なら並列化候補ですが、rate limitや順序契約がある処理を見た目だけで並列にしません。

Queueingが長い時は同origin接続、priority、service workerを確認します。HTTP/2やHTTP/3では接続の見え方が異なるのでprotocol列も見ます。Stalledをserver処理と呼ばず、Waitingとの境界をTimingで読みます。外部resourceなら所有者、必要性、timeout時のfallbackも確認します。

redirect chainは一行だけでなく前段を含めて読みます。HTTPからHTTPS、旧domainから新domain、末尾slashの補正が重なると、各responseは速くても合計遅延になります。最終URLをHTMLへ直接書けるか確認し、認証redirectを安易に除去しません。

cache確認ではdisk cache、memory cache、304を区別します。初回訪問者の速度を測るなら空cache、再訪体験なら通常cacheで測ります。双方を混ぜた平均にせず、対象利用者を決めます。resource headerのCache-Controlが更新要件と合うことも確認します。

mobile想定ではnetwork throttlingだけでなくCPU slowdownも必要な場合があります。ただしWaterfallは主にnetwork観測なので、parseや実行の遅さはPerformanceへ移ります。toolの担当範囲を越えて原因を断定しません。

おすすめ記事

← 一覧に戻る
PR
PR
PR
PR