Firefox Network Monitor: Waterfall Chart Timings Explained
This article provides a breakdown of how the Firefox Network Monitor visualizes network request lifecycles using its waterfall chart. It covers the four critical phases of a web request—DNS lookup, TLS handshake, waiting (Time to First Byte), and content download—explaining what happens during each stage, how Firefox labels and color-codes them, and how developers can interpret this data to resolve performance bottlenecks.
Understanding the Waterfall Chart
The waterfall chart in the Firefox Developer Tools Network Monitor represents every network request as a horizontal bar divided into color-coded segments. Each segment corresponds to a chronological phase of the request. To view the exact millisecond breakdown of a specific request, click on the request row in the network log and select the Timings tab in the right-hand pane.
While Firefox tracks up to seven distinct phases (including "Blocked", "Connecting", and "Sending"), performance analysis primarily focuses on DNS, TLS, Waiting, and Receiving.
1. DNS Lookup (Labeled as "DNS Resolution")
Before Firefox can contact a server, it must translate the
human-readable domain name (like example.com) into a
machine-readable IP address.
- What it measures: The time taken to resolve the domain name via a Domain Name System (DNS) server.
- How Firefox displays it: It is labeled as DNS Resolution in the Timings tab and represented by a pink/magenta segment at the start of the active network phase in the waterfall bar.
- What it means for performance: If this bar is long,
the DNS provider is slow, or the browser is resolving too many unique
third-party domains. If the bar is missing or shows
0 ms, Firefox already had the IP address cached locally.
2. TLS Handshake (Labeled as "TLS Setup")
Once the IP address is found and a standard TCP connection is established, secure websites (using HTTPS) require an encrypted connection before any actual page data can be requested.
- What it measures: The time taken to complete the cryptographic negotiation between Firefox and the web server. This includes verifying the server's SSL certificate and agreeing on encryption keys.
- How Firefox displays it: It is labeled as TLS Setup and appears as a purple segment immediately following the TCP connection phase.
- What it means for performance: This segment only
appears for
https://requests. Long TLS setup times indicate that the server is slow at handling cryptographic math, the certificate chain is bloated, or high network latency is delaying the back-and-forth negotiation packets.
3. Waiting / TTFB (Labeled as "Waiting")
After the connection is secured and Firefox sends the HTTP request, the browser must pause until the server starts sending back the requested file. This is industry-standard Time to First Byte (TTFB).
- What it measures: The duration between the moment Firefox finishes sending the request and the moment it receives the very first byte of the server's response.
- How Firefox displays it: It is labeled as Waiting and is typically represented by a green or violet-blue segment (depending on your DevTools theme) in the waterfall chart.
- What it means for performance: The Waiting phase combines two factors: one round-trip of network latency and the server's internal processing time. A long Waiting bar usually points to backend bottlenecks, such as slow database queries, unoptimized server-side code, or lack of server-side caching.
4. Download Times (Labeled as "Receiving")
Once the first byte arrives, the Waiting phase ends, and the browser begins downloading the actual payload (HTML, CSS, JavaScript, or media).
- What it measures: The time required for Firefox to read the complete response data sent from the server down to the final byte.
- How Firefox displays it: It is labeled as Receiving and is shown as the final blue segment on the right side of the waterfall bar.
- What it means for performance: The length of the Receiving bar depends on the size of the file and the user's internet bandwidth. If this segment is excessively long, the asset is likely too large and requires optimization techniques like Gzip/Brotli text compression, image compression, or code minification.