Measuring web performance can give you insights into what causes your web pages to load slowly (or quickly), how CDNs affect load times and how third party objects affect user experience. You can also determine whether web server or network performance is affecting your service. And the best way to stay informed about your service health is to set up targeted, specific alerts. We’ll cover web performance metrics in this post, digging into web server, page load and transaction tests. You may also be interested in previous posts on DNS alerts and BGP alerts.
Metrics for Your Web Perf Toolkit
ThousandEyes has three tests to measure website and web page performance: HTTP Server measures availability and response time of a web server, Page Load measures performance of an individual page and Web Transaction measures performance of a sequence of pages and user actions.
Here are 5 must-track metrics to measure and alert on:
Page Load Time
Page Load Time is a key metric for web page performance. It can be decomposed into parts by the browser that correspond to W3C navigation timing: blocked, DNS, connect, SSL, send, wait and receive. Blocked represents the browser waiting for an available connection, typically limited to 6 per domain. Additional measurements include response time, fetch time and DOM load time. Figure 1 shows the relation of these elements with the blocks you will see in a page load waterfall and the navigation timing names. For more info, check out Google Developer’s critical rendering path.
In addition to performance (response time, DOM load time and page load time), you can also monitor availability by alerting on errors and incomplete page loads (typically from time outs). Setting up these alerts is easy. Figure 2 shows a Page Load Alert Rule that will be triggered when a variety of metrics are degraded.
You should make sure to customize the page load timeout to match the specifics of your page; set more time for rich graphics and for geographically disperse users. You can adjust the conditions for the number of locations and number of intervals required to trigger an alert so that you are only notified when a ongoing problem crops up, rather than a local DNS hiccup or minor route flap.
Web Server
Each page load test also includes an HTTP Server test. HTTP Server Alert Rules include HTTP fetch phases (e.g. DNS, connect, receive), HTTP response codes (e.g. 200, 500) and error types so that you can disambiguate what’s wrong with the web server or the network connection. Figure 3 is an example of an alert that is sensitive to web server issues.
Third Party Components
Most web pages contain more than a few third party objects – ads, tracking pixels, javascript snippets, fonts, external logins, etc. Some of these may be business critical, say if you are a newspaper that relies on ad revenue. These objects can, and do, cause chaos when they don’t perform: see January 2015’s Facebook outage that took down Tinder or November 2014’s DoubleClick outage.
Sometimes you may want to be notified if third party objects on your pages are incomplete or slow loading. Other times, you may only want to know about your own page objects, in which case you can easily select items served only from your own domain.
By selecting the ‘Any Component’ condition, you can create Alert Rules that trigger based on individual page components. Select the list of domain names for the component, such as ‘doubleclick.net’, and the threshold for the condition. You’ll most likely be interested in Total Fetch Time which measures how long the component takes to load, say 250ms, or Component Load which will trigger when the load is incomplete. Figure 4 shows an Alert Rule for DoubleClick ads.
CDNs
To monitor CDN-hosted components of your page, use the same alert configurations as you would for other third party objects. In this case, the domain will typically be custom for each of your CDN providers. In Figure 5, alerting on Intuit’s CDN provider Akamai requires each of the CDN-hosted domains to be listed. We’ll alert whenever Akamai fails to deliver components.
Web Transactions
Web transactions are straightforward to alert on. You’ll want to use conditions for errors, when the transaction does not complete, and for completion time. Let’s say we have a transaction with 3 steps: login, search and logout. We expect each to take 3 seconds. In Figure 6 we created an alert that triggers either when the transaction is incomplete or when it take more than 9 seconds.
What About Planned Maintenance?
For organizations that have planned maintenance windows, ThousandEyes now has Alert Suppression Windows that will ensure that you aren’t inundated by notifications when you take your application down for new releases. Just set your release window in your local time, set the recurring frequency and apply the window to tests which will be affected by your release schedule. In figure 7, alert suppression is enabled and recurs every other Tuesday.
Putting This Into Practice
You have a number of alert types you can create depending on your mix of availability, web server performance, network performance and third party objects.
You can get started right away with HTTP server, page load and transaction measurements with a free trial of ThousandEyes.