Waterfall charts provide a timeline representation of how elements of your web page are loaded into the browser.
This type of graph provides a wealth of information, including details such as the size of each of your resources, the number of requests, the loading behaviour, loading times and much much more!
So grab your
wetsuit webpagetest report, as we dive in and show you how to interpret your waterfall chart and uncover the clues it has to offer for improving the performance of your web site.
What is a waterfall chart?
As mentioned, a waterfall chart depicts how elements of a web page are loaded by the browser over time.
Illustrating the difference between HTTP 1.1 and HTTP/2
HTTP/2 is the "new" Web protocol, whose specification was approved in May 2015.
It allows files to be transferred over a single connection (also referred to as multiplexing). Requests are then issued concurrently by the browser. There is no need to wait until one request has completed before issuing a subsequent request over that same connection, as was the case in HTTP 1.1
First View vs Repeat View
A waterfall chart provides a "First View" timeline (the first time a user goes to your web site) and a "Repeat View" timeline (user returning to your web site).
As an example, let us consider the Leroy Merlin home page:
Here, we see that the Repeat View chart has many fewer rows, meaning that many fewer resources were loaded. This graph serves as a good indicator when it comes to analysing how efficiently caching is being used by your web site.
Understanding a waterfall chart
Looking a little more closely, we can deduce a whole host of information about the process of loading a web page.
Reading across the waterfall chart
- Dark green: DNS resolution
This initial step associates a domain name with its IP address: the browser must determine where to go to retrieve the information.
- Orange: TCP connection
TCP (Transport Control Protocol) is the protocol used for communication between the browser and server
The browser must establish one or more TCP connections with the servers it needs to communicate with, and this connection process can take time. Therefore, the more connections necessary, the longer the site will take to load.
Until now, TCP connections could often be a weak spot when it came to web site performance. But with the advent of HTTP/2, it is possible to use a single connection to send and receive multiple HTTP requests. It is no longer necessary to open multiple TCP connections.
- Purple: TLS connection (formerly SSL)
TLS (Transport Layer Security), formerly known as SSL (Secure Sockets Layer), is used to send resources over a secure connection. Any information sent therefore remains private and cannot be accessed by a third party. In addition, a secure connection guarantees the integrity and authenticity of the message.
The light section represents the Time To First Byte for the resource in question, while the dark section represents the actual downloading of the resource.
Time To First Byte (TTFB)
Time To First Byte is the time taken to load the first byte-- or more specifically, the time taken by the server to send the first byte. TTFB is a key factor when it comes to page ranking, as explained by Webrankinfo: “TTFB is extremely important for organic page ranking, as it determines how your web site's HTML is accessed. Specifically, Googlebot search bot allocates each web site a "quota" to each web site that it crawls (almost certainly based on a time limit, or possibly other metrics). If it does manage to visit all of your site within this quota, then hard lines: some of your pages are likely not to be updated or even not indexed at all!”
Several factors can have a negative impact on TTFB. While some of these are factors beyond the web site's control, such as the quality of the user's Internet connection, others can indeed be optimised, e.g. server response times or distance from the server to the user.
Source: HTTP Archive, from the period 1 June 2012 to 1 June 2017.
Reading down the waterfall chart
- The green line represents “Start Render”: this shows when the blank page begins to be filled with the first elements of the web page.
- The yellow line represents “DOM Interactive”: this shows when the HTML code has finished parsing and the DOM has finished building.
- The blue line represents “Document Complete” (or “Load Time”): this shows when all processing is complete and all resources on the page (images etc) have finished downloading.
This event is fired at the same time as "window.onload()". For a long time it was the de facto web performance indicator, but this is no longer the case. The reason is that load time no longer determines when a web page actually becomes usable. A user may start interacting with the page prior to this event.
- “Fully loaded” indicates when all of a web page's resources (including hidden external resources) have loaded.
Limitations of the Waterfall Chart
While a great deal of information can be gleaned from a waterfall chart, this type of graph still has its limitations.
In particular, Speed Index is not included, despite being a good indicator when it comes to user experience. Speed Index provides a means of measuring how quickly elements are displayed "above the fold" (as depicted below).
This metric relates directly to the user's perception of the speed of your web site.
Keep an eye on your waterfall
Now you have a better understanding of waterfall charts, it's time to turn our interest in the number and size of the bars they contain.
Large numbers of orange bars?
This can mean one of two things:
- You have too many resources distributed across different servers, and at least one connection therefore needs to be made to each of those servers.
In this case, the solution is to group as many resources as possible together on one single server, thereby minimising the number of TCP connections;
- Requests are being sent over different TCP connections, one after another.
In this case, you can turn on keep-alive, which enables a single TCP connection to be used to fetch multiple resources.
|Without the keep-alive :||With the keep-alive :|
(image source: KeyCDN)
And if all else fails...? Concurrent requests are possible with HTTP/2.
Large numbers of requests to load?
Concatenation, image inlining (embedding small images directly within the page HTML) and lazy image loading (only images appearing above the fold are loaded, with the remaining images being loaded as the user begins to scroll the page) will help to mitigate the situation.
Resources taking a long time to load?
Slow time to first byte?
A CDN should solve this issue.
For more information about CDNs, do check out “Content Delivery Network: 11 Questions & Answers”.
This brief overview should give you a better understanding of your waterfall charts. The aim of the game: to shrink the waterfall both horizontally and vertically!
Looking to streamline your web site the easy way?
Fasterize cuts loading times by optimising your web site on the fly. Your waterfall chart will shrink to a more optimal width and height.