Reading time 5 min

One of my favorite features in the Rigor application is the waterfall chart, HAR report, or load time breakdown that Rigor captures for each page monitored with a Real Browser check. I love waterfall charts because they can provide rich insights about how specific assets affect page speed, performance, and user experience.

You may be familiar with waterfall charts from other performance monitoring tools or as the chart you see in the Network panel of your browser developer tools.

If you’re not familiar with HAR reports or waterfall charts, you may feel a bit confused by all of the lines, colors, and numbers on the charts. In this blog post we’ll walk through the columns of the chart together, identify the components, and discuss how the information can be helpful for diagnosing slowness.

For the purpose of this post, we’ll look at the waterfall chart for the Rigor Knowledge Base’s home page at


At first glance, we can see that there are 15 requests, the total page size was 262.1 KB, it took 1.04 s until the end of the last request, and it took 1.07 s until the onload event fired.

The first column in the waterfall chart shows HTTP methods. We can see in our example that all of the requests to make up the page are GET requests, but you may see other HTTP methods (like POST) in your own waterfall chart. You can read more about HTTP methods here. If you have many requests or round trips you may want to consider joining some resources. One common example of combining resources would be a sprite sheet for icons and symbols.


The next column shows the name of the resource. When we hover over the name we can see the URL path where the resource is located. (Pro-tip: use command + click or ctrl + click to open that path in a new tab and view the resource.)

A quick note on HeadersIf you’re looking for more information about the request or the response, you may want to drill down even further to take a look at the headers section for a request. In Rigor’s waterfall charts you can click on the name of any resource to expand the Headers section.

This section shows available information about the Response Headers and Request Headers.

The third column shows the HTTP response code that we received. In this example all of our response codes are pretty boring – 200 OK. If you’re not sure what different HTTP response codes mean, here’s a resource to learn more.

The fourth column shows the size of the resource. When we hover over the size of a resource we can compare the compressed and uncompressed sizes for the resource in KB and bytes. These days popular web designs can be super image heavy with large complex CSS and JavaScript files. If you suspect that your design is affecting performance, pay special attention to the sizes here. You may need to compress, minify, or concatenate some files.

Moving right along! Here’s where things get fun:

The fifth column starts a timeline for your page load that starts at 0 ms and ends at the time it took for your last request to finish loading.

If we hover over any of the resources in this chart, we’ll see a legend that will help us understand more about the lines and colors that represent requests.


The legend shows us different color codes that represent what was happening with the request at that time. When we look at the first GET request in this chart we can clearly see phases of blocking (yellow), waiting (purple), and receiving (blue).

Here’s a quick reference for the types of request phases we may see:

  • Blocking: time spent in the browser queue waiting for a network connection
  • DNS lookup: time for the DNS to resolve
  • Connecting: time required to create a TCP connection
  • Sending: time sending request data to the server
  • Waiting: time waiting for a response from the server
  • Receiving: time downloading the response body

You can read more about request phases here.

The blue vertical line represents the DOMContentLoaded event which occurs when the main document has been read and parsed. We generally treat the blue DOMContentLoaded line as the time when your user starts to see items render on the page. The red vertical line represents when the onload event fires, which is when all of the page’s necessary resources have downloaded. In some instances, resources may finish downloading or start downloading after the onload event or past the red line.

Your waterfall charts are likely more complex than this example, but the basic components are the same.

Now that we understand the basics, let’s talk about some simple ways to diagnose what may be slowing things down:

  1.  Look for red text. If you have 400 or 500 error response codes for resources in your waterfall chart you may see the name of the resource marked in red text to indicate that there was an error retrieving that resource. The below example shows what a 500 Internal Server Error might look like in my waterfall chart, but you could see any one individual request fail within the makeup of a page.waterfallcharterror
  2. Look for long bars. In the following example the long bar represents an especially long time for a DNS lookup to find a custom font on my blog.waterfallchartlongbar
  3. Look for big gaps between requests. These gaps represent times when no requests happened, probably because JavaScript was executing or the browser was processing.


I hope this post helps makes the waterfall charts in the Rigor application seem less mysterious and more accessible!

This is by no means the most comprehensive resource on this topic. If you’re looking for further reading about waterfall charts in general, I recommend either of these two great resources:

Firebug Net Panel Timings from
Waterfalls 101 from

As always, if you have any questions about reading waterfall charts in the Rigor app, we’d love to hear from you! You can reach us via email at

Suggested Blog Posts

The Perception Gap for Poor Web Performance

E-commerce revenue continues to grow,as consumers turn away from shopping in brick-and-mortar stores to shopping online.  However, many businesses are not prepared for this growth because they do not fully understand the market and how to invest in...

Read More

Using Browser Trends to Maintain a Better Site

Because of the multifarious nature of web clients today, it’s important to consider the usage statistics when designing, implementing, and managing your site. However, misconceptions often arise when determining what browsers to design...

Read More

Finding Causes of Intermittent Errors from Google Webmaster Tools

Google Webmaster Tools is a web service that allows webmasters to view the status of their sites as seen by Google and the Googlebot crawlers. In addition to indexing your site structure and content, the Googlebot crawlers also record data on perform...

Read More

Optimization Options not Always Optimal

Web designers and developers are always looking for ways to speed up their page load times. Yahoo has an excellent article written on the best practices for speeding up your page. How do you know if implementing one of their suggested practices will...

Read More