How to Read a Synthetic Waterfall Chart

A waterfall chart is an essential diagnostic tool for your web pages. If you care about how fast your pages load and what might be slowing them down, then you need to have at least a basic understanding of waterfall charts.

^{Image by Freepik}

Pages can be slow for a myriad of reasons, from a sluggish back end to latency to unoptimized third-party scripts that block the rest of the page from rendering. If your site feels slow, you can quickly run your own tests using your synthetic monitoring tools. From those tests you can generate waterfalls and get a good idea of where the problem lies before you flag the problem with other members of your team.

This post is for people who are interested in performance but don’t necessarily have a lot of technical know-how. It’s for people who want to crack the hood and learn:

• Why pages behave the way they do
• How to begin to diagnose performance issues before sending out red-flag emails to everyone on your team
• How to talk about performance with other people in your organization

What is a waterfall chart?

A waterfall chart is any diagram that represents data that is generated cumulatively and sequentially across a process. A performance-specific waterfall chart lets you see the series of actions that occur between a user and your server in order for that user to view a specific individual page of your site.

Each page resource — from HTML to images, CSS, JavaScript, and other scripts — is represented in its own line on the chart. The waterfall shows the moment when each resource is called from the server straight through to the moment when it has been downloaded and rendered in the browser.

(If you’re a project manager or someone accustomed to using Gantt charts, performance waterfalls are somewhat similar in that they depict a cascade effect among interdependent page elements. For example, a page can’t begin to download resources until it has completed its DNS lookup and established a TCP connection.)

Waterfalls: The good, the bad, and the ugly

Let’s follow the picture-is-worth-a-thousand-words principle.

The good

As a general rule of thumb, a good waterfall has few bars, and the bars are relatively short. This indicates that the page is lean and each resource downloads and renders fairly quickly. A good waterfall looks something like this:

CHART

Looking at this waterfall, we see that this page contains XX requests. The Backend time is around XX seconds, which is pretty good. Start Render time is XX seconds, and Largest Contentful Paint is XX seconds (more on these terms later). As pages go, it could be better, but it’s still better than most.

The bad

A bad waterfall is a waterfall that has a combination of (1) more resources, and (2) slower resources. I won’t bother including an image of one here, because I expect you can visualize it well enough on your own. Instead, let’s skip ahead to the ugly, because it’s pretty spectacular.

The ugly

Behold, the Niagara Falls of waterfall charts. You might want to take a few seconds to flex your scrolling finger before you check this out.

CHART

This majestic beast contains a total of XXX resource requests. Backend time is 0.7 seconds, Start Render is around XX seconds, and Largest Contentful Paint is XX seconds. Yikes.

But here’s the caveat...

The difference between a good page and an ugly page is about more than just the number of resources. It’s also about things like:

• How much latency these resources experience
• The order in which they render on the page
• Whether or not they block other resources

It’s important to bear in mind that you can have a waterfall with very few bars, but if it experiences any of these problems, then you might be in no better shape than our Niagara Falls example up there.

Conversely, you can have a waterfall with a lot of bars, but if the most important content renders early, all those bars might not be anything to worry about.

And this neatly leads up to the meat of this post…

Understand basic performance measurement terms

Before getting into how individual page resources load, first let’s get some key performance measurement terms straight:

CHART

Backend time

Start Render

Largest Contentful Paint

Load time

Know your colours

When you look at the bars on a SpeedCurve waterfall chart, there are several things to pay attention to:

LIST

Each of these coloured bars represents a different activity that happens as the object is delivered to the user’s browser. And each of these coloured bars can tell you a useful story about how that specific page resource performs.

COLOUR = DNS lookup

This is when the browser looks up the domain of the object being requested by the browser. Think of this as asking the “phone book” of the internet to find someone’s phone number using their first and last name.

How to use the XXXXXX bar to identify problems: You can’t do much about the XXXXXX bars and they shouldn’t be a problem on most sites.

COLOUR = TCP connection

Also called the three-way handshake, this is the process by which both the user and the server send and receive acknowledgment that a connection has been made and data can begin to be transferred. It’s not easy to speed up the TCP connection, but you can control how many times the connection takes place. This is a good thing to do, because too many connections will slow down performance.

How to use the XXXXX bar to identify problems: If every other bar on your chart has XXXXX in it, that’s too many XXXXXX bars. You can address this problem by having your developers use something called keep-alives to reduce the number of TCP connections. 

COLOUR = Backend time (AKA Time to First Byte)

This is the window of time between when the browser asks the server for content and when it starts to get the first bit back. The user’s internet connection is a factor here, but there are other factors that can slow things down: the amount of time it takes your servers to think of what content to send, and the distance between your servers and the user.

How to use the XXXXXXXXX bar to identify problems:

Too many XXXXX bars. This is caused by having too many resources, each of which requires its own server round trip before it can be rendered in the browser. There are a number of techniques to address this problem, such as consolidating page resources so that fewer bundles need to be sent over the wire, and leveraging the browser cache so that the user isn’t calling for the same resources over and over on subsequent pages in their visit.

XXXXXXX bars are too big. You have a latency problem. You can fix this problem with a CDN, which will bring your content closer to your users. Chances are, you’re already doing this. Hopefully, this post will help show that while a CDNs can be a great resource to have in your toolset, they don’t address all aspects of the performance problem.

Blue = Content download

This is the time it takes for each page resource to be completely sent from the server to the browser.

How to use the blue bar to identify problems: If there are too many blue bars in your chart, then not only does the page contain too many resources, but each of these resources is too large. This problem can be fixed using a number of performance techniques, from fundamental best practices like resource compression to advanced treatments like auto-preloading. (Again, let me know if you have questions about these techniques.)

Longer bars = slower rendering

MORE

Taller bars = larger resources

MORE

Hashmarked bars = blocking resources

MORE

When it comes to user-perceived performance, some bars are more important than others

In SpeedCurve, your waterfall chart is interactive. You can hover over each bar and see how that resource lines up to the rendering filmstrip at the top of the chart. This lets you see which resources are requested before meaningful content appears in the browser.

CHART

If you care about user-perceived performance, then you should care about each of those resources. Ask yourself:

• Are there any slow/large resources? If so, can they be optimized or deferred to render later?
• Are there any blocking resources? Do they need to be blocking, or can they load asynchronously instead? If they need to remain blocking resources, can they be deferred?
• Are there any resources with excessive Long Tasks times? Can they be optimized or deferred?

Learn more about each request

You can also click on each request in a waterfall chart to get a lot more information about that resource, including:

LIST

Identify first- and third-party request groups

MORE