Tracking Indicators

Of all the possible metrics, Google now identifies three so-called Core Web Vitals. These are the focal point for Google in the coming year. Every year, Google might add or change these metrics as they evaluate them over a longer time. 

The three pillars of page experience

For now, the three pillars of page experience are:

• Loading performance (how fast does stuff appear on the screen?)
• Responsiveness (how fast does the page react to user input?)
• Visual stability (does stuff move around on the screen while loading?)

To measure these essential aspects of user experience, Google chose three corresponding metrics — aka the Core Web Vitals:

• LCP, Largest Contentful Paint: This measures how long it takes for the largest piece of content to appear on the screen. This could be an image or a block of text. A good grade gives users the feeling that the site loads fast. A slow site can lead to frustration.
• FID, or First Input Delay: This measures how long it takes for the site to react to the first interaction. This could be a tap on a button, for instance. A good grade here gives the user a sense that a site is quick to react to input and, therefore, responsive. Slow, again, leads to frustration.
• CLS, or Cumulative Layout Shift: This measures the visual stability of your site. In other words, does stuff move around on the screen while it is loading — and how often does that happen? Nothing more frustrating than trying to click a button when a slow-loading ad appears in that spot.

The three Core Web Vitals and their scores

Google’s John Mueller has said that all three metrics must appear green if you want your site to get a ranking boost. Note, of course, you shouldn’t optimize your site to get green scores — but having green scores absolutely will be beneficial for your visitors. It’s all about happy visitors — and great content, of course!

While the Page Experience update is coming soon, it probably won’t have a massive impact from the start. Google’s Danny Sullivan has said that it will be introduced gradually and that it might become more important over time.

What are these Core Web Vitals?

The Core Web Vitals don’t work in isolation, as there are many other metrics. Some are based on controlled lab tests, while others are metrics that only work with field data. After doing a lot of research, Google determined a new set called Web Vitals. These are a combination of metrics we already know, plus a set of new ones. The three Core Web Vitals are the most important ones, and Google is specifically asking site owners to keep an eye on these scores and improve them where they can.

LCP: Largest Contentful Paint

Largest Contentful Paint measures the point at which the largest content element appears on the screen. Keep in mind that it doesn’t measure the time it takes for your page to load fully, but it simply looks at when the most important part loads.

If you have a simple web page with just a piece of text and a large image, that large image will be considered the LCP. Since this is the largest piece of content to load in the browser, it’s destined to make an impression. By getting that to load quicker, your site can appear much faster. So, sometimes, it might just be as simple as optimizing that image itself. 

In the past, there were metrics like First Meaningful Content, which measured the time when the first piece of content appeared on the screen that meant something to the user. Unlike the name suggests, the FMC metric often couldn’t figure out the most meaningful thing that appeared on the screen. Complex metrics lead to useless data.

Largest Contentful Paint is easy to understand: it is simply the time it takes for the largest element to appear on the screen. These elements might include images, videos, or other types of content. 

What you need to know

Now you know what the LCP is, you can start optimizing for it. According to Google, you should aim for the LCP to happen within the first 2.5 seconds of the page loading. Everything under 4 seconds needs improvement, and you can consider everything over that as performing poorly. 

An overview of the scoring for LCP

The LCP is also dynamic, as the first thing that loads might not immediately be that large image. The LCP shifts to that large image when that appears on the screen. 

Here’s an image from Google that explains how the works:

This image from Google gives you a good idea of how the LCP is measured

On the left, you first see the logo and ‘Visual stories’ line appear. In the second screen, the large headline appears as a candidate for LCP. In the last screen, however, you see that a big image overtakes the header as LCP. If you have just one big piece of content, that might be the LCP the whole time.

If you look at the image’s loading process, you can easily see why this is such a handy metric. You can easily spot what the LCP is and optimize the loading of that element. 

Google offers several tools to help you find all these elements. PageSpeed Insights, for instance, offers a wealth of data on Web Vitals, plus a whole lot of advice to improve your page.

PageSpeed Insights identifies the large header image as the LCP on on our site

According to Google, the LCP is affected by a number of factors: 

• Slow server response times: optimize your server, use a CDN, cache assets, et cetera.
• Render-blocking JavaScript and CSS: so minify your CSS, defer non-critical CSS, and inline critical CSS.
• Slow-loading resources: so optimize your images, preload resources, compress text files, et cetera.
• Issues on client-side rendering: so minimize critical JavaScript, use server-side rendering and pre-rendering. 

FID: First Input Delay

The First Input Delay measures the time it takes for the browser to respond to the user’s first interaction. The faster the browser reacts, the more responsive the page will appear. If you are looking to offer your users a positive experience — who isn’t? — then you should work on your pages’ responsiveness. 

Delays happen when the browser is still doing other work in the background. So, it has loaded the page, and everything looks dandy. But when you tap that button, nothing happens! That’s a bad experience, and it leads to frustration. Even if there’s just a small delay, it might make your site feel sluggish and unresponsive.

A browser has to do a lot of work, and sometimes it needs to park certain requests, only to come back later to them. It can’t do everything all at once. As we’re building ever more complex sites — often powered by JavaScript — we’re asking a lot from browsers. To speed up the process between getting content on the screen and making it interactive, we need to focus on the FID. 

The FID measures all interactions that happen during the loading of the page. These are input actions like taps, clicks, and key presses, but not interactions like zooming and scrolling. Google’s new metrics call for an FID of less than 100ms to appear responsive. Anything between 100ms and 300ms needs improvement, and you can view anything above that as performing poorly.

After testing the FID you get a score and you can work from there

What you need to know

One of the things you need to remember is that you cannot measure the FID if there is no user interaction. This means that Google can’t simply predict the FID based on the data they have from the lab — they need data from real users or so-called field data. This also means that this data is less controllable than lab data as it collects data from users will all kinds of devices and who uses it in different ways and environments. This is one of the reasons why you sometimes see data change.

If you are looking to improve your scores, you will often find JavaScript to be the culprit of bad grades. JavaScript helps us build awesome interactions, but it can also lead to slow websites with complex code. Often, the browser cannot respond to input while it is executing JavaScript. If you improve your JavaScript code and its handling, you are automatically working on improving your page experience scores.

This is the hardest part, though. Most sites can gain a lot by reducing the time it takes to execute JavaScript, breaking up complex tasks, or removing unused JavaScript.

You should look at your scores and determine what you can do. Try to find the improvements that are easiest to do or result in the biggest performance jumps.

There are always improvements to make, but you have to decide if that’s worth it — or even possible

CLS: Cumulative Layout Shift

This metric tries to determine how ‘stable’ stuff loads onto your screen. It looks at how often stuff jumps around while loading and by how much. You can imagine that sometimes a button loads on the screen, inviting users to click it. In the background, however, there’s still a large content area being loaded. The result? When the content finally fully loads, the button pushes down a bit — just as you want to hit that button. Again, frustration mounts!

These layout shifts happen a lot with ads. Ads are a lifeline for many sites, but these are often loaded so poorly that they frustrate users. Also, many complex sites have so much going on that these are heavy to load, and content gets loaded whenever it’s ready. This can also result in content or CTAs that jump around on the screen, making room for slower loading content. 

What you need to know

The Cumulative Layout Shift compares frames to determine the movement of elements. It takes all the points at which layout shifts happen and calculates the severity of those movements. Google considers anything below 0.1 good, while anything from 0.1 to 0.25 needs work. You can consider everything above 0.25 as poor. 

The scores for CLS

Of course, the score only looks at unexpected shifts. If a user clicks the menu button and a fold-out menu appears, that doesn’t count as a layout shift. But if that button does call a big change in design, you should make sure to keep that clear for the user.

Slowness is added in every step, and you have to work hard to get your ads to appear in the right spot at a moment’s notice. But there’s another element that’s responsible for large layout shifts: images.

Developers don’t always specify the width and height of an image in the code and leaving it up to the browser to figure out how the image should appear on the screen. On a page with some images and text, the text will appear on the screen first, followed by the images. If the developer hasn’t reserved space for these images, the top part of the loading page will be filled with text, prompting them to start reading. The images, however, load later and appear in the spot where the text was first. This pushes the text down, getting the user agitated. So, always specify the width and height of the CSS images to reserve a spot for the images to load.