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 http://help.rigor.com/hc/en-us.
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 http://help.rigor.com/hc/en-us 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 Headers: If 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.
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:
- 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.
- 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.
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:
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 email@example.com.
As mobile devices continue to play a more prominent role in our 21st century society, their usefulness has spread beyond the casual activities of technological enthusiasts. According to research conducted by FUNDtech, a rapidly growing number of ba...Read More
E-commerce is a growing source of revenue for many companies and businesses, as it continues to capture market-share from brick-and-mortar stores over recent years. However, many businesses are not prepared for this growth of online business becau...Read More
In recent years, client-side browsers have been more involved with processing code before it reaches the user's desktop, shifting away from a reliance on servers handling the bulk of this burden. Websites and applications now rely more on a user's br...Read More
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 for an...Read More