PageSpeed is a useful tool for certain metrics but it lacks some specific details.
Using a tool that shows you a waterfall chart can give you a different angle on performance. GTMetrix, Webpagetest.org and DebugBear are examples of tools that provide a waterfall chart.
What’s a waterfall chart?
The waterfall chart shows a list of every file that your website loads, in the order that those requests are made.
So it pulls back the curtain and gives you a peek at what’s going on behind the scenes when someone visits your site in their browser. It helps you find bottlenecks, errors and other performance issues.
Note, you can get a lot of this info in your browser’s developer tools as well, but using a speed testing service can be more user-friendly and also give you even more details. For example, when using a speed tool, you’ll be able to check from different locations and devices.
Here’s 10 useful things you can learn when running a speed test using a waterfall chart.
- What’s the Time To First Byte (TTFB)?
- Is the visit cached?
- How many files are loading?
- Are critical files loaded early?
- Are files served from your CDN?
- Is browser caching applied?
- Is compression applied?
- Are there any loading errors on files?
- The impact of 3rd party content
- Are there any unnecessary redirects?
What’s the Time To First Byte (TTFB)?
The very first request in the chart represents the server response time. If this is slow, it will affect everything that comes after it, so this metric is critical.
The very first line shows which URL is being tested. / means I’m testing the homepage. Under 500ms is ideal. In this case the request takes 373ms which is good.
Compare that to the uncached version of the page, and you can see what a difference page caching makes in TTFB. It takes 1.1s in this result – 3 times longer.
So sometimes you can see at a glance whether the page is cached or not, but in the next tip we can check more specifically.
Is the visit cached?
There’s a couple of ways to check this.
The first is similar to the above step: Run the URL twice, once normally and once with ?nocache appended to the URL (which in most cases will bypass any server or plugin cache). If the page is cached, the TTFB will be much faster on the normal URL compared to the ?nocache URL.
The second way to check is by looking at the headers on the request to see if any server cache indicators are present. Some cache plugins may also add headers but others (like WP Rocket ) don’t, so this is not a reliable way to see if your caching plugin is working, but can be used to check if a server cache is applied.
In GT Metrix, to check the headers, click on the request to expand it and reveal the Headers tab.
Here we can see that this site is cached by Cloudflare:
This site’s server has a server cache, but it wasn’t used on this response, as we can see by the MISS on the x-proxy-cache header.
Almost all CDN/server caches have some sort of custom header to show this information – you can check their documentation for the specific details.
If it’s not cached you’ll typically see MISS or BYPASSED.
How many files are loading?
A lot of people think “I have a simple site, it shouldn’t be slow” but they don’t realize how bloated or chunky their page is.
While file count is not the be all and end all of performance, having a realistic look at what’s actually loading on the page can be eye-opening. Perhaps your “simple” page isn’t that simple after all.
In GTMetrix, the overall size is at the bottom of the waterfall:
Generally speaking, fewer files are better. Of course there are exceptions – one massive JavaScript file that runs complicated functions might tank your site more than 10 tiny images. But outside of exceptions, fewer files are better.
Are critical files loaded early enough?
Requests related to your Largest Contentful Paint element, such as the main image, or the font if your LCP is text, should show up in the waterfall at or near the top.
Here you can see the difference between a preloaded image and a non-preloaded image:
In the first screenshot, the LCP image is preloaded and is therefore the second request in the list. In the second screenshot, the LCP image is not preloaded and is found near the bottom of the waterfall.
If the LCP element isn’t loaded until late in the waterfall, this is likely to adversely affect the LCP metric.
DebugBear’s free website test tool is very useful for checking this because it labels the LCP element, preloaded elements and requests with fetchpriority=high:
Is a file served from your CDN?
There’s a couple of ways to check this depending on what kind of CDN you use.
If you use a pull CDN like Bunny CDN, the file will be loaded from their domain, or a custom domain you set up. In that case, it’s easy to check the domain column for that. In the below screenshot, keyloop.b-cdn.net is the CDN domain serving the assets:
However, if you are using a CDN like Cloudflare or similar where you’ve pointed your DNS to it and all the files use your own domain name, you can check by looking at the headers on a specific file. In this case, the CSS file is served from Cloudflare:
The headers will also help you to see if the file has been cached at a specific CDN PoP (Point of Presence, the location of the server it was served from) as well.
Click on the file you’re interested in and check for a cache header and HIT. The server header shows exactly which PoP it came from.
Is browser caching applied?
Click on a specific file and check the headers. Browser caching can be applied in a couple of different ways. Generally you should see a cache-control or expires header. You may see etag although that tends to be a bit less common.
The max-age number is in seconds. If the value is too small, less than a few months, most testing tools will flag it in the browser caching section of their recommendations.
Is compression applied?
Again check the headers of a specific file and look for content-encoding.
You should see either br (for Brotli), gzip or, zstd. These are different forms of compression. As long as one of them is applied, you’re all set.
Loading errors on files
Check the status column for this. Files that are responding correctly, without an error or redirect will have a 200 response.
Other response codes will likely require further investigation. The most common error you might see in a waterfall is a 404. That means the file does not exist.
In some cases 404 errors might take a long time for the server to resolve, or could block other files coming later.
So addressing any errors will help overall speed as well as prevent a poor user experience due to missing content etc
3rd party content
3rd party content refers to files that are hosted from another domain, that is not your own. Common examples are tracking scripts, Google tag manager, Facebook scripts, etc They are bad for a few reasons:
- Connecting to an external domain adds extra time
- They often result in request chains – that is, the first file brings in another file and so on. This leads to a cascade of files being shoved into your site which take time and processing power to load.
- If anything goes wrong with the external server it’s possible for that failure to load the file to block any file that should come after it and prevent your site from working correctly.
- You don’t control the file so if the 3rd party does not add browser caching, compression etc, it will bring down your scores and you can’t usually fix it.
Scanning the domain list will quickly show you where files are loading from. In the screenshot below you can see that there are numerous files related to klaviyo which are chained from the initial file klaviyo.js at the top of the screenshot:
Redirects
Redirects are bad for performance because they add extra time to get to the final destination. If a browser requests a file and it gets redirected from one URL to another, it will take longer to retrieve and download that file.
Checking the waterfall will reveal such redirects.
Look for a 301 or 302 response in the status column.
In this example, cat1.jpg is redirecting to cat.jpg. The redirect takes one second, which is wasted time. It also pushes the real image to be loaded later on in the list. So, bad news all around. Avoid redirects unless absolutely necessary.
This list does not represent an exhaustive list of all that can be learned from a waterfall, but it covers the most common and useful cases.