Essential Web Performance Metrics

Essential Web Performance Metrics

In last week’s post, Essential Web Performance Metrics — Part 1, we led off with a venerated stat from Amazon who reported in 2006 that for every 100ms improvement in response time, they received a 1% increase in revenue.

We then delved into the components that make up the traditional concept of response time, including DNS time, TCP connect time, HTTP redirect time, time to first byte, HTML content time, and full page object load time. In the process we pointed out the quandary of these network-side metrics: they can tell you where to look if you have a problem, but they don’t necessarily uncover the effect of the problem on your users.

So where do you look? When talking about speed improvements that translate into revenue, we’re talking about user perception — how the user is actually experiencing your website and applications. While these backend metrics can provide insight around specific technical problems that may or may not be increasing/decreasing overall page load and response times, there is no direct connection between their measurements and the user’s experience.

This post will introduce some new metrics you should be monitoring and how they contribute to the user’s perception, including:

Technically, page load time and DOM load time are browser timings, not user timings, but they help set the stage for what the user perceives.

Page load time represents the entire time it takes from the user command through the finished loading of the page and all referenced objects. It is the end-all, be-all of response time metrics as it includes all of the page’s documents, all referenced objects and scripts, style-sheets, and images. While page load time may seem important, it really isn’t because it includes everything — whether visible to the user or not. As we’ll see later, what the users don’t know won’t hurt them.

DOM load time is the time it takes to finish parsing the page’s documents beginning with the first byte, but not including referenced style-sheets, images and sub-frames.

It is the browser’s job to piece together each page element and load external files into memory.  The DOM, or Document Object Module, defines a standard way of structuring and parsing the elements of an HTML page, including text, i-frames, and the like so they can be logically assembled before being loaded.

The “DOMContentLoaded” event is fired when the document has been completely loaded and parsed without waiting for stylesheets, images, and subframes to finish loading. That means DOM load time is concerned with the structure of the page rather than its content. If, after a while, a website begins to bog down, it’s often because front-end blocks of code in the DOM become exaggerated or locked or refer to hidden bits.

A high number of DOM elements can be a sign that the markup of the page needs fixing without necessarily removing content. For example, throwing in extra <div>s only to fix layout issues can create unnecessary complexity over time. Increased complexity means slower DOM access in JavaScript. Having to loop through 1000 DOM elements versus only 100 can materially slow the DOM load time.

When simplifying a complex page, take note that differing parsing engines sequence the elements for assembly differently. Chrome, Safari, Firefox, and Opera may all load your page in different orders, which can make a difference to the user’s perception.

Bueller? Bueller?

A lot has been written about the impatience of Internet users, but nothing frustrates them more than being flat-out ignored.

First paint time measures the time duration from when a web page URL is entered into a browser window to the moment when the user sees the first burst of visual activity on the Web page in the browser window..

First paint tells the user that the site is responding to their action. How long will she wait? About as long as it takes to blink.  According to a New York Times article, if users don’t get that acknowledgement in 250 milliseconds — literally the time it takes to blink — they will abandon the site.

Once the first paint begins, the order in which elements load becomes critically important.  Web users spend 80% of their time looking at information above the page fold. Although users do scroll, they only allocate 20% of their attention below the fold.

Above-the-fold is where users focus, and it’s where you should focus too.

Above-the-fold time measures the time it takes for the visible page’s content to reach its final rendering, with enough intelligence to adapt for animated GIFs, streaming video, rotating ads, etc.

The first thing above-the-fold time tells us is that you shouldn’t set your site to load all the images when the page starts. A site’s assets should load in roughly the order of importance to the user, first loading content and images that are above the fold.

The good news is you can dramatically improve the user’s perceived response time without struggling to reduce the real response time at all. Simply reorder the execution so anything that’s not immediately important loads after anything that is.

In the end, web performance monitoring is like politics — perception is reality.  While traditional backend metrics can provide insight around specific technical problems, they don’t provide much insight into the thing that matters most: the user’s experience. By incorporating a few user-centric metrics in your WPM plan, you can quickly get a handle on opportunities to optimize your site in ways the directly translate into increased revenue.

See Also: