HTTP Waterfall Charts are visualizations of all the HTTP requests that are being made by the browser when a page is loaded. When you visit a webpage, the initial request loads in the webpage document. This document then tells the browser to load in all the other necessary resources that are needed to display the page properly. Examples of such resources include CSS files, Javascript files, images, fonts, and even other webpages.
Modern websites can load in hundreds of resources, and each request contains many types of information. By making use of waterfall charts in Rigor, we can visualize all of this data in a clear and succinct manner that allows us to draw conclusions from our data more easily.
Interpreting a Waterfall Chart
At first glance, we can see that there were 84 requests, the total page size was 1.1 MB, it took 1.82s until the end of the last request, and it took 1.17s until the onload event was fired.
Each row in the waterfall chart represents a single resource that is being loaded into the page, and these resources are displayed in chronological order. Information about each resource is displayed on the left, and to the right, we can see a timeline of all the resources that were loaded for that URL.
Each resource has a corresponding bar that denotes the start and end of the request for that particular resource. The length of the entire bar represents the time taken to load that resource, and the colors represent the different phases for that request. If we hover over any bar, we get a tooltip that tells us more information about these phases.
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 the server to receive the first byte (i.e. time between when the browser puts the last byte of the request on the wire and when the browser starts receiving data)
- Receiving: time downloading the response body
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.
Request Metadata
By default, Rigor’s waterfall chart displays the following information about each request:
- HTTP method
- Name of resource
- HTTP response status code
- Size of resource
The first column shows HTTP methods. We can see that all of the requests that were made for each resource were GET requests, but you may see other HTTP methods (like POST) in the waterfall chart.
You can read more about HTTP methods here.
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, and if you Command + click (Windows: Control + click) that URL, it will view that resource in a new tab.
If you are looking for more information about the request or response, you can click on the resource to get an expanded view for details about the Response Headers and Request Headers. This can be helpful if you are trying to simulate this particular request via some other system.
The third column displays the HTTP response status code for that resource. Status codes are used by servers to convey information about the response, and the first digit of the status code specifies one of five classes of response:
- 1xx Informational
- 2xx Success
- 3xx Redirection
- 4xx Client Error
- 5xx Server Error
For more information about status codes, click here.
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. Modern web frameworks can be very image-heavy and contain large CSS and Javascript files. If your resources are too large, you may need to compress, minify, or concatenate some files.
Filters
To view additional information about Content-Type, Domain, or Remote Addresses for all resources, we can make use of filters to add or remove columns to the waterfall chart. This allows us to quickly scan all the resources for patterns in the loading behavior, which can provide insights into errors. Click ‘Reset’ to return to the default layout.
Identifying Common Performance Issues
Waterfall charts provide us with a lot of information about all the requests that are being made by the webpage, and it is difficult to identify potential sources of page slowdowns at a glance, especially if you are unfamiliar with HTTP waterfall charts. Here are some of the red flags to look out for when diagnosing slow page loads:
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.
Large gaps between requests
These gaps represent times when no requests happened, probably because JavaScript was executing or the browser was processing.
Long bars
Long bars typically indicate that a single resource is taking a very long time to load. Sometimes, this can be the case for very large files or images, but it could also be due to server errors or uncompressed files. If you see that several requests are being held up by a particularly long request, that would be a good place to start investigating.
Multiple short bars
If your page is loading many small CSS files or Javascript files, you may be able to reduce the number of round-trips that are being made to the server by bundling these files together into a single CSS or Javascript file. Multiple image requests could also be eliminated by using a sprite sheet.
Ideally, you want to reduce the height of waterfall chart as well as its overall width, such that the page makes fewer requests and loads resources faster. However, this may not always be possible if your website needs to load many large images, or if it relies on external third-party plugins or content. In the next section, we will look at how we can use Domain Analysis and HTTP Referer Analysis to filter for 3rd-party content. Doing this allows us to better understand which resources are within our direct control, and which external domains are contributing to performance slowdowns.
Domain Analysis
The domain analysis aggregates requests by domain, helping you identify sources of slowness. This representation of HAR data can help you:
- Evaluate third-party provider performance
- Focus your optimization efforts on costly domains
- Understand which domains have the greatest impact on your site’s performance
HTTP Referer Analysis
The HTTP Referer analysis provides a tree-view of the requests made by your page. Using the HTTP Referer header, each resource is rolled up to the resource that requested it, allowing you to see the resources responsible for the majority of the site’s requests. This view can help you:
- Understand the performance impact of adding a resource to your site
- Find and eliminate costly resources
- Track down the source of a problematic asset
More information
HTTP waterfall charts contain a wealth of information, and there are many other ways to use them to improve your web performance. To learn more, visit: