×

One common question we hear from Rigor users is, “What performance metrics matter? Which ones should I pay attention to?”

While there are some universal performance metrics that almost everyone should track, the metrics that matter most to you could vary based on your industry or business goals. Metrics are not “one size fits all.” Some metrics go by multiple names. This article will define and explain some common performance metrics, so you can understand what metrics make sense for your team.

Three Universal Performance Metrics

For most sites and applications, teams rely on three key performance metrics to determine page performance: page load, render time, and server time.

Page Load

The most common metric for gauging overall performance is Page Load. In terms of JavaScript, this means how long until the window.onload event handler fires in the browser. Users typically expect a site to load in two seconds or less. Search engines penalize pages with slow load times.

Remember: it is possible to defer some content to load after the onload event fires. Typically developers defer elements such as advertising content or third-party scripts to load in after the onload event. Your team may want to compare Page Load timings to Page Fully Loaded timings. Page Fully Loaded would represent the time from the start until there was no network activity after Document Complete and would include dynamic requests triggered by JavaScript after the onload event fires.

Render Time

Page Load time tells us when the entire page loads, but it doesn’t give us information about when the user can see something. Evidence shows that perception matters. Render Time is a great measurement that helps us understand when a visitor begins to perceive the page loading. 

There are a couple of different ways to look at Render time. Rendering isn’t a single-instance event, but it starts and then completes. We can either look at the event that fires in the browser that indicates when the browser is ready to begin rendering content, or we can look at when rendering starts to take place. 

  • DOMContentLoaded: an event that fires when the initial HTML document has been completely loaded and parsed; this is generally when HTML renders, but might not include stylesheets or images
  • Start Render Time, sometimes called Time to First Paint (TTFP): the time from the start of the initial navigation until the first non-white content is painted to the browser display

Whether using a free tool or a paid tool, make sure that you have some consistent method for comparing Render times against Page Load times. This will help you understand how quickly content is shown to a visitor and how long the visitor has to wait for content to finish loading in.

Usually, slow Render times indicate issues with render pipeline due to your JavaScript or CSS files. If that is the case, optimizing these resources will leave a better impression on your user, while also improving your page’s search engine rankings.

Server Time

When we look at the Server Time we’re looking for the time it takes for the server to respond to the initial request. This metric is similar to Time to First Byte (TTFB), or the amount of time that elapses between the user’s initial HTTP request and the user receiving the first byte related to that request. Both measurements indicate the responsiveness of a web server.

While slow server times usually aren’t the cause of page load bottlenecks, faster server times indicate well-configured server applications. Some servers will have higher server times or TTFB sizes, especially if the page requires large requests from a database.

Because the first resource that the user receives is the base HTML file, many use TTFB as a proxy for backend processing time. This includes the time it takes for your application tier, database tier, and so on to respond. Additionally, this metric appears to be highly correlated to where your site shows in search engine results. Faster TTFB numbers yield higher search engine rankings.

 

image02

Rigor’s monitoring service can provide detailed information on your page’s load times.

Performance Metrics for the Bigger Picture

While it’s critical to track server time, render time, and page load time, there are some other metrics that may help your team gain a more complete understanding of how visitors see pages on different devices or how to design pages with performance in mind. Let’s look at a couple of additional performance metrics that may be helpful to measure.

Speed Index

In April 2012, Google added Speed Index to its WebPagetest for measuring the performance of various web pages. Google defines Speed Index as the average time at which visible parts of the web page are populated and displayed.

Speed Index is measured in milliseconds and is dependent on the size of the view port. Rather than just looking at when the user receives the first byte, Speed Index measures how fast the user receives viewable content. WebPageTest captures video of the page as it loads. Then, the tool inspects each frame to see how much content has been loaded. Currently, the test analyzes ten frames gathered each second.

image01

Source: Google

The Speed Index metric is useful for measuring a user’s experience. Because Speed Index is based on the percentage of the viewport, you can compare sites across multiple devices.

Page Weight / Performance Budgets

A performance budget is a set of limits that a team sets to guide design and development. The budget may be comprised in terms of page size or load times. For example, your team may say “Images should not comprise more than 20% of our page size” or “Images should only account for .5 seconds of the total page load size.”

When using performance budgets, consider the volume of data related to your site. Paying attention to page size can help your team identify unoptimized pages, redundant resources, or overly large scripts. Make sure that your organization’s best practices are followed by making them a fundamental part of the page’s design.

image00

For a given page, Rigor can provide details on the resources required to load it, as well as the time spent by the browser on acquiring and rendering that resource.

Industry-Specific Metrics

Some industries and companies have more specific aspects of their site’s performance they like to track. To do this, they usually use some combination of synthetic monitoring and user analytics or user timing APIs. You may find these metrics helpful for identifying issues with and improving the performance with your site.

Time to Complete a Transaction

While most of the performance metrics we’ve covered so far relate to a specific page’s load, we often need to measure a user’s ability to complete multiple steps across multiple pages. Synthetic monitoring tools allow teams to configure multiple step simulations that can navigate across multiple pages and the sum the response time for the whole series. This can help teams get a more complete understanding of how long it takes to complete a transaction, such as searching for a product or making a purchase.

Time to Video Playing

Many of Rigor’s media clients embed videos that autoplay within their news stories or show live broadcasts. If you have something similar on your site, this metric is useful for determining how quickly it takes for the user to see the video play. Video resources are expensive in terms of time to load on a page. Load videos as quickly as possible to ensure that people see them as quickly as possible.

Time to First Ad

Ads are a common source of revenue. If ads take a long time to show, users have less time to look. This directly results in decreased revenue, due to less user engagement with the ad. Track the amount of time it takes until the ad is first rendered to the user. If ads aren’t rendering quickly enough, change the way they’re prioritized to render on the page or work with an ad network partner to improve their performance.

Time to First Interaction

Google’s Speed Index, among others, try to measure the user’s experience. Generally, these metrics only look at things the user has little control over. At the same time, the user is typically doing things like scrolling up and down the page, clicking a link, moving the cursor over different objects, and so on. Gauge real user experience by measuring interactions.

To do this, you can add assorted JavaScript events and handlers to your page to measure your user’s engagement and activity levels. This can also provide information such as “dead spots” on your page, or areas that are neglected or unseen. At best, such areas merely slow down your page by requiring your to render things that are unnecessary. At worst, these areas include ads, links, and so on, and the limited engagement with these items is decreasing your revenue.

Time to First Meaningful Paint

While measuring the amount of time it takes for the user to receive a byte is useful information, displaying just a pixel isn’t helpful. As such, Time to First Meaningful Paint provides additional detail by indicating how long it takes for a user to receive a meaningful image. Define what images are meaningful. Use custom timings to measure performance of those images.

Conclusion

Metrics can help you discover opportunities to improve performance. But, you must understand how your metrics relate to user experience and performance management as a whole. There are always trade-offs in performance. It can be easy to forget about the impact to the end-user when we’re focused on moving the needle. Start by trending the basics – server time, render time, and load time. Then watch to make sure these don’t creep up after deploying changes. Finally, look to track specific metrics that relate to your industry or business KPIs.

Rigor can help you proactively track key performance metrics such as server time, render time, load time, page size, time to complete transactions, and more. Book a kickoff call to walk through the app and start your trial today.

Suggested Blog Posts