Google Web Vitals - Measuring your Frontend Performance

When you build a website or web app, there are so many factors to consider that it can be hard to know how you can actually measure its success. For example, is success measured by the users' feedback, how many features it has or its volume of traffic? This is just a handful of ways of how you can get feedback and neither really tells the developer if the code itself needs improving.

You could have a web app with numerous features and a jaw-dropping design, but its codebase could be completely cluttered with unnecessary JavaScript code, leading to a longer than usual loading time. In which case it would actually have a knock-on effect on the user experience as well as its SEO performance, causing a lower ranking on the Search Engine Results Page. So how do you test this?

Enter Google Web Vitals . These are a set of metrics provided by Google to offer guidance to the developer on how to measure the user experience. For example, its three core metrics are: Largest Contentful Paint (LCP), Interaction to Next Paint (INP) and Cumulative Layout Shift (CLS). Let's break these down.

LCP is the render time of the largest node on the landing page. It often corresponds to an img, h1 or div HTML element. When you perform this test, it will tell you which element on your page is the LCP - for example, in the screenshot above , you can see it's the image element on my homepage. In order to do this yourself, just open the Chrome developer tools, go to Performance and click on the Start Profiling button (an icon in the shape of a circle with an arrow on the end of it). So why is LCP important?

As this measures your landing page's largest node, it essentially is analysing the loading time of the element that will take the longest to render. Therefore, it is a good indication of the general loading time of your website, as it measures the biggest offender, on the HTML page, for slow loading times so to speak. Google states that a good loading time for LCP is below 2.5 seconds. Anything that takes longer than this but is faster than 4 seconds, needs improvement. And a LCP that takes longer than 4 seconds to render, corresponds to bad performance. Again if you look at the screenshot of my website, you'll see that the loading time of the LCP is 0.155 seconds (154.6ms). So I don't need to worry.

Excessive JavaScript code can be one of the culprits of long LCP loading times. If the app uses Client-side rendering, the JavaScript code needs to be executed first before any HTML element is rendered. This is why conditional rendering and asynchronous fetching are important. When you fetch data from a database on a webpage, this process, if not handled correctly, can delay or even stop the rendering of the HTML elements.

Then you have INP, which is a metric that analyses a page's responsiveness to a user's interaction. Think of when a user clicks a dropdown menu or clicks on a button that executes a function. It measures the time between the user initiating the interaction, and the page responding. Testing it is a bit more complicated. Again on the performance tab of Chrome Developer Tools, you click on record and execute the interaction you want to test. Here is a more detailed explanation of the process .

Similarly, Google sets guidelines for how long this metric should be. It is more strict in this case as a response of longer than 500ms is consider poor, and anything above 200ms needs improvement.

Lastly, we have CLS which essentially measures the shifting of HTML elements between page loads. This can get quite complex if explained in detail, but I'm sure we've all experienced a poor performing CLS score. Think of a time when you've been on a webpage and have been bombarded with popup adverts. When you click on the cross ic