Create Custom Metrics for Web Performance Measurement
Steve Sounders has pioneered much of the work in the world of web performance. He is the author of High Performance Web Sites and Even Faster Web Sites. He is the creator of many performance tools and services including YSlow, the HTTP Archive, Episodes, ControlJS, and Browserscope.. [ref]
Comments and corrections are highly welcome.
There is no single metric that best measures site performance. The best practice is to find out the most important contents you want to present to users, and then create custom metrics and track the measurement yourself by user timing.
1. W3C Web Timing Specs
Understanding the basics of W3C Web Timing Specs, you’ll get a idea of the APIs that you can use to assist performance measurement.
Navigation Timing: This interface provides Web apps with timing-related info.
A set of attributes for performance.timing can be found here.
For instance, the following script calculates how much time to load a page since the most recent navigation.[ref]
Resource Timing: This interface facilitates timing measurement of downloadable resources. For example, XMLHttpRequest objects [XMLHttpRequest], HTML elements [HTML5] such as iframe, img, script, object, embed, and link with the link type of stylesheet, and SVG elements.
User Timing: Help performance measurement by giving access to high precision time stamps. It defines the PerformanceMark and PerformanceMeasure interfaces, and extensions to the Performance interface
Here is a good example that shows how to use user timing apis for mark, and clearMarks. [ref]
2. There is no single metric that best measures your site performance
Some popular metrics:
The time until the browser reaches the load event for the main document (onload) [ref]
Does not require that the UI is done loading, but is the first point at which the customer can interact with the UI using an input device. [ref]
As Steve explained in this article, loading js, css and fonts would undermine the reliability of your measurements
As pages grow and load a lot of content that is not visible to the user or off the screen (below the fold) the time to reach the load event is extended even if the user-visible content has long-since rendered.
speedIndex measures how quickly the page contents are visually populated ( lower numbers better).
The speed index takes the visual progress of the visible page loading and computes an overall score for how quickly the content painted. [ref]
Unfortunately, none of these are very good metrics of the actual end user experience. Indicated by the slide below, even when domInteractive, onload are available, user still might not be able to see the expected content.
3. The best practice for measurement:
Step1. define the most important element that user wants to see
Step2. measure using User Timing
Step1: Suppose you have decided that the most important element for users is the first twit with image and content.
Based on the selected elements, you want to handle the following cases:
- For image rendering, it takes time to download, and to be displayed. Assuming image is really large, and css is small/fast. For performance measurement, we’ll time from “navigationStart” to image fully displayed “img onload”(t1).
- By default, when stylesheet is downloading, it blocks the rendering. Assuming a stylesheet is very large and image is very small, even if image is finished onload, it would not be displayed, because the rendering is blocked. We needs to time from navigation start to inline script gets executed (t2)
- We’ll take the max out of t1, t2.
- user-timing-and-custom-metrics (Awesome article written by Steve himself)