Skip to main content

Understanding Core Web Vitals

The Core Web Vitals are a set of three website performance metrics that capture how users experience the performance of your website. They are used as a search result ranking factor by Google.

This article looks at what the Core Web Vitals are, how you can measure them, and how they impact SEO.

What are the three Core Web Vitals?

The three Core Web Vitals are:

  • Largest Contentful Paint: how quickly does the page render
  • First Input Delay: how quickly does the page respond to user input
  • Cumulative Layout Shift: how stable is the page layout

Google has defined thresholds for each of these metrics to rate them as "Good", "Needs Improvement", or "Poor".

Core Web Vitals thresholds, LCP good under 2.5 seconds, CLS good under 0.1, FID good under 100 milliseconds

Run a Core Web Vitals test

Want to know whether your site meets Google's Core Web Vitals requirements? Use our free site speed testing tool to find out!

Core Web Vitals Test Result

How do Core Web Vitals impact SEO?

Google first started using Core Web Vitals as a ranking factor in June 2021. Initially this only affected mobile rankings, but starting in February 2022 the change will also be rolled out to desktop searches.

The Core Web Vitals are part of the broader range of page experience signals Google uses, like being mobile-friendly and using a secure connection.

When do pages get an SEO boost?

You should see a gradual ranking boost as your metrics move toward the "Good" rating. Core Web Vitals are not a binary ranking factor!

Once all metrics are in the "Good" range, further improvements will no longer yield SEO benefits.

Even when making improvements within the "Poor" range, you could still see your pages rise in search result rankings if your competitor's pages are also slow.

Largest Contentful Paint

When first loading a website you'll start with a blank page. Then gradually content will start appearing on the screen.

Different paint timings can be measured and used to evaluate the website's performance.

The First Paint (FP) measures when the browser first starts rendering parts of the page. This includes empty boxes without any content.

The First Contentful Paint (FCP) measures when content, like text or images, is first rendered by the browser.

The Largest Contentful Paint (LCP) measures at what time the largest UI element was rendered on the page.

Filmstrip showing Largest Contentful Paint and other paint timings

Paint timing metrics are closest to the metrics Google traditionally used to factor site speed into its rankings. They measure the visual loading experience of your site.

Unlike the First Paint or the First Contentful Paint, the Largest Contentful Paint can increase later on in the page load process if another large element is rendered in the viewport. Your website might look fully loaded, but if part of the page re-renders then the LCP will jump up.

This filmstrip shows an example where this happens when a parallax background is enabled. Other common causes are replacing a low-resolution background image with a high-resolution one, or a slider that advances to the next slide.

Largest Contentful Paint occurring after UI update

For a good user experience, the Largest Contentful Paint should happen within 2.5s of the page starting to load.

To optimize the Largest Contentful Paint, first check if you can speed up the initial page load. This might include removing render-blocking JavaScript and CSS files, or speeding up server response times. You can read more about this in the First Contentful Paint article.

Avoid large UI updates once the page has been rendered. To do this, make sure that the resources needed to render the above the fold content of your page are prioritized (for example using preload tags, or by lazy-loading other content).

If you're building a JavaScript app, consider using server-side rendering to avoid visual changes once the client-side app is initialized.

First Input Delay

The First Input Delay (FID) measures how long it takes for the browser to start responding to user interaction, like clicks and taps.

The most common reason for a poor First Input Delay is JavaScript compilation or execution blocking the page main thread. If other work is already in progress, the browser can't start handling the user interaction until this work is complete.

This screenshot of the Chrome DevTools Performance tab shows an example of a busy main thread. If the user tried to interact with the page during the long frames (600.9ms and 994.5ms) it would have taken a long time for the page to respond.

Busy main thread in Chrome DevTools

Ideally, the First Input Delay should be under 100ms.

To optimize First Input Delay, record a Performance profile in Chrome DevTools and identify long tasks that block the UI. Is it possible to speed up theses tasks, or to break them up into smaller chunks, so that user interactions can be handled in between?

Third-party scripts can also block the main thread. Check if all of them are necessary, or if some can be loaded later on as needed.

Interaction to Next Paint (INP)

The First Input Delay metric has two important limitations:

  • It only considers the first user interaction on the page
  • It only measures how long it takes for the browser to start responding to user input, not how long it takes to finish responding

Google is experimenting with a new responsiveness metric called Interaction to Next Paint.

Total Blocking Time

The First Input Delay can only be measured if the user actually interacts with the page. If you're using a lab-based tool like PageSpeed Insights, Lighthouse, or DebugBear, then you won't be able to capture it.

As a substitute, you can look at Total Blocking Time (TBT) instead. It measures how long the page main thread was blocked for while the page was loading. "Blocked" here means that there were long tasks taking more than 50 ms. A series of multiple 40ms tasks would not count toward Total Blocking Time.

Cumulative Layout Shift

Cumulative Layout Shift (CLS) measures how much content moves around after first being rendered.

Layout instability can hurt user experience, for example if a button moves around while the user is trying to click it, or if text shifts around after the user started reading.

This filmstrip shows an example of content shifting around on a page.

Website content shifting around as fonts and headers are loaded

To optimize Cumulative Layout Shift, either make sure all content renders in one go, or use placeholders while some content is still loading. That way, even if the UI updates later on, it won't cause existing content to change position.

The CLS should be as low as possible, ideally under 0.1.

Web Vitals in Chrome DevTools

Performance Tab

Chrome includes a Web Vitals lane in the Performance recording. Click on the Web Vitals checkbox to enable the feature, then click on the Start profiling and reload page button on the left.

The recording now shows lanes marking the First Contentful Paint and Largest Contentful Paint, as well as each layout shift that occurs.

Below that you can see a lane called Long Tasks. It shows main thread tasks taking longer than 50ms, with time in excess of 50ms marked in dark blue.

Web Vitals in the Chrome DevTools Performance tab

Core Web Vitals Overlay

Chrome 90 – due for release in April 2021 – is adding an option to show the Web Vitals for the current page as an overlay. When working on optimizing your site speed, this overlay makes it easy to see the most important metrics without having to dive into the Performance tab.

You can enable the overlay via the DevTools Command Menu. Press Ctrl/Cmd + Shift + P, type "web vitals overlay", and press Enter.

DevTools Command Menu

You'll then see the Largest Contentful Paint, First Input Delay, and Cumulative Layout Shift for the page.

DevTools Web Vitals overlay

Alternatively, you can toggle the overlay setting via the DevTools Rendering tab. Click the button in the top right to open it.

Opening DevTools rendering settings

You can find the Core Web Vitals overlay option towards the bottom of the settings.

DevTools rendering settings

Web Vitals in PageSpeed Insights

Google provides PageSpeed Insights (PSI) as a tool to test your website performance. Internally, PSI tests your site using Lighthouse.

You can find the Core Web Vitals in the PageSpeed Insights report.

Field data has been collected by Google from real users accessing your page. If your website doesn't get much traffic you might not get any data here, or see data aggregated across your entire website.

Lab data is collected in a lab environment when you run the PageSpeed Insights test. It uses a simulated mobile device to generate test data.

(Read this article to learn more about field vs lab data.)

Core Web Vitals in PageSpeed Insights

Web Vitals in Google Search Console

You can also view information on Web Vitals in Google Search Console (formerly known as Webmaster Tools).

Select Enhancements and then Core Web Vitals from the sidebar to view how your website is doing.

Core Web Vitals in Google Search Console/Webmaster Tools

You can click on the each issue that Google Search Console identified to see what page the issue occurred on.

Pages with high Cumulative Layout Shift in Google Search Console/Webmaster Tools

Core Web Vitals in DebugBear

Continuously monitoring Core Web Vitals lets you catch performance regressions early and fix problems before they affect Google rankings and user experience.

DebugBear continuously tests your site speed in a lab environment but also shows how the metrics collected by Google in the Chrome User Experience Report (CrUX) change over time.

Core Web Vitals lab and field data

In addition to measuring site performance, DebugBear also keeps track of the SEO and Accessibility scores generated by Google's Lighthouse tool.

Core Web Vitals in DebugBear

Start tracking Core Web Vitals today.

DebugBear is a site speed monitoring service. Start tracking Lighthouse scores and Core Web Vitals in minutes.
Start monitoring your websiteGo to app