Measuring Load Time: Today’s Web Demands a New Standard

Nov 02, 2011 - Krux Engineering - 0
  • Twitter
  • Facebook
  • MySpace
  • StumbleUpon
  • Reddit
  • Slashdot
  • Digg
  • Del.icio.us
  • E-mail

Today's guest blog is from Krux engineering.  Read on...

Everyone agrees – consumers and website operators alike – that page load time is a primary driver of user satisfaction when visiting a website.  It’s been widely shown that consumers are more likely to leave a site based on slower load times, and that of course translates into lost revenue for the site’s operator.  Based on a study of latency in web applications by the Aberdeen Group, a one second delay can:

  • reduce customer conversions by 7%,
  • decrease customer satisfaction by 16%, and
  • decrease page views by 11%.

What this means for a typical online service provider, based on an upcoming performance benchmarking report by Krux:  a 40% improvement in page load time could drive at least 10% more transactions and 20% more traffic.

So, here’s something that’s been on my mind lately:  Why is there still no universally accepted metric for measuring latency on websites?  While in many ways the ‘business’ of measurement is in a state of evolutionary flux, I believe that right now is the right time for the leaders in the online world to reach consensus on a sensible standard to which we can all hold ourselves accountable.

 

Standards Are Lacking

Historically, the closest thing to an industry standard for page load measurement is Total Network Time.  This is mostly due to ease of measurement: it can be done at the http socket level and isn’t dependent upon a browser event.  While some have moved on from this increasingly archaic measure, others have not.   

However, there are several drawbacks to relying on Total Network Time to gauge site performance. 

  • It doesn’t account for CPU time impacting load performance.
  • It doesn’t accurately reflect the user experience, being somewhat divorced from content load events on the page.
  • It unfairly penalizes pages that intelligently delay certain types of content until after page load in the interest of user experience (e.g., Krux SuperTag or Lazy Loading image libraries).

 

The Current State of the Art is a Good Start

The good news is that Total Network Time isn’t the only option.  The current state-of-the-art for capturing timing is demonstrated well by this blog post.  Essentially, a JavaScript timer is set to start at the top of the page and the window.onload event is fired at the end, with the difference representing load time.  Several other important page event metrics can be calculated in the same manner (such as ‘Above The Fold’ or ‘Content Ready’). 

But with this method and any of the possible measures or metrics, the page-level JavaScript deployment approach is imperfect. 

  • There is almost always Inconsistency across browser types.
  • One cannot measure anything that happens before the start timer is executed in the top of the HTML (e.g. dns time, server response time, redirect time, etc.).
  • Overhead is incurred for additional JavaScript to be loaded.
  • They can be can be cumbersome to tag, and the measurements themselves can be inaccurate due to JavaScript timer problems.

 

Now, Enter HTML 5

Recognizing these deficiencies, the performance community is starting to push a new W3C standard that will be implemented in HTML 5.  You can see it demonstrated here, on HTML5 Rocks.  This new standard in measuring page load events overcomes the inherent challenges by relying on native JavaScript implementation at the browser level. 

This proposed timing spec has many advantages, most importantly, it:

  • provides standard and consistent measurement across different browsers types (including Internet Explorer 9+, Firefox 7+, and Chrome 6+),
  • allows several event timings to be measured and captured without any incremental instrumentation overhead, and
  • delivers a timestamp when a particular event is fired at the millisecond level.

This works by accessing the window.performance object via JavaScript, which then gives you a time stamp down to the millisecond for the firing of a particular page load event.  For example, to calculate the time from when the user first hits the page to when the browser’s window.onload event fires, one would use the following.

         <script> var elapsedTime = performance.timing.loadEventStart - performance.timing.fetchStart; </script>

This HTML 5 approach allows many different timing markers to be measured, beyond just window.onload.  The following diagram illustrates the various event timings that are supported and their relative firing order (source: W3C).  A complete list of events and their descriptions can be viewed at the W3C's timing spec.

Among all of these events, the window.onload marker is Krux’s preferred standard measure.  It is calculated by comparing the difference between the loadEventStart event and the domLoading event, which ensures that the measurement focuses on front-end page load times.  Thus, it is well correlated to actual end-user experience.

Further, given the broad-based browser support for the W3C/HTML 5 measurement approach, the window.onload statistic will both be stable across browsers and prove super-compatible with market-standard measurement tools like Google Analytics.  And it's worth noting, it is becoming an increasingly important statistic for the search rankings of Bing and Google.

 

Our Challenge to the Industry

Simply put:  Why isn’t the entire industry embracing the more reliable metrics and measures that are available right now? 

Continued reliance on something like Total Network Time, a measure disconnected from ‘real world’ page- and browser-level dynamics, is just wrongheaded.  The emerging W3C measurement standards overcome the cross-browser and page-level challenges once inherent to JavaScript measurement approaches.  Further, it is widely accepted that the window.onload event is more closely aligned to user experience than other possible measures.

The measurement challenges of the past have been solved – and not just in the lab.  These new approaches have been tested out in the wild, against real-word scenarios, and have emerged as the logical choice.

The time is now for the industry to move – and move fast.  Krux is embracing this change.  Will you join us?

Here's what other people had to say

There are no comments yet... be the first!

What about you?

Name

Email

Remember my personal information
Notify me of follow-up comments?

Website