The summary page in GTmetrix is friendly enough: a grade, a couple of scores, a list of top issues. Then you click the Waterfall tab and get something that looks like a spreadsheet crossed with a bar chart, sometimes a hundred rows or more, each with a little coloured bar starting at a different point. Most people close it again.
That is a shame, because the waterfall is the most honest view of a page load you can get. Scores summarise; the waterfall shows each file, where it came from, when it started, how long it took and what it was waiting for. This is the GTmetrix waterfall chart explained row by row, so you can find the one or two things actually holding your page back.
What you are looking at
Every row in the waterfall is one request: one file the browser asked for while loading the page. The first row is nearly always the HTML document itself. Below it come stylesheets, scripts, fonts, images, and requests to other services such as analytics or a chat widget, roughly in the order the browser started fetching them.
Time runs from left to right. Each row has a horizontal bar on the timeline; where the bar starts is when the request began, and its length is how long it took to finish. A page that loads well tends to show many bars starting close together near the left. A page with problems shows long bars, gaps, or a staircase where each request only starts once the one above it has finished.
The columns, left to right
GTmetrix arranges the information in a few columns. Labels may shift slightly over time, but you will see something like this:
- The URL of the file, usually shortened. Hovering or expanding shows the full address and the request and response headers.
- Status: the HTTP response code. 200 means the file was sent. 301 or 302 means a redirect. 304 means “not modified”, and 404 means the file was not found.
- Domain: which server sent the file. This column is where you spot third parties.
- Size: how much data was transferred for that file.
- Timeline: the bar itself.
Above the rows you can usually filter by type, so you can see only scripts, only images or only fonts. At the bottom is a summary of the number of requests, total size and load time.
Reading one bar: the timing phases
Each bar is split into coloured sections, and hovering over it shows a breakdown in milliseconds. The colours themselves matter less than the names. The phases you will see, in order:
- Blocking: the browser had the request queued but was not yet sending it, often because it was busy with other files or waiting for a free connection.
- DNS lookup: turning the domain name into a server address. This normally happens once per domain, so you see it on the first file from each new domain.
- Connecting: opening a connection to the server, including the secure TLS handshake for HTTPS. Again, mostly once per domain.
- Sending: sending the request. Nearly always tiny.
- Waiting: the gap between the request being sent and the first byte of the answer arriving. On the HTML row, this is largely your server building the page.
- Receiving: downloading the file. Long receiving bars mean big files, a slow connection, or both.
Once you know these, a bar stops being decoration. A long waiting phase says “the server was slow to answer”. A long receiving phase says “this file is heavy”. A long DNS and connect section on a third-party row says “you paid for a new connection to someone else’s server before anything arrived”.
The vertical lines
Across the whole chart, thin vertical lines mark moments in the page load, such as when content first appeared, when the HTML was fully parsed (DOM loaded), when the main onload event fired, and when the largest content element was painted. Hover over them to see which is which.
They let you answer the useful question: which requests happened before the page became visible, and which came after? Anything to the left of the first paint line had a chance to delay it. A row of scripts finishing just before that line deserves suspicion; a bunch of images arriving long after it, below the fold, are less of a worry.
GTmetrix waterfall chart explained through common patterns
You do not need to study all hundred rows. These patterns tell you most of what you need.
A long wait on the very first row
If the HTML document’s bar is mostly the waiting phase, the server took a long time to produce the page. Everything else waits for this, because the browser cannot request anything until it has the HTML. This usually points to missing or bypassed page caching, slow database work, or overloaded hosting. Our post on time to first byte explains what that first wait includes.
Redirect rows at the top
If the first row or two show a 301 or 302 status, the browser was sent somewhere else before it even got the page: http to https, a missing “www”, or a trailing slash. Each redirect is a full extra round trip. Test the final address directly, and make sure your links and ads point to it.
A staircase of CSS and JavaScript
If several stylesheets and scripts load one after another near the top, and nothing appears until they finish, they are render-blocking. The browser will not draw the page until it has the CSS it needs, and plain scripts in the head pause it too. The fix belongs to a separate topic; for now, note which files and which plugins or theme they belong to (the file path usually gives it away).
One very long bar
Sort or scan for the longest bar. If it is a large image, especially one near the top of the page, that is often your slowest element. If it is a video file, a font or a large script bundle, the same logic applies: size first, then whether it needs to load this early at all.
Many different domains
Scan the Domain column. Each new domain usually brings its own DNS lookup and connection before its file can download. Analytics, ad tags, fonts, maps, chat, reviews, social buttons: each might bring one or more domains. A long list of them, each with a DNS and connect segment, adds up. If DNS lookups themselves look slow, how DNS affects page speed goes into that part of the chain.
Requests that keep going after the page looks finished
Some pages show rows trickling in long after onload: tracking beacons, chat widgets, polling requests, ad refreshes. These may not delay the first view, but they use the visitor’s data and processor and can make the page feel sluggish when someone tries to tap.
404 errors
Any row with a 404 status is the browser asking for something that does not exist. It is wasted time, and often a sign of a deleted plugin or a theme referencing an old file. Easy to fix once found.
Finding the slowest request, step by step
- Look at the first row. If its waiting phase is long, start with the server and caching. Nothing else matters as much until that is fixed.
- Find the first paint line. List every CSS and JS file finishing before it.
- Find the longest bar overall, and the longest bar before the largest content line.
- Filter to images and check their sizes. Note any image far heavier than the rest.
- Scan the Domain column and count the outside domains. Note which belong to tools you still use.
- Check for redirects at the top and 404s anywhere.
At the end you should have a short list: one server issue (or none), a few blocking files, one or two heavy items, and a set of third-party domains to review. Those you can act on, or hand to a developer.
Things that trip people up
- Total load time is not the experience. The last request finishing late, especially a tracking pixel, does not mean the visitor waited that long to see the page.
- Bars that overlap are fine. Browsers fetch many files at once over modern connections. Overlap is good; long sequential chains are the problem.
- The test location matters. Each GTmetrix report comes from a particular test location, shown with the results. If that location is far from your host, every connection takes longer. Compare results from the same location only.
- One run is one sample. Third-party files in particular can vary between runs. Before drawing firm conclusions, run the test again.
Waterfalls look broadly similar in WebPageTest and in Chrome DevTools, so once you can read this one you can read theirs. For how waterfall checks fit into an overall routine, see our guide on testing your website’s speed with a repeatable method; for the wider subject, the full guide to website speed ties it all together.
Frequently asked questions
Why does the first request take so long in my waterfall?
The first request is the HTML page itself, and its waiting time is mostly your server generating that page. Long waits usually mean page caching is missing or bypassed, the database is slow, the host is overloaded, or a plugin is calling an outside service while the page builds. Since every other file waits for the HTML, this delay affects everything.
Do third-party requests in the waterfall slow my page down?
They can. Each new outside domain needs its own lookup and connection before its file arrives, and many third-party scripts then run code on the visitor’s device. Those loading early, before the page appears, do the most harm. Those loading late may not delay the first view but can still make the page feel slower to use.
What is a good number of rows in a waterfall?
There is no fixed target. What matters more is which requests load before the page appears, how large they are, and how many different domains they come from. A page with many small images loading lazily further down can be quicker than one with fewer requests where a few heavy scripts block the start.
Why do I see the same file twice in the waterfall?
Usually because two plugins, or a plugin and the theme, each load their own copy of a library, or the same file is requested with different version strings. Sometimes it is a redirect followed by the real file. Look at the full URLs and the initiator if shown; duplicates are often easy wins once identified.
A waterfall usually narrows the problem to the server, the theme or a tangle of plugin scripts. Working through those is what our speed optimisation service for WordPress sites does, and its before-and-after comparison draws on the same kind of chart.
Next in this series: Lighthouse vs PageSpeed Insights: Why Scores Differ
