Analyzing Website Performance at a Glance

Zippy performance is a vital component of any website’s success. Quickly diagnosing site lag issues is critical but not always easy. In-browser tools like Firebug and Chrome’s developer tools can determine which page elements are slow to load, but not if a DNS lookup or redirect is taking way too long, and the data they provide cannot be stored to view page load trends over time. The Navigation Timing API, simple javascript that measures load times for each step in a page load’s lifecycle, provides the means to build an easy-to-use diagnostic tool that can be incorporated into any web analytic software. The only catch is that its support is limited to the vast majority of Chrome and Firefox browsers, IE9 and above and Opera 15 and above. Safari does not support it at all. However, adequately measuring website performance and fixing performance issues does not require data from every visitor, and the API works for more than 70 percent of most websites’ traffic.

Long ago, in the dark days before HTML5 and Carly Rae Jepsen, a common method of measuring load speed was to get the time (in milliseconds) that a page began to load and subtract it from the time it finished loading. Well, not quite finished, since the “loading finished time” was captured by a javascript method embedded at the bottom of each page. This was not cool, because the load complete time was not accurate. When measuring performance, milliseconds can count. More importantly, however, this method could not measure the load time of all the goings-on before the web page itself loaded, like the browser request, server connection and other network activity like our friendly neighborhood Mr. Navigation Timing API.

The performance data itself is captured by the window.performance.timing object.

            window.performance.timing.navigationStart  //The true beginning of page load

            window.performance.timing.domainLookupEnd  //The DNS lookup is finished

            window.performance.timing.loadEventEnd  //The page is finished loading

By themselves, these values do not mean much, but when combined to capture a complete page load picture, they provide a powerful performance snapshot.  The numbers below represent the load time of the home page for each page load step in milliseconds. They are captured in order of execution, except for the first value, which represents total page load time.


In order, here are definitions for each number:

  1. 4518: The total page load time.
  2. 0: Redirection time. If a page view was the result of a redirect, something like, this number would describe the time it took to complete the redirect process.
  3. 0: Application cache processing time. This is used for offline browsing.
  4. 0: DNS lookup processing time. In this instance, the DNS lookup was either cached or no lookup was necessary.
  5. 0: This represents the time it takes to connect to the server. If there are no server connectivity  issues, this number is either very low or, as in this case, zero, which occurs if the URL is cached or stored locally.
  6. 298: The time the browser takes to send a request for a site’s URL.
  7. 4: The time the server takes to respond to the browser request.
  8. 4207: The bulk of the load work is usually done here, because this represents the time it takes for the page code, images, stylesheets and any other related calls to load. Barring other types of connectivity issues, this should be the highest number in the string.
  9. 9: The time it takes for a window’s load event to fire.

If desired, there are three subsets of these values that might be measured: secure connection time, the time it takes to unload the previous page (as part of the server response time) and the document object model (DOM) content to load, separate from the full DOM processing time (No. 8 above). However, it might be a good idea to keep this page load string simple. Here is the fairly simple javascript code that can be used to pass all this information into one variable:

if (window.performance && window.performance.timing) {

var t = window.performance.timing;

            var pageLoadDetail = (t.loadEventEnd - t.navigationStart) + "|" + (t.redirectEnd - t.redirectStart) + "|" + (t.domainLookupStart - t.fetchStart)  + "|" + (t.domainLookupEnd - t.domainLookupStart) + "|" + (t.connectEnd - t.connectStart) + "|" + (t.responseStart - t.requestStart) + "|" + (t.responseEnd - t.responseStart) + "|" + (t.domComplete - t.domLoading) + "|" + (t.loadEventEnd - t.loadEventStart);


“pageLoadDetail” should be incorporated into a variable from the web analytics tool of choice. This way, page loads can be correlated with data like page names so that slow pages can be singled out for performance boosts. It is a solution that takes very little time to implement but can save lots of agonizing minutes or hours wondering why a website is more sluggish than driving a Yugo up Pike’s Peak.


By Jim Glauner
About the Author:

Jim Glauner is a Senior Consultant, Team Lead at Stratigent.

Contact Us Now