searchmetrics email facebook github gplus instagram linkedin phone rss twitter whatsapp youtube arrow-right chevron-up chevron-down chevron-left chevron-right clock close menu search

Core Web Vitals – Getting ready for Google’s Page Experience ranking factor update

Core Web Vitals, the new user experience metrics from Google, are made up of three metrics that webmasters and SEOs will have to keep in mind in the future: loading, interactivity, and visual stability. Because Core Web Vitals are based on the user experience, they are measured with field data which is different to previously used lab data that pinpoints a specific moment during the page loading process. In combination with other components relating to website security and user friendliness, Core Web Vitals will be added to the Page Experience ranking factor in June 2021. Read on to find out everything you need to know about Core Web Vitals including optimization tips and a case study.

We can help with your SEO and Content strategy – get in touch with one of our experts to discuss solutions for your business.

Get in touch

Core Web Vitals based on a set of three core metrics

In early May 2020, Google announced the forthcoming launch of their new Core Web Vitals, key indicators that they will be using to rank user experience on websites. When Google’s Core Web Vitals launch in June 2021*, they will include three metrics which, in combination with other variables, will make up a new ranking factor for stable and safe user experience on websites. More details on the Page Experience Ranking Factor can be found in the linked article.

Core Web Vitals
The new Page Experience ranking factor is based on the Core Web Vitals metrics in combination with other KPIs for secure and stable user experience online.

Core Web Vitals are measured with field data that Google has provided in multiple reports and tools, including Lighthouse, Page Speed Insights and Google Developer Tools. Core Web Vitals are made up of three metrics that include:

  • Largest Contentful Paint
  • First Input Delay
  • Cumulative Layout Shift

Over time, Core Web Vitals will be adapted to the latest technical developments and changes in user behavior. In light of this, Google will be re-evaluating the Core Web Vitals every year. This means that the core metrics may change, too.

The focus on three clear and coherent core metrics brings a number of benefits. Google can analyze websites on the basis of clearly communicated KPIs. This gives webmasters, web developers, and SEOs a solid basis when arguing their position in relation to specific jobs and budgets with customers. or their management, who can be shown evidence of the unequivocal positive outcomes of optimized core web vitals.

Where can I access the Core Web Vitals report?

Google’s Core Web Vitals have already been integrated into all of Google’s analysis tools. For example, Core Web Vitals can be accessed via PageSpeed Insights, which also includes the page speed score (between zero and 100) generated from Lighthouse. The results for the Core Web Vitals are shown, on the one hand, in the form of field data and lab data. Field data is anonymized data used to render websites on browsers used by real users on various devices and at various connection speeds. Lab data, on the other hand, is based on simulated page loading on a single device under defined network conditions. This is why the values can differ.

The results of the Core Web Vitals can also be accessed in the Google Search Console in the form of a direct overview of metrics for the given domain, showing how many and what URLs are considered good (green), which need improvement (yellow), or which are poor (red). The data in the Search Console is based on the user experience report in Chrome and reflect the actual user data for the respective website for users all over the world:

Core Web Vitals: Google Search Console

The three initial KPIs in the Core Web Vitals are described in more detail below. Also included are optimization tips and other links.

Google rates Core Web Vitals separately for desktop and mobile

Meanwhile Google Webmaster Trends Analyst John Mueller made some additions to the Core Web Vitals in the German Google Office Hours on October 29, 2020. According to this, additional metrics for loading time, as determined in detail in Google Lighthouse, for example, do not play a role for the page experience as a ranking factor. Furthermore, the Google Core Web Vitals would be determined separately for mobile and desktop. In most cases, the mobile values for the Core Web Vitals are worse than for the desktop page. Google then evaluates this separately; for the page there are then no negative effects on the rankings in the desktop search results, but possibly for the mobile rankings, Mueller continued.

Largest Contentful Paint (LCP): How fast does my page load?

Core Web Vitals: Largest Contentful Paint

The Largest Contentful Paint (LCP) measures the time that passes until the largest content element on a page has loaded. These can be images, blocks of text, or elements with a background image. For LCP, loading times of up to 2.5 seconds are good, anything between 2.5 and 4 seconds needs improvement – and anything lower than 4 seconds is poor. The LCP of a page is determined on the basis of the page loading status – because, in most cases, the largest element is loaded at the end. Let’s take a look at the example of the CNN website shown below:

Core Web Vitals: Example CNN

Google has done their best to make the documentation on the individual Core Web Vitals as detailed and clear possible. More information and the exact basis of the calculations can be found in Google Documentation on the Largest Contentful Paint.

Optimizing for the Largest Contentful Paint

  • Server responding too slowly: The longer the browser needs to receive content from the server, the longer it will take for the page to load for the user. This is why Google recommends using a framework like React instead of an entire HTML file, so that the content of a page is sent to the browser dynamically. It might also help to establish a Content Delivery Network (CDN) to enable the requests to be sent from the server located closest to the user. In addition to efficient caching, it makes sense to set up third-party connections early so as to prevent an avoidable delay in the latter part of the page loading.
  • JavaScript and CSS render-blocking: Before the browser can really render content elements, meaning visualize them for the user, the HTML mark-up has to be parsed in what is called a Document Object Model (DOM). The problem here, however, is that the HTML parser stops each time CSS stylesheets or JavaScript resources have to be loaded. To eliminate this problem, Google recommends minifying CSS or JavaScript files, deferring non-critical styles or JS and inlining critical CSS attributes.
  • Resources loading too slowly: Images, videos or content blocks can often cause resources to load too slowly. Here, Google recommends reducing images to the size needed, for instance using newer file formats that have superior image compression such as JPEG 2000, JPEG XR or WebP. Another approach would be to pre-load the main resources and compress HTML, CSS, or JavaScript files using Gzip. Adapting Serving can also help here, giving you the option of setting the page to only load a small image rather than a video if the connection speed is anything less than 4G, for example.
  • Client-Side Rendering: Client-Side Rendering, where webpages are rendered in the browser directly with the help of JavaScript frameworks such as React or Angular, is an effective means of ensuring that the Largest Contentful Paint loads faster for the user.
  • Other optimization tips: In a dedicated blogpost Google provides a number of tips for improving Largest Contentful Paint.

First Input Delay (FID): When can the user interact with a page?

Core Web Vitals: First Input Delay

The First Input Delay (FID) measures the time from when a user first interacts with a site up to the point at which the browser is able to respond to that interaction. Often users will go to a website and immediately click on text or click a button without waiting for the page to fully load first. Very often nothing much will happen because the browser is busy loading the page. The diagram below shows the different parameters and metrics involved in webpage loading:

Core Web Vitals: Example website loading

To stop users from becoming impatient and leaving the page again because the browser is not responding to their input, the FID metric measures the delay that occurs between the user input and the browser response. According to Google, anything under 100 milliseconds is good, anything between 100 and 300 milliseconds needs improvement, while FID values above 300 milliseconds is considered poor. Details on First Input Delay can be found in the Google documentation on First Input Delay.

Optimizing for the First Input Delay

  • Splitting up long tasks: Delay are often caused by JavaScript execution, meaning users may not be able to interact with the website. Breaking up the tasks can help with this. For Google, long tasks are those where a piece of code blocks the main thread for longer than 50 milliseconds.
  • Prioritizing interactivity: In other words, giving priority to code that is essential for site interactivity, meaning this is loaded first.
  • Using a Web Worker: With a Web Worker, heavy JavaScript files can be executed in a separate thread, meaning the main thread is not blocked.
  • Reducing JavaScript execute times: All the JavaScript files that are executed when a website is loaded, should be scrutinized with a view to deferring those that are not essential.
  • Other optimization tips: In a dedicated blogpost Google also provides various tips on how to improve the First Input Delay.

Cumulative Layout Shift (CLS): Visual stability on a website

Core Web Vitals: Cumulative Layout Shift

The Cumulative Layout Shift (CLS) refers to the visual stability during interactivity on a website. When a website loads, layout shifts can happen pushing elements down the page, for instance, while the next element is loading above. When content shifts as a page loads and the user is already interacting with the site, this can have undesirable effects as shown in the following Google demo video:


In other words, the Cumulative Layout Shift shows whether and to what extent unexpected layout changes (shifts) occur while the user is interacting with the website. For example, when a new content element is being visualized and a button suddenly shifts position without the user scrolling. The lower this metric is, the better. As part of Core Web Vitals, the Cumulative Layout Shift metric is calculated as follows:

Impact Fraction x Distance Fraction = Layout Shift Score

The impact fraction is the percentage of the screen impacted by a shift, while the distance fraction describes the percentage of the viewport height by which the content element has moved down due to the layout shift. Both the impact fraction and the distance fraction are given as values between 0 and 1. The Layout Shift Score is the product of these two values and lies between 0 and 1.

For Google, anything below 0.1 is good and anything higher than 0.25 is poor. Anything in between needs improvement. Details on the Cumulative Layout Shift can be found in the Google Documentation on Cumulative Layout Shift.

Optimizing for the Cumulative Layout Shift

  • Specify the size of images and video elements: Specifying the exact size (W x H) of images and videos will ensure there are no unpleasant surprises for users. Alternatively, the space needed for these elements can also be defined using aspect ratio with CSS. In this way the browser will keep the exact space needed for the image or video free while it is loading.
  • Ads with no height / width data: According to Google, ads are one of the most common reasons for layout shift on websites. This is because advertising networks – including Google Ads – often use dynamic ad formats. Placeholder elements can help here – historical data will enable you to select the most likely size for a certain ad space.
  • Dynamic content elements: Elements like newsletters or special offer banners, related content blocks, or GDPR info positioned as blocks in the main content on a page can result in layout shifts. Here, too, Google recommends using placeholder elements. Doing so will rule out unpleasant surprises for the user if content shift while a page is loading.
  • Web fonts: Downloading and rendering web fonts can cause layout shifts – for example when the fallback font is replaced by the custom web font. This is why it is advisable to preload the fonts. The web fonts used can also be saved on your own server.
  • Other optimization tips: In this blogpost Google itself provides various tips on how to reduce or prevent Cumulative Layout Shift

Case Study: Fashion house Chloé optimizes for Core Web Vitals

The video below shows a case study of the fashion house Chloé and describes how the company managed to optimize Core Web Vitals for their homepage, taking it to the “green” level in Google’s charts. For example, the Largest Contentful Paint metric was reduced from 2.9 to 1.5 seconds, for instance by optimizing critical-path CSS or through image compression. Google engineering manager Addy Osmani talks you through the Core Web Vitals in this hands-on journey:

Conclusion: Google is doing its part – SEOs have to step up, too

Google’s Core Web Vitals are set to become the core metrics for measuring user experience. Core Web Vitals will initially launch with three core metrics for loading (Largest Contentful Paint), site interactivity (First Input Delay), and visual stability (Cumulative Layout Shift). What’s more, Core Web Vitals will be merged with existing ranking factors such mobile friendliness or HTTPS to bring you Google’s all-new ranking factor: Page Experience!

For greater transparency on Core Web Vitals, Google has gone all out and published in-depth documentation that gives webmasters, developers, and SEOs all the information they need to fully understand how the individual criteria are set, what elements are crucial, and, more importantly, how websites can now be optimized for the new Core Web Vitals.

If you haven’t already, we recommend using the Search Console to run a proper check on your own web projects to see how they are performing on the Core Web Vitals front. The majority of websites have room for improvement – and Google has given us the very tools we need to do just that! Armed with Google’s in-depth documentation and optimization tips for Core Web Vitals coupled with analysis tools such as Lighthouse, you can make the most of the time while we are waiting for the new Page Experience ranking factor to launch.

We can help with your SEO and Content strategy – get in touch with one of our experts to discuss solutions for your business.

Get in touch


Google first wanted to launch in May 2021, but then announced to launch in June 2021.