Skip to main content
Frontend Performance Measuring & KPIs

Frontend Performance Measuring & KPIs

Frontend performance really matters for user experience, conversion, and of course good old SEO. To build fast websites you need to have the performance metrics and KPIs defined.

Woman looking at display with charts and diagrams

Core Web Vitals, LCP, Cumulative Layout Shift, FID,, Google Lighthouse, Pagespeed Insight. I’m sure you’ve stumbled upon one of these in your quest to improve frontend performance, right?

But how do you measure performance? And why do you need to be data-driven, and continuously optimize and build a culture of performance testing and optimization?

Let’s explore that. Let’s go millisecond hunting.

Determine Your KPIs

Frontend performance KPIs, or Key Performance Indicators, are the first thing you need to establish before you start to measure or improve. With your KPIs in place, you have defined the game's rules in your organization, establishing a common language that you use in front-end performance subjects.

I highly recommend that you choose KPIs that are common in the industry. With that, you get the benefit of a vast selection of measurement tools available, and you focus your attention on the same metrics as Search Engines since they factor in speed as part of the page ranking.

The best option for this at the moment is the Core Web Vitals. Core Web Vitals does not encompass all the available frontend performance metrics, but they include the most important ones that can be reliably measured.

Core Web Vitals

In May 2020, Google announced new metrics to measure the quality of user experience on the web by quantifying the Core Web Vital metrics. Measuring core web vitals is the key metric added to the various tools to measure frontend performance and page speed.

The Core Web Vitals consist of (as of the time of this article) three different metrics:

You can identify these three metrics as a part of a performance audit done with the popular online performance tool Pagespeed Insights.

Field Data vs. Lab Data

The three Core Web Vital metrics are represented in the image above. Make a note of the heading Field Data. This indicates that these performance audits have been pulled from actual users on the target website (collected automatically when using Google Chrome). These numbers reflect actual experiences that the users are getting and are also what Google uses as part of the page ranking algorithm.

When measuring performance, there are a lot of factors that influence the results.

  • The device (laptop, cell phone)
  • The network type (wifi, cellular, cable)
  • The network health (at home or a busy café)

A rule of thumb here is that the device's speed and network is a primer for the performance result. You can get vastly different results for the same website if you’re testing with a different device or over a different network setup.

On the other hand, Lab Data is not based on actual user reporting but on a single test run using a simulated device on a throttled network.

Lab data is not what your users see and is not used by Google in their ranking algorithm. It is only useful for developers who can use the results of a single test to check if changes in the code had any impact on performance.

In other words, super useful for the developer in the middle of analyzing how changes to the code affect frontend performance, but not at all relevant when telling the world how fast your site is.

Performance KPI 1: Largest Contentful Paint

As the most influential of the Core Web Vitals, Largest Contentful Paint makes up 25% of the total Lighthouse score, making it the number one frontend performance KPI. It measures the time it takes for the largest portion of the visible screen to be displayed and painted on the user’s device.

Performance KPI 2: Cumulative Layout Shift

Claiming 15% of the total Lighthouse performance, Cumulative Layout Shift is now established as an important metric that you should not ignore. It measures all the small and large “jumps” in the layout during the page load phase. You want to keep this score as close to 0 as possible, as a score of 0 indicates that the layout did not change at all.

Performance KPI 3: First Input Delay

First Input Delay measures the delay the user experiences upon their first input on the webpage. Input in this context is clicking on a button, link, or using a javascript-powered feature. Most users would not enjoy interacting with your web page, only for nothing to happen afterward. A score of 0 is the best you can achieve here, with no measured delay for the user. You want to keep it under 100ms to stay in the green performance zone.

Interestingly enough, FID is not used in the Lighthouse performance scoring. The reason for this is that the Lighthouse Lab tests cannot correctly simulate what actions users might be doing, never interacting with the page, thus making it impossible to measure FID.

If you want to improve FID, you should look at another metric on the Lighthouse Performance Report: Total Blocking Time (TBT).

Total Blocking Time

Total Blocking Time makes up 30% of the total Lighthouse performance score, making it the most influential metric. It is, however, not part of the Web Vitals, and it is not recorded as part of the Field Data for your website. It is on the other hand a good indicator when doing one-off Lighthouse tests for the First Input Delay.

TBT measures the time a user is blocked from doing interactions at the critical page load time and is a metric that you want to get close to as 0 as possible.

A score of 0 indicates that the user is not blocked, whereas a score of, let’s say 1000, indicates that there was an accumulated time of 1 second where the user was blocked. Not a very good user experience. You typically want to keep this number below 300 to ensure a happy journey for the user.

Comic strip illustrating the frontend performance metric Time to Interactive

Other Performance Metrics

These three metrics are the most important ones when you define your performance KPIs. There are a bunch of other metrics (speed index comes to mind), and they all serve a common purpose: to improve the experienced speed for the end-user. Frontend performance is an important factor of digital product design, and the metrics described above measure just that.

When optimizing frontend performance, you also need to monitor the performance of your back-end. For example, with a headless commerce approach, you need to make sure your back-end has a fast ecommerce API.

How to Measure Frontend Performance?

So, I talked about the Field and Lab data. Now, let’s see which tools you can use to measure frontend performance.

Pagespeed Insights

As most accessible tool out there, Page speed insights is web based, uses Lighthouse behind the scenes. It can be used by anyone in your organisation, and is a good place to start.

Chrome Devtools

Open Chrome dev tools, go to the Audits panel, and run a test with the Performance checked. It uses Lighthouse in the background and gives back a range of metrics, with the Core Web Vitals taking center stage.

Use this instead of Pagespeed Insights if you desire an even more detailed report, and it is very useful for local development.

Now, if you want to dive into the details of how your website performs, visit It is an online service that provides page tests on a fleet of servers located in different places worldwide. The audit reports you get back shows you with incredible detail all the things that happen behinds the scene of a page load and can be very useful if you want to debug a particular frontend performance problem.

It is also very handy when you want to perform tests where you are interested in the metrics measured from a particular region around the globe.


GTMetrix is another awesome website performance analytics tool. It's built to help you analyze the performance of your website and provide you with a list of actionable recommendations to improve it. Bunch of cool features like Speed Visualization, Waterfall Chart, and even Video for paid users.

Web Vitals Javascript Library

If you want to track your site visitors, I recommend the web-vitals library. It’s easy to use and integrates well with whatever frontend solution you might be running:

import {getLCP, getFID, getCLS} from 'web-vitals';


The data from the user timings API can be collected for all your users and sent to an analyzing tool, such as Google Analytics. From there, you will get a crystal clear image of how your site is performing for your user base, and you can get valuable information in reports by correlating measured frontend performance with things like conversion rate.

Optimizing for frontend performance is not something you do once and then don’t have to worry about it again. It’s an ongoing effort that requires commitment from everyone involved. Browsers evolve, devices get faster, and the way we craft websites changes as well.

What never changes, though, is the importance of a friction-free user journey, where you put the user first and never compromise on performance. And on top of that, performance has become one of the search ranking signals, which means it is now effectively a part of your SEO efforts (especially for eCommerce SEO).

Our friends at Snowball did a blog post on why fast websites increase sales.

Remember, milliseconds matter.

You Should Also Read👇

Keeping Websites Fast when Loading Google Tag Manager

Keeping Websites Fast when Loading Google Tag Manager

Google Tag Manager can influence your overall website performance just as any other external 3rd party script. Luckily, there are a couple of things that you can do in that regard.