Understanding and optimising Core Web Vitals [Guide]

In this article, I'll explain what Core Web Vitals are, why they're important as SEO KPIs and how to improve them for SEO.

I'll try to explain it in a way that really anyone can understand, because unfortunately a lot of Google's documentation is geared towards web developers. While web developers are perhaps the most important audience, everyone in the marketing and SEO community should have a basic understanding of it.

What are the Google Core Web Vitals?

The easiest way to think of Core Web Vitals is as a combination of three metrics that Google uses to measure how well a website performs in terms of page or user experience.

Since June 2021, these metrics have been included in Google's ranking algorithm, which means that websites that provide a good user experience will rank higher and websites that don't may rank lower.

Update: The Google Core Update 2024, which places even more emphasis on user experience, emphasises the importance of Core Web Vitals once again.

The 3 metrics of the Core Web Vitals

Image source: Chromium Blog

Core Web Vitals consist of 3 metrics that measure certain aspects of the page experience or loading time. These metrics include:

• the perceived loading speed/loading time, measured by Largest Contentful Paint
• the visual stability of your web pages, measured by Cumulative Layout Shift
• interactivity and responsiveness, measured by First Input Delay

The CWV - part of the page experience

Like many other Google ranking factors, the Core Web Vitals cannot be considered independently of each other. They are part of Google's page experience ranking signals, which also include factors such as mobile-friendliness, secure browsing, HTTPS and intrusive interstitials, i.e. pop-ups. In other words, all those factors that promote user-friendliness and user experience.

image source: Chromium Blog

Are Core Web Vitals an important ranking factor?

Nobody yet knows exactly how big the impact of Core Web Vitals will be on SEO and thus on the ranking of websites, as they were only elevated to the rank of a ranking factor with the Google Page Experience Update in mid-June 2021.

Regardless of this, it is still worth improving them, as page speed and user experience also improve the bounce rate, dwell time and conversion.

According to Google, users are 24% less likely to abandon a page if a website fulfils the optimal thresholds for the 3 Core Web Vitals metrics.

In addition, 22% fewer abandonments were recorded for new pages and 24% fewer abandonments for shopping pages.

Astonishing result of a study on the Core Web Vitals

The result of a study by Searchmetrics is all the more astonishing. Two million URLs that rank in the top 20 Google results for Germany, the USA and the UK were examined and their Core Web Vitals results analysed. This study revealed that, incredibly, only 4% of websites scored well in all 3 Core Web Vitals. 96% did not.

Understanding the two main data types of Core Web Vitals

Before we get to the 3 metrics and how to optimise them, you need to understand the two main data types for the Core Web Vitals metrics.

The two types of data are field data and lab data.

Field Data

field data includes real user metrics and is generated from the Chrome User Experience Report, also known as CrUX.

Basically, Google takes data from Chrome users who have opted to share information such as browsing history. This data is then used to calculate the 3 Core Web Vitals metrics, which are designed to provide insight into how Chrome users experience the web in real life.

You can see a summarised view of your website's Core Web Vitals in Google Search Console and page-level metrics in PageSpeed Insights under the Field Data category.

One major disadvantage is that the field data is based on a rolling 28-day average. This means that if you change something on your website, the full effects will only become visible after 28 days.

This is where lab test data can help.

Lab data

This data is generated by tools. These tools are designed to always carry out tests under the same conditions. This is basically a good thing, but it also means that they do not necessarily reflect "real world" data due to factors such as location and internet speed.

What's more, bots don't interact with your content, whereas humans do.

You can access the lab data in PageSpeed Insights, with the Lighthouse Chrome Extension and in Chrome Dev Tools.

All right, we're now ready to start analysing and optimising pages for the 3 metrics.

Before optimising the Core Web Vitals

Before you get started with Google Core Web Vitals, it's important to cover the other basics of user experience signals.

But now!

The 3 metrics of Google Core Web Vitals explained

Now that we've covered the general part, let's look at the individual metrics, the recommended thresholds and the technical solutions to common problems.

Let's start with Largest Contentful Paint - LCP.

Largest Contentful Paint (LCP)

The first metric of Google Core Web Vitals is Largest Contentful Paint or LCP.

What LCP is supposed to represent is essentially the loading time of a website. Google measures how long it takes for the largest element on a page to be fully displayed and rendered for the user. Only elements that appear above the fold are considered. This can be a featured image, a background image, the H1 tag or even a paragraph in the content.

The recommended goal is for your LCP value to be under two and a half seconds.

Check LCP value

To check the LCP for a page, you can use one of the tools mentioned above such as PageSpeed Insights, the Lighthouse extension or Chrome Dev Tools.

If you use PageSpeed Insights or Lighthouse, you can refer to Lab data for updates, as the field data is also a running average of the last 28 days.

To see the largest element that was measured, scroll to the bottom of the report and click on "Largest Contentful Paint Element." For our blog articles, this would be our "Featured Images".

If you are working on a development site that is not open to the public, you can use the Chrome Dev Tools.

1. To do this, right-click anywhere on the page you want to test and click "Inspect".
2. Make sure the device is set to a mobile device, click on "Performance", click on the "Record button" and refresh the page.
3. After refreshing, click Stop.

You should then see LCP in the time chart. And if you hover over it, you'll see the largest visible element in the viewport - in the case of our homepage, that's the H1 tag.

Click on it and you'll see more details below.

The causes of poor LCP scores

According to Google, the 4 most common causes of poor LCP are

• slow server response times
• Render-blocking JavaScript and CSS
• slow resource loading times and
• Client-side rendering

If you've implemented the basic load time optimisations such as good hosting, caching, image optimisations and using a CDN, this should help with load performance.

However, if you have issues with render-blocking JS or CSS, it gets a little more technical.

To perform optimisations effectively, you need to have a basic understanding of how browsers render pages.

Let's take a quick look at that now.

But there are ways you can optimise this process to improve loading performance.

Optimising the rendering process for the three main types of resources: images, CSS and JS files.

Let's start with images.

Optimising the rendering process of images

Aside from things like lazyloading and compression, preloading images can significantly reduce page load times. Preloading basically tells browsers the resources that should be loaded first.

For example, if you have a featured image in the viewport, you will probably have it preloaded.

This topic is very extensive, so here is an article about preloading responsive images.

Now let's take a look at what you can do to optimise the rendering process of CSS files.

Optimising the rendering process for CSS files

• Minimise the CSS file.
  Minification removes all unnecessary characters from the source code, resulting in smaller file sizes and faster loading times.
• Include your critical CSS for above-the-fold content in the HTML.
  This could include, for example, the font, viewport settings, background colour and an H1 style. This way, your readers can see the content above the fold before all the round trips are completed in the processing phase.
• Remove unused CSS and move non-critical CSS.
  To find CSS that your site isn't using, go to Chrome Dev Tools, click on the three vertical dots on the right and press the "Run" command. Then search for "Show Coverage".
  Click on the Reload button here, and you can see the CSS and/or JS that is not running in red.
  Click on one of the URLs and you will see the exact lines of code that have not been executed on that page. From here, you can remove anything your site isn't using or move unused code to a separate file and only load that resource on pages that need it.

Optimising the rendering process for Java Script

You can do pretty much the same for JavaScript as you can for CSS. Minify it where it won't break your website or web pages and remove non-critical JS.

Two other things worth doing are deferring or asynchronously loading JS where appropriate. You do this by using the defer or async attributes in the script tags.

To better understand these attributes, you need to know what happens when JavaScript files are included in the HTML code of your website.

This is what happens when JavaScript files are included in the HTML code of your website

Assuming we have a regular <script> tag without attributes, the HTML file will start parsing until it encounters this script file. Parsing is then paused while the script is downloaded and then executed.

Then the rest of the HTML content is parsed. So the result is that the JavaScript blocks and delays the Largest Contentful Paint (LCP).

The async attribute

If you add the async attribute to the script tag, the JS file can actually be downloaded while the HTML is being parsed. And although asynchronously loaded JS can still block the LCP, it ensures that important scripts are executed sooner.

Generally speaking, you should use the async attribute for scripts that are needed earlier in the page load and defer anything that can wait until later.

Finally, there is the defer attribute.

The defer attribute

When added, JavaScript files are downloaded while the HTML is being parsed. But JS is not executed until parsing is complete. It is therefore not blocked.

Let's move on to the next of the 3 Google Core Web Vitals.

First Input Delay (FID)

The next metric of the Google Core Web Vitals is First Input Delay or FID, which measures interactivity.

The purpose of this metric is to get an understanding of a user's first impression of the interactivity and responsiveness of a website.

It measures the time between a user's first interaction with a page and the time it takes for the browser to respond to that interaction.

The recommended speed for FID is less than 100 milliseconds.

Different types of interactions include clicking on a link or button, entering text in a blank field, selecting a drop-down menu or whatever.

Causes of a high First Input Delay value

The main cause of a long FID is heavy JavaScript execution. Basically, a user is trying to interact with the website, but the browser is unable to respond because the main thread is busy with something else.

The solutions to problems with First Input Delay

The four recommendations that Google gives are:

• split long tasks
• optimise your pages for responsiveness
• use a web worker
• reduce the JavaScript execution time

I won't go into this further as First Input Delay is a field metric, which means you can't get lab data for it.

Instead, here's a link to Google's guide to optimising FID.

Let's move on to the third metric: Culmulative Layout Shift (CLS)

Cumulative Layout Shift (CLS)

The next metric in Google Core Web Vitals is Cumulative Layout Shift or CLS, which measures visual stability.

CLS looks at how much the visible content shifts in the viewport and measures the distance by which the affected elements have been shifted.

Here is an example:

In this image, you can see the page on the left just before and after the adverts have loaded on the right.

These shifts can be annoying, causing a poor user experience, and this is probably why Cumulative Layout Shift (CLS) was introduced.

Initially, the stability of web pages was measured continuously, even after the page was loaded. Recently, however, Google has decided to measure CLS in 5-second sessions. The metric that is now reported is the 5-second time window in which the most shifts occurred.

The threshold recommended by Google is a value of less than 0.1.

Check CLS value

You can check this using the same tools I've already discussed.

If you want to see these layout shifts, test your page in Google PageSpeed Insights, for example, and scroll to the bottom of the page. Click on "Avoid Cumulative Layout Shifts" to see the exact parts that are affected.

The causes of Cumulative Layout Shift

The most common causes of CLS are images without dimensions, adverts, embeds and iFrames without dimensions, dynamically inserted content and when fonts or styles are applied too late in the code.

Optimising the CLS value

Fixing these issues without dimensions is fairly simple.

For images and videos, simply add width and height attributes to your elements. Alternatively, you can also use CSS aspect ratio boxes.

For ads, embedded elements and iFrames, static elements can be created to "reserve" the space for these elements.

If you define width and height attributes for the element, you have added placeholders that turn into adverts, iFrames or other embedded elements after rendering.

So, that's it for CLS.

Conclusion: Final thoughts on the Core Web Vitals

I've now given you all the important information about Google Core Web Vitals. You should therefore be able to adapt your website to the criteria of the Google Page Experience Update in order to meet the requirements of the search engine as well as those of the user experience.

Here is a summary of what you have learnt:

• What are the Google Core Web Vitals?
• Understanding the two main data types of Core Web Vitals
• The optimisation of the Core Web Vitals
• The 3 metrics of Google Core Web Vitals explained
• Conclusion: Final thoughts on the Core Web Vitals

The big question remains:

Are Core Web Vitals really that important ...

...that you should invest the time, effort and possibly the money in them?

Good question. Hmmm...

Let me put it this way: If you're already on page 1 of Google, maybe even in one of the top spots, and you'd like to make up one or two more rankings, then it could pay off. The prerequisite: the pages that rank before you can be overtaken.

If you are ranked on page 2 or even further back and want to improve your ranking on page 1, then optimising the Core Web Vitals alone is not enough. In this case, you should possibly generate one or two backlinks beforehand and take care of the quality of your content.

Because, as John Mueller (Senior Webmaster Trends Analyst at Google) said?

"Quality content still comes first. Page experience becomes more important when there are multiple similar results."

Do you need help optimising your Core Web Vitals or other Page Experience factors? Then feel free to contact us. Send an email to This email address is being protected from spambots. You need JavaScript enabled to view it. call us on +43 1 353 2 353 or send us your enquiry using our contact form.