This is a continuation of a series of blog entries on this topic. The series starts here.
Real User Measurements (RUM)
The other way to obtain client-side Page Load time measurements – and one that is becoming increasingly popular – is a tool that measures page load time from inside the browser. The web browser-based performance tools we have looked at like ChromeSpeed or the corresponding Network tab in the Internet Explorer Developer Tools measure page load time from inside the web client. But, as we saw, those performance tools function like YSlow, requiring you to have direct (or remote) access to the web client. Real User Measurements refer to measurements of how long it took to access your web site acquired from inside the web browser running on your customers’ machines and operated directly by them. Those are the real users whose experience with our web sites we want to capture and understand.
Currently, measurements based on the timing of synthetic web requests are beginning to be superseded by Real User Measurements, or RUM for short, which access timing information directly from inside the web browser. Now that there is a standard interface, known as the Navigation/Timing API, adopted in 2012, it is markedly easier to gather web client response time data directly from your web site’s customers.
Listing 1. Accessing the DOM’s performance object in a Load event handler.
Among the popular tools that use this measurement technique is Google Analytics, a tool that Google supplies free of charge to smaller sites that captures and reports on many kinds of web page usage statistics, including the SiteSpeed timing data that measures Page Load time. Google Analytics introduced the SiteSpeed measurements in 2010. The SiteSpeed data is sampled by default, by the way. Unless you change the Google Analytics defaults (see documentation on the _setSiteSpeedSampleRate() for details), SiteSpeed data is sampled at a 1% rate. There is even a free Google Analytics plug-in for WordPress-based web sites that makes it very easy for small and medium-sized businesses with limited technical resources to start utilizing the company’s web analytics reporting suite.
To help make gathering the SiteSpeed measurement data more reliable, Google put its weight behind a proposal to the W3C, the standards body responsible for all web technology and protocols, to add a standard Navigation Timing object to the DOM and then implemented that API in Chrome. Shortly after the Navigation Timing API was submitted to the W3C by Google, Microsoft, Yahoo and others, it was adopted by all the major web clients, including Chrome, Internet Explorer, Firefox, Safari and Opera. (For details on support of the API in different browsers, see http://caniuse.com/nav-timing.)
In the next post, I will take a closer look at the Navigation Timing API.