Eugenio Marongiu - Fotolia

Get started Bring yourself up to speed with our introductory content.

6 top webpage performance metrics to monitor

Webpage performance is paramount for digital success. To monitor webpage performance, use these top six metrics.

An organization's IT team is responsible for the speed and performance of its online experience. Most teams monitor performance with page weight calculations, or page load time, but there's a lot more to do.

Here are the six most important webpage performance metrics to monitor, and how they can improve the user experience.

1. Above the fold rendering

This metric -- also known as the speed index -- represents how quickly users can view the part of the webpage that displays before they scroll down. It's this pre-scroll part of the page that is referred to as above the fold -- terminology rooted in paper newspapers that fold up.

This metric represents the first time your page becomes useful to the end user. There's only one chance at a first impression. Even if your page is still rendering below-the-fold content or processing JavaScript events, the end user will feel like the whole webpage has been loaded. But there are two issues to account for when monitoring it.

This metric depends on the size of the user's view port. The amount of content that renders above the fold is different on a 1080-pixel-wide screen as opposed to an ultra-high-definition 4K monitor. Before you implement this webpage performance metric, agree on a standard port size to consistently evaluate the view.

This metric also lacks a background event or browser function for its calculation. IT teams need to use a tool that records the invocation of a webpage and then evaluate the time it takes for the page to completely render to obtain the metric's value. It can be a time-consuming task, but above the fold rendering is still worthwhile to track.

2. Webpage finally interactive time

Above the fold rendering is especially important for pages that display content. But for webpages that include input fields or clickable icons, simply rendering content above the fold isn't good enough.

There's no worse user experience on a webpage than when an unfinished script blocks a user's ability to fill in a form field or click a submit button. The finally interactive metric measures the point in time at which all input fields and clickable components work.

This metric is important on serial peripheral interface-based sites built with Angular or Ember. With these frameworks, page transitions happen inside the browser without triggering a new request-response cycle. For sites built with modern, client-side rendering frameworks, the finally interactive metric acts as a measure of when the user can navigate throughout the site.

3. Time to first byte

The number of milliseconds elapsed between a request sent from the client's browser to when it receives a response from the server is known as the time to first byte (TTFB). Generally, 200 milliseconds is considered a good TTFB value.

Unlike other webpage performance metrics, TTFB completely depends on an organization's network architecture and hardware performance, as opposed to the way architects and developers designed the webpage.

Some factors that can affect the TTFB include a slow network, servers that are overwhelmed by a high load and poorly designed network infrastructure. Any of these issues can push the TTFB value into the one to two second range. As a result, it can be difficult for organizations to meet a three or four second target for a full page load.

4. Server response time

This metric counts the delta between the TTFB and the time at which the browser receives the last piece of data from the server. It includes all images that are delivered, all CSS files received and any deferred JavaScript files downloaded.

Infrastructure plays a role in this metric, because powerful servers, content delivery network usage and an in-memory cache of static content all speed up server response times. Webpage developers can also help improve this metric with strategies such as page weight reduction, combining multiple JavaScript files into one, and use of inline CSS rather than linking to multiple external stylesheets.

However, if a user downloads all these files, it doesn't mean that they've all been processed. After the CSS files download, apply all the corresponding document object model (DOM) selectors. After the webpage downloads a JavaScript file, its onReady events still need to be executed. There may be a delay of several seconds between all resources that are downloaded from the server and the conclusion of the client-side rendering of the page.

5. DOM loading and processing

This DOM processing metric is a measure of how much time it takes for the browser to parse the downloaded HTML file, create the associated document object model within the browser, create and initialize the CSS object model and finally call the browser's DOMContentLoaded event.

Webpage structure and size have a big effect on this metric. A large HTML file with over 1,000 DOM elements can easily take three or four seconds to parse, and a CSS file with over 1,000 entries in it can slow down DOM processing. Just think about it: 1,000 DOM elements with 1,000 CSS entries would require the browser to do 1 million Boolean CSS selectors across the DOM. These file sizes can bring less powerful laptops and mobile devices to a crawl.

Organizations should reduce the size of the DOM and the number of CSS styles in use as the most straightforward way to improve the speed at which a browser loads and parses the DOM.

6. Webpage fully loaded time

The time for a webpage to fully load, often referred to simply as the page load time, is the most common metric used to evaluate webpage performance. The metric is fairly self-explanatory, as it calculates the time between the browser request for the page and the point in which all associated resources download, all images render, all CSS selectors are applied and every onReady JavaScript event has fired.

The fully loaded metric misses some of the nuances of the others for webpage performance, such as the finally interactive time or the time it takes to perform an above the fold rendering. These other metrics serve as better indicators of the user experience. However, the page load time is easy to calculate and easy to understand, and as such, is the one most often cited when page performance is a concern.

Webpage performance metrics to monitor

In review, the six most important webpage performance metrics organizations should monitor include:

  1. The speed index, also known as the above the fold rendering time;
  2. Finally interactive time;
  3. Time to first byte;
  4. Server response time;
  5. DOM loading and processing; and
  6. Webpage fully loaded time.

If an organization constantly monitors these important webpage performance metrics -- especially on the website's main landing page -- it will catch any pending performance issues, act before they become problems and ensure that clients have a consistently positive experience on the site.

Dig Deeper on Ajax Web development and Java client programs

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

SearchAppArchitecture

SearchSoftwareQuality

SearchCloudComputing

SearchSecurity

SearchAWS

Close