How to use a waterfall chart to interpret web performance data

30 July 2012  -   Tags: , ,

Waterfall diagrams are visual representations of data that are generated cumulatively and sequentially across a process. In web performance, waterfalls allow us to see the series of actions that take place between user and server when a user accesses a website.

Here at Strangeloop, we work with waterfalls every day in an effort to not only educate customers on their own website performance, but also help guide our internal operations. Our team encounters plenty of executives, site owners and other customers who aren’t sure how to interpret waterfall charts. This post is intended to help beginners understand a typical performance waterfall, both pre- and post-acceleration. 

Here’s what a waterfall looks like for a typical website that hasn’t been optimized:


Looks like a mess, but a few basic facts make it seem less complicated: 

1. Each row represents a different object within the page.

2. An object could be text, image, Javascript files, etc. 

3. Each object makes its own roundtrip between server and browser.

Now let's take a closer look at the same image:


Each of the colored bars represents a different activity that happens as the object is delivered to the user’s browser:

Dark green = DNS lookup

This is when the browser looks up the domain of the object being requested, similar to looking something up in a massive directory. DNS lookups don’t cause much of a performance problem on most sites. 

Orange = TCP connection

Also called the “three-way handshake,” this is the process by which user and server make friends by sending and receiving acknowledgment that a connection exists, and that data transferring can begin.

It’s not easy to speed up a TCP connection, but limiting the number of connections will improve performance.

Bright green = Time to first byte

This is the window of time between when content is requested from a server, and when the first bit arrives back.

The user’s internet connection is a factor here, but there are other variables at play: the amount of time it takes your servers to “think” of what content to send, and the distance between servers and the user.

Blue = Content download

This is the time it takes for every piece of content to be sent from the server to the browser. 

You can speed up content download by making the total amount of stuff you need to send smaller. More on that later.

Back to our original chart:

This diagram contains four indicators that the site is performing poorly:

1. The number of orange bars.
2. The number of bright green bars.
3. The length of the bright green bars.
4. The number of blue bars.

Too many orange bars

This means there are too many TCP connections taking place, which slows down performance. The best way to address this problem is to ask your developer to use something called "keep-alives."

Too many bright green bars

A bright green bar signifies a roundtrip between browser and server. As each object on the page requires its own roundtrip, roughly 75 are needed in this instance. This problem can be fixed by consolidating page objects into fewer bundles.

Bright green bars are too big

This problem can be fixed with a CDN, which brings content closer to your users. Chances are you’re already doing this, but either way, this post will show why CDNs – though vital to your performance toolset – don’t address all aspects of the performance problem.

Too many blue bars

Not only are there too many page objects, each object is too large. The average web page is between 320 and 420 kb - too big! This problem can be partially fixed through implementing the performance best practices suggested above, and partially fixed using something called compression.

So what does a waterfall chart from an optimized website look like? Take a look at these before-and-after charts for the same site:


When reading the performance reports for a site, there are five things to look for: 

1. As few rows as possible.

2. As few orange bars as possible.

3. Bright green bars that are as few and as short as possible.

4. As little blue as possible.

5. The “start render” and “document complete” vertical lines should occur as early as possible, and be as close together as possible.

Learn more

To  learn more about how to interpret waterfall diagrams, check out this informative webinar by Strangeloop technology VP Hooman Beheshti.

Or to find out how Strangeloop can implement the performance treatments discussed in this post, talk to a performance expert.

Post your comment

Posting comments has been disabled.


  • Thanks for the informative article!

    Ethel, it looks like they used to create these waterfall charts. It's well worth checking out if you haven't already.

    Posted by Tony Quartarolo, 08/08/2012 1:05pm (2 years ago)

  • sorry about the spam - I expected to see my comment show up above the comment box, not under it!

    Posted by Ethel, 01/08/2012 1:52pm (2 years ago)

  • Great post, this looks pretty handy. What tools did you use to generate the waterfall diagram?

    Posted by Ethel, 01/08/2012 1:52pm (2 years ago)

  • Great post, this looks pretty handy. What tools did you use to generate the waterfall diagram?

    Posted by Ethel, 01/08/2012 1:51pm (2 years ago)

  • Great post, this looks pretty handy. What tools did you use to generate the waterfall diagram?

    Posted by Ethel, 01/08/2012 1:51pm (2 years ago)

RSS feed for comments on this page | RSS feed for all comments