The good news is that modern web browsers expose lots of performance data that can help you understand how your web page performs. With the launch of Browser Insights today, we can analyze the performance from the perspective of the web browser and what the end user actually experiences. In this post, we’ll dive into how we think about performance and utilize the timing APIs in the web browser.
How web browsers measure performance
In the old days, the only way for a developer to profile performance was to intercept requests and measure the time from the beginning of the page load until the end of the load event.
Today, we can use Web APIs that are supported by modern browsers. This is part of the web standard called the Performance API. The Performance API consists of a collection of individual APIs that include:
- Navigation Timing (for timing information related to the page and navigation)
- Resource Timing (for timing data regarding the loading of an application's resources)
- Paint Timing (that provides timing information about paint operation during the page construction)
In this blog post, we will primarily focus on the Navigation Timing API.
Inside the Performance API
To see what’s collected with the Performance API, you can open the Developer Tools in Chrome browser and type ‘performance’ in the console tab (or type in
performance.timing to get direct access to the PerformanceTiming attribute).
Try expanding the Performance object by clicking on the arrow before the label and again expand the ‘timing’. This is called PerformanceTiming, which includes all the timings that relate to the current page load as UNIX epoch timestamp (milliseconds). The timing attributes shown are not in the order of the load. So for better understanding, let’s look at the illustration provided by the W3C.
As we can see from the diagram shown, each element (represented as a box above) in the order from left-to-right, represents the navigation flow of the page load. Each element has an attribute from the starting point to the end (and some have multiple attributes!) so that we can measure the elapsed time for each element. For example, to get the Request Time, you could type in the command like shown below in the console which appears to be 60 milliseconds.
How Cloudflare uses performance data
The metrics we surface are:
- DNS (domainLookupEnd - domainLookupStart): How long the DNS query takes. This could appear as zero if the connection is reused or the content was stored in the local cache (memory or disk).
- TCP (connectEnd - connectStart): How long it takes to establish a TCP connection to the server. If HTTPS, this process includes TLS negotiation time.
- Request (responseStart - requestStart): The time elapsed between making an HTTP request and receiving the first byte of the response.
- Response (responseEnd - responseStart): The time elapsed between the first byte and the last byte of the response received. You can think of this as a resource download time.
- Processing (domComplete - domLoading): How long it took to render the page. If this number is big, you can optimize your document architecture, resource size, or configure settings under the Speed page such as Auto Minify the source code. This document process can be drilled down more with domInteractive, domContentLoadedEventStart, domContentLoadedEventEnd, and domComplete. We plan to provide more detailed analytics on this later on.
- Load Event (loadEventEnd - loadEventStart): When the browser finishes loading its document and resources, it triggers a `load` event. This duration may be helpful to you if you have additional functions or any logic for the load event.
- Total Time: Sum of each timing metrics shown on the graph.
If you are seeing any spikes or unusual form of a line in the stacked line chart, you could start investigating on each element to see what is causing the problem.
For more about how to use Browser Insights, see our announcement blog post.