Frontend Performance Measuring & KPIs

Core Web Vitals, LCP, Cumulative Layout Shift, FID, Webpagetest.org, 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.

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.

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:

• Largest Contentful Paint (LCP)
• First Input Delay (FID)
• Cumulative Layout Shift (CLS)

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

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.

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.

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.

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).

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.

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

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.

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 webpagetest.org. 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.

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';

getCLS(console.log);
getFID(console.log);
getLCP(console.log);

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.