WebPerf Waterfall Analysis – Diving Into Your Website’s Requests

Analyzing website performance is something we do on a daily basis here at KeyCDN. One way we benchmark and troubleshoot slowness is by diving into the website’s individual requests and doing what we like to call a waterfall analysis. There are numerous tools out there like Chrome DevTools, WebPageTest, and Pingdom which will generate a waterfall chart of your website. Understanding how they work can help you to better pinpoint performance issues as they provide valuable insights about how specific assets affect your page speed and the user experience.


Waterfall Analysis


The waterfall chart, also referred to as a waterfall graph, provides you with a visual representation of how all the assets on your website load. This includes your CSS, JavaScript, HTML, images, plugins, and third party content. Another important note is that waterfall chart lets you see the order of which assets are rendered in your browser. The order can be very important as this can affect all sorts of things, from render blocking CSS to FOIT issues. Make sure to check out our post on what is blocking the DOM.

There are dozens of tools out there you can use to generate a waterfall chart. Check out our post on 15 different website speed test tools. Below is a typical waterfall chart generated by Chrome DevTools on the keycdn.com website. You can see that the total load time was 966 ms, there were 28 HTTP requests, and a total of 435 KB of data transferred. What you really want to aim for is what we at KeyCDN call a “nice looking waterfall.” We will go more into what that means and how to achieve it later on in this post.



Sometimes all the colors, lines, and bar can be quite confusing at times. So below we will break down some of the most important pieces of a waterfall chart. There is a lot more to a waterfall chart than just your total load times. Also remember that depending on what tool you are using the names for these attributes below might vary slightly.

1. DNS Lookup / DNS


Upon accessing a web page, the browser finds all resources which require a DNS lookup and must wait until the lookup completes before it can download anything. The DNS lookup is based on hostnames. So for example, if you include Google Analytics on your website, it will have to do a DNS lookup not only for your domain.com but also to google-analytics.com.



Check out our post on how to reduce DNS lookups. This is why we always recommend hosting as many 3rd party assets as possible on your CDN because this will mimize your requests to a single DNS lookup. Also, it is important to note that with many tools, if you run speed tests multiple times, it will cache the DNS, meaning you won’t see this information on additional tests. But the lookup still occurs for new visitors that hit your site. WebPageTest has nice solution for this as they provide what they call the “First view” and “Repeat view.” This way you can see a better overall picture.

You can also utilize resource hints such as DNS prefetching, which allows the browser to perform DNS lookups on a page in the background while the user is browsing. This minimizes latency as the DNS lookup has already taken place once the user clicks on a link. See example below.

<!-- Prefetch DNS for external assets -->
<link rel="dns-prefetch" href="//fonts.googleapis.com">
<link rel="dns-prefetch" href="//Google Analytics - Mobile, Premium and Free Website Analytics – Google">
<link rel="dns-prefetch" href="//opensource.keycdn.com">
<link rel="dns-prefetch" href="//cdn.domain.com">
2. Initial Connection / Connect


The initial connection, is also referred to as the TCP connection and or connect in some tools, is the total time required to create a TCP connection. This is used to create a connection between a local host/client and server. It is a three-step method (three-way handshake) that requires both the client and server to exchange packets before actual data communication begins.



Reducing TCP connection time can be more tricky. A good place to start is to ensure you are on a fast web host with low latency. Reducing your TCP connections can also help (the less connections the better). TCP Fast Open is another option which helps reduce the additional network latency time this handshake incurs by having the client send data during the initial SYN, thus allowing connections to take place during the handshake.

And don’t forget about preconnect, which allows the browser to set up early connections before an HTTP request is actually sent to the server. The example below shows what it looks like to enable preconnect for the zone alias link for KeyCDN.

<link href='https://cdn.keycdn.com' rel='preconnect' crossorigin>
3. SSL / TLS


SSL, also referred to as SSL negotiation in some tools, is the total time for the web browser to perform the SSL/TLS handshake. Obviously you will only see this in your tests if your website and or CDN is running over HTTPS. Make sure to read our post on what is the difference between HTTP and HTTPS.



Below are a few a ways you can speed up sites running over HTTPS.

1. HTTP Strict Transport Security (HSTS) is a security enhancement that restricts web browsers to access web servers solely over HTTPS. It helps your performance by eliminating unnecessary HTTP-to-HTTPS redirects.
2. Early termination is very important in decreasing the latency due to the SSL/TLS handshake. By serving your content from a CDN, like KeyCDN, you are reducing the latency cost of each round-trip between the client and the server. A CDN allows you to terminate the connection closer to the user.
3. OCSP stapling is an alternative approach to determining whether an SSL certificate is valid or not. It allows the web server to check the validity of it’s certificates and eliminates the need for the client to contact the certificate authority, reducing another request. OCSP stapling is automatically enabled when you server content with KeyCDN over HTTPS.
4. And of course we have HTTP/2, which is the second major version update to the HTTP protocol since HTTP1.1. Performance features of HTTP/2 include multiplexing, HPACK compression, one connection per origin, server push, and the ALPN extension.

Are you running over HTTP/2 yet? Use our free HTTP/2 test tool to check your web host and CDN provider. KeyCDN has supported HTTP/2 for all customers since October 2015.

4. TTFB / Waiting


TTFB, which stands for time to first byte, is the amount of time it takes from when a client makes an HTTP request to it receiving its first byte of data from the web server. In Pingdom this is also known as the wait time. TTFB is an important aspect of website optimization since the faster the TTFB, the faster the requested resource can start being delivered to the browser. On average anything with a TTFB under 100ms is fantastic. Anything between 200-500ms is standard, between 500ms – 1s is less than ideal and anything greater than 1s should likely be investigated further.



One of the easiest ways to improve your TTFB is to implement caching on your server. For example, if you are running on WordPress, KeyCDN’s WordPress Cache Enabler plugin creates a cached static HTML file on your server. This allows users to avoid the backend resource intensive processes, thus being able to deliver the page with a faster TTFB. You can see example here where simply implementing Cache Enabler reduced the TTFB by over a whole second.

Using a CDN can also drastically improve your TTFB. See our examples below.

TTFB Before a CDN

Here is an example on a test domain of our TTFB without a CDN.



TTFB With a CDN

Here is an example on the same domain with KeyCDN running. As you can see, the TTFB was cut in half simply be enabling our CDN. This will vary of course based on server locations and POPs.

---

Some other ways to speed up TTFB include making sure Nginx and Apache are updated to the latest versions, as well as verifying your origin server isn’t reaching its capacity when it comes to CPU, IO, etc.

5. Content Download


Content download is exactly what it sounds like, this is the time it takes to download all of your content. The larger your assets and file sizes are, the longer the time will be.



Image compression plays a big role when it comes to reducing your content download time. According to the HTTP Archive, as of June 2016, images on average make up 61% of a website’s page weight. Check out our recent case study where we compared JPG to WebP. WebP resulted in a 85.87% decrease in average image size. So it is very important to compress all of your images and as well as using the srcset and sizes attributes for mobile devices.

And of course, implementing a CDN can be one of the easiest ways to decrease the content download time because you will be serving assets from POPs located within closer proximity to your visitors. This helps decrease TTFB as well.

Some other ways to decrease content download time is to ensure your only using JavaScript and CSS that are needed as well as taking advantage of Gzip compression. If you are using KeyCDN, Gzip is enabled on all of your assets via our edge servers.

6. DOM Content Loaded


The DOM is an acronym for Document Object Model. To put it in lamens terms, when you are in the visual inspector in Chrome, using the elements tab, this is showing you a visual representation of the DOM. Your plain HTML is not the DOM, Chrome DevTools shows you the DOM after it has been manipulated, by HTML or Javascript. You can also think of it as the parsed HTML.

When it comes to analyzing the speed of your web pages you always need to take into consideration what might be blocking the DOM, causing delays in your page load times. These are also referred to as render blocking resources, such as HTML, CSS (this can include web fonts), and Javascript. Most tools will show you the total DOM Content Loaded time, which is different than the total load time.



You can read our more in-depth post on what is blocking the DOM and how to fix some of those render blocking resources. There is also the preload directive which offers more control over how particular resources are fetched for the current navigation. Here is an example of preloading fonts.

<link rel="preload" href="https://example.com/fonts/font.woff" as="font" crossorigin>
7. Load Time / Fully Loaded


The load time, also referred to as fully loaded in some tools, is the total time for your webpage to finish downloading, render, and be shown to the visitor. This is of course a very important metric and generally one that is probably used the most when benchmarking websites.



There are many things you can do to speed up your load. Besides following the tips we have already mentioned above, make sure to check out our speed up guides if you are using one of the following platforms:

• How to Speed Up WordPress
• How to Speed Up Magento
• How to Speed Up Drupal
• How to Speed Up Joomla
• How to Speed Up Xenforo

8. Data Transferred / Bytes In / Page Size


Data transferred, also known in WebPageTest as Bytes In, and in Pingdom as Page size, is the total size of all your assets on the web page. The smaller the better. Follow our recommendations above on decreasing content download time which will in turn decrease your total data transferred. As of 2016, the average web page size is a little over 2 MB, which is way too big. Web page size has increased by 1,530 KB or 317% from 2010 to 2016. We recommend aiming for at least 1 MB or less if you want to see decent performance. Although this might not always be possible in every environment.



9. HTTP Requests


Requests shows you the total number of HTTP requests generated on your website. Every individual asset (CSS, JavaScript, image) generate their own request, as well as your initial HTML doc load. In general the more HTTP requests your web page makes the slower it will load.



There are many ways you can reduce the number of requests such as:

• Inline your Javascript (only if it is very small)
• Reducing assets such as 3rd party scripts and plugins that make a large number of external requests
• Don’t use 3rd party frameworks unless they are absolutely needed
• Use less code!
• Combining your CSS and JS files (Remebmer, with HTTP/2 concatenation becomes less relevant)

10. Status Codes / Error / Server Response Codes


Status codes, also referred to as error codes and server response codes, are messages that contain completion status information, such as “HTTP/1.1 200 OK”. The client sends a request message to a HTTP server (after the TCP handshake) which hosts a website, the server then replies with the response message.



If there is a problem with an HTTP request there is a list of status codes which inform your browser so that you can better troubleshoot what the problem might be. The way the user-agent handles the response depends upon the code and the response header fields. For example, a “404 Not Found” error means the the content either does not exist or has been moved.

Summary


As you can see, tools like Chrome DevTools, WebPageTest, and Pingdom provide us with all sorts of valuable insights about how are pages are loading and what might be causing delays. Understanding what each piece of data means can help you better troubleshoot and diagnose performance issues on your site. The next time you do a waterfall analysis, hopefully some of the tips above can help you.

Related Articles

• 15 Website Speed Test Tools for Analyzing Web Performance
• 18 Tips for Website Performance Optimization

The post Waterfall Analysis – Diving Into Your Website’s Requests appeared first on KeyCDN Blog.

Continue reading...