At Zoompf we work with dozens of website owners every month who are looking to improve the performance of their site. During these discussions we run across a wide variance in the knowledge levels about performance best practices: some are looking to squeeze out that last 500ms of page load time through advanced techniques, while others are content to install a basic wordpress plugin and move on (generally a bad idea). Of course we understand not everyone has the time to become a performance expert.

When I was recently talking with a client, it dawned on me that I was speaking in a vocabulary that was not shared on the other end. In this specific case, the client had not used a waterfall chart before. Again, totally fine – there are many aspects of his business that I knew absolutely nothing about myself!

This does underscore the danger of making assumptions. We all come at web performance from different backgrounds, so its helpful to define a base understanding on the topic. Towards this end, I wanted to spend some time giving an overview of waterfall charts: what they are, why they are useful, and how you can generate your own.

If you’re already a waterfall chart pro, my feelings won’t be hurt if you skip the rest of this post. If not, come along with me for the ride, hopefully you’ll learn a tidbit or two…

What is a Waterfall Chart?

I like to think of a waterfall chart like an X-Ray showing you the inner workings of how a browser loads your webpage. When you type in cnn.com or whatever into favorite browser, you’re no doubt used to seeing the various”waiting on…” and “loading…” messages that scroll across the status bar. What you might not realize, though, is how much “other” content is also getting loaded during that process: CSS files, javascript, analytics beacons, external advertisements, on and on.

The waterfall chart shows you how the sausage is made, providing full visibility into every single piece of content that is used to display the webpage. And not only does it list all the resources, but it shows them in time ordering with the duration of each load. When you’re diagnosing a slow performing webpage, this data can become immensely valuable for identifying bottlenecks.

Consider the example below. The horizontal axis shows the page load time in seconds. The vertical axis shows the in-order sequence of resource loading by the browser. Notice all the “.js” (javascript), “.css” (cascading style sheets), advertising content and more!

Depending on the browser used, many of these resources can be loaded in parallel (hence the overlapping timeframes), but even this has limits and eventually the browser is forced to wait for some resources to finish loading before attempting the next set of resources. This waiting can become a large component of your overall page load time.

How Do I Create a Waterfall Chart?

While there are various tools to do this, in our opinion the hands-on best is WebPageTest. It’s fantastic and it’s free.

There are a number of options here, so let’s walk through the most pertinent:

URL: Okay this one should be obvious, but keep in mind the waterfall chart is for a single page. It may well be your homepage is well optimized, but when you drill down into a child page (say a category page on an e-commerce site) your performance drops sharply. It’s good to test those pages your customers interact with the most, don’t just focus on your home page!

Test Location: This one is very important: your site can load quite differently from different locations in the world. If you host your site in California, don’t assume all your users are also in California! Look at your traffic logs and/or sales history reports to see where your users are coming in from, then choose a location closest to that origin. You may have to run a few tests from different locations around the world to get a clear picture. We talk more about this in our blog about Time to First Byte.

Browser: Waterfall charts are specific to a particular browser, and not all browsers work alike! While its tempting to only test Chrome, look at your traffic logs and see if you are also getting a lot of traffic from IE, Firefox, Safari, or other browsers as well. Don’t make the mistake of assuming a fast website on Chrome is also fast on IE!

Connection: I usually just leave this one on the default of “Cable” since most users these days are on a broadband connection or higher.

Number of Tests: The Internet is a fickle beast. Things that load fast at one moment in time may load slower the next. It all depends on the current congestion in the routes your traffic takes. To smooth out these variances, I recommend choosing a value of 3. WebPageTest will then run the same test 3 times and report median values to smooth out any one time anomalies. While this takes slightly longer to run the test, the improved accuracy is often worth it.

Repeat View: Usually the first time you load a webpage is much slower then the second time. Why? Because your browser is often instructed by the website to cache (aka “keep a local copy of”) commonly used resources such as images, javascript files, and so forth. The level of caching varies wildly from site to site, so its useful to select “First View and Repeat View” here to see how effective caching is on your site. The more effective it is, the faster the “repeat view” time will be.

All the other options can be kept at default. For the purposes of brevity, we’ll keep these out of scope for this post, possibly to revisit later in a deeper dive.

Running the Test

From here, click “Start Test” and let WebPageTest do its magic. A single test usually takes about 30 seconds or so to complete, but may run longer if the site is loading slow or the “Number of Tests” value you select is high. Furthermore, the test server will only run one test at a time, so if other users have submitted test requests before you, you may be stuck waiting in a queue for those to finish first.

Eventually the tool will complete and you’ll see a summary result like this:

There’s a wealth of information displayed here, so let me highlight a few key areas:

First Byte – This is used to measure network latency and how long it takes the server to reply with the first piece of content. We recommend a value of 0.4s or lower. See our post on Time to First Byte for more information.

Start Render – This is the time it takes for your user to start seeing something other then a blank page. While interesting, this number is not the greatest gauge of user experience since your users are still waiting for the page at this point. Still, nobody wants to see a blank page for a long amount of time, so a high value here should be avoided.

Document Complete Time – This is the time it takes for the browser to fire the “onLoad” event. At the risk of oversimplifying, think of this as the time it takes to load the “core” page itself, but not necessarily all the javascript that may run after the page loads. This stat is becoming less relevant as more and more sites adopt a “lazy loading” strategy for resources such as images, meaning the images are loaded in the background while you are already interacting with the page. Still, you ideally want your document complete time to be under 2 seconds.

Fully Loaded – This is the amount of time it takes for everything to load, render and get displayed to the user. This stat can be a bit draconian since the user can still have a pleasant and meaningful experience with your site while resources continue to load “below the fold” (not visible until you scroll) in the background. Still, this is useful for detecting worst case scenarios, especially if you have a misbehaving advertising widget loading in the background.

Speed Index – Speed Index is a relatively new concept introduced to help overcome the challenges with the above metrics, especially for today’s websites that heavily utilize javascript to load content in the background. There’s a good explanation of this metric from Google here. Essentially speed index uses an algorithm to compute what we subjectively interpret as “how fast things display” on the page. I haven’t played around with this metric enough yet to give good guidelines, but in general the lower the number the better. We may do some followup research on this in a future blog post.

The Waterfall Chart

We could write a short book on all the wonderful content in a waterfall chart, so for this beginner’s guide let me just highlight a few key points:

Ideally you want your waterfall to be as “thin” as possible (short overall loading time) and as “short” as possible (small number of elements to load). Of course this is at odds with providing an appealing, feature rich page (lots of content), so balance is needed.

In general you want your waterfalls to be “steep”, meaning they drop down fast vertically. This indicates a high level of parallel loading is happening in your browsers. Modern browsers like Chrome can download up to 8 resources at a time in some cases. For example:

Beware long horizontal lines that “hold up” other content from loading. These are good indicators of performance bottlenecks and areas worth analyzing further. For example, this initial page load has delays both on DNS lookup and initial server rendering:

And of course common sense prevails: avoid the temptation of overloading your site with too many analytics trackers and advertising widgets. You can easily spot those in the waterfall by the URLs that come from domains completely foreign to the page domain. Third party dependencies are one of the largest causes of slow page performance.

In Closing

Waterfall charts are an excellent tool for diagnosing slow performance bottlenecks, but can be sensitive to congestion in the internet and the physical location of your users relative to your servers. Still, every web engineer should include a waterfall analysis in their standard bag of tools.

In future posts we’ll go into deeper depth about waterfall charts for advanced users. And of course, I highly recommend you play around with WebPageTest to generate your own waterfall charts.

If you find a problem and are not quite sure how to fix it, try Zoompf’s Free Scan to learn more about how you can improve your website performance. The Zoompf platform analyzes your entire website against 400 common causes of slow performance and provides prioritized, step by step instructions on how to improve your site performance and keep it fast over time.