Core Web Vitals: what they are and how to optimise them for SEO

Core Web Vitals measure something very concrete: how much a slow-loading website loses. According to an analysis by Google, 53% of mobile visits are abandoned if a page takes more than three seconds to load. So if your site is slow, you aren’t just losing rankings on Google: you’re losing customers before they’ve read a single line.

Core Web Vitals are the metrics Google uses to measure how long a page takes to load, how quickly it responds to clicks and how much the layout moves while the user is reading. They aren’t a technical detail to be left to the developer alone: they affect both rankings and the behaviour of the people visiting your site.

In this guide you’ll find the definitions of the Core Web Vitals, namely LCP, INP and CLS, the pass and fail thresholds set by Google, the tools for measuring them and a practical checklist for improving them.

What Core Web Vitals are

Google introduced them in 2020 to answer a simple question: how do you measure, with numbers rather than impressions, whether a website gives its visitors a good experience? Before then there was no shared standard. There were dozens of performance metrics, each useful in its own way, but none clear enough to become the shared standard we now call Core Web Vitals.

Core Web Vitals cover three areas:

• loading, meaning how much time passes before the main content of the page is visible
• responsiveness, meaning how much time passes between a click (or a tap, or a key press) and the visible response on screen
• visual stability, meaning how much the layout shifts while the page is loading or while the user is interacting with it

The data comes from the Chrome User Experience Report (CrUX), which collects the real experiences of people browsing with Chrome, not from a simulated lab test. This often causes confusion: a site can look fast in a local test and still have Core Web Vitals in the red in Search Console, because the local test doesn’t reflect visitors’ real conditions (mobile networks, less powerful devices, unstable connections).

For a company that sells online, the link between Core Web Vitals and conversions translates into a concrete number: a site that loads in one second converts up to 2.5 times more visitors than one that takes five seconds, according to a Portent study cited by HubSpot. It isn’t just a question of rankings on Google. It’s a question of how many customers make it to the basket.

LCP, INP, CLS: the three metrics explained

Each Core Web Vital has a “good” threshold, a “needs improvement” threshold and a “poor” threshold. The thresholds are set by Google and apply to every site, with no exceptions by industry.

LCP (Largest Contentful Paint): loading speed

LCP is the first of the three Core Web Vitals and measures how much time passes from when the page starts loading to when its largest element is displayed: usually a hero image, a cover video or the main block of text.

Thresholds: good under 2.5 seconds, needs improvement between 2.5 and 4 seconds, poor over 4 seconds.

The most common causes of a slow LCP are oversized, uncompressed images, a slow-responding server, CSS and JavaScript that block rendering before the main content is visible, and web fonts that delay text from appearing.

INP (Interaction to Next Paint): responsiveness

INP is the second of the three Core Web Vitals and measures the time between a user interaction (a click, a tap, a key press) and the moment the browser visually updates the page in response. It replaced First Input Delay (FID) as the official metric in March 2024, because it assesses every interaction in the session, not just the first.

Thresholds: good under 200 milliseconds, needs improvement between 200 and 500 milliseconds, poor over 500 milliseconds.

The most common causes are heavy JavaScript that takes a long time to run, long tasks that block the browser’s main thread, and third-party scripts (chat, tracking pixels, pop-ups) competing for the same resources.

CLS (Cumulative Layout Shift): visual stability

CLS is the third of the three Core Web Vitals and measures how much the content of the page moves unexpectedly while it loads or while the user interacts with it. It’s the classic case of the button that jumps a split second before you manage to click it.

Thresholds: good under 0.1, needs improvement between 0.1 and 0.25, poor over 0.25.

The most common causes are images or videos without dimensions declared in the HTML, ad banners or widgets inserted dynamically above content that’s already visible, and web fonts that arrive late and change the size of text that has already been rendered.

How to measure them (Search Console, PageSpeed Insights)

Before working on Core Web Vitals, you need to know where the data you’re looking at comes from. Google distinguishes between two kinds of measurement, and confusing them is the most common mistake made by people checking Core Web Vitals for the first time.

Field data comes from real users who visited the site with Chrome: it tells you what really happens, but it needs a minimum volume of traffic to be available. Lab data comes from a simulated test, always run under the same conditions: it’s immediate, but it describes a hypothetical scenario, not visitors’ real experience.

There are four main tools, and each serves a different purpose:

• Search Console, in the Core Web Vitals report: uses field data aggregated by groups of similar pages. It’s the best starting point for understanding which sections of the site have a widespread problem, not just one isolated page
• PageSpeed Insights: combines field data (when available) and lab data for a single page. Useful for a quick diagnosis and for understanding what is actually slowing that page down
• Chrome UX Report (CrUX): public field data, useful for domain-level comparisons, including with competitors
• Chrome DevTools (Performance panel) or Lighthouse: detailed lab data, the right choice during development, to check whether a change has really improved things before publishing it

To get an accurate picture of a site’s Core Web Vitals, start with Search Console to identify the critical pages, then dig deeper with PageSpeed Insights page by page. The official Google Search Central documentation explains in detail how the thresholds are calculated, and was last updated in December 2025.

If you’d rather have a ready-made analysis than cross-reference four different tools, request a technical SEO audit: we’ll prepare it for you, with the priorities already ranked by impact.

How to optimise them: a practical checklist

The three Core Web Vitals have different causes, so the fixes are different too. Here’s a checklist divided by metric, designed for people who need to set priorities and don’t have time to rebuild the site from scratch.

Checklist for improving LCP

1. Compress images and use modern formats such as WebP or AVIF
2. Preload the main image or video instead of lazy loading it
3. Enable server-side caching and, if traffic justifies it, a CDN
4. Reduce server response time (TTFB)
5. Remove or defer CSS and JavaScript that block rendering of the visible part of the page
6. Apply lazy loading only to off-screen images, not to the main one
7. Use font-display: swap to stop web fonts from blocking text from appearing

Checklist for improving INP

1. Break long JavaScript tasks into smaller chunks, so they don’t block the main thread
2. Remove or defer non-essential third-party scripts (chat, pixels, pop-ups)
3. Update the interface the user can see first, then run the rest of the code in the background
4. Reduce the size of JavaScript bundles with code splitting
5. Move heavy calculations that don’t touch the DOM to a web worker
6. Avoid reading and changing the page’s styles in the same execution cycle
7. Use the Performance panel in Chrome DevTools to identify the slowest tasks

Checklist for improving CLS

1. Always declare width, height or aspect-ratio on images and videos
2. Reserve space for ad banners before they load
3. Avoid inserting dynamic content above content the user can already see
4. Preload web fonts to avoid layout shifts when they arrive
5. Animate elements with transform, not with properties that change the layout
6. Check third-party embeds (videos, maps, social widgets): they are the most frequent cause of high CLS

To learn more about how Google recommends working on Core Web Vitals, and on INP in particular, the web.dev guide goes into detail on how to handle long tasks on the client side.

Core Web Vitals and rankings: how much they matter

Clarity is needed here, because you can read all sorts online. In its own documentation, Google says that Core Web Vitals, together with the other aspects of page experience, are aligned with what its ranking systems seek to reward. It doesn’t say they are the deciding factor.

In 2021, Google’s John Mueller answered people asking how much Core Web Vitals really weighed in rankings: they are a ranking factor, and more than a tie-breaker between similar pages, but they don’t replace relevance. Content relevance remains by far the most important factor: a slow site with relevant content can still beat a fast site with generic content.

That doesn’t mean they count for little. It means the relationship between site speed and SEO should be read on two levels: rankings, where Core Web Vitals are one signal among many, and business, where the effect is direct and measurable. According to data reported by HubSpot, after improving LCP, one of the three Core Web Vitals, by 31% on one site, Vodafone recorded a 15% increase in lead-to-visit rate, an 11% increase in cart-to-visit rate and an 8% increase in sales.

In practice: even if Core Web Vitals won’t move you from page two to page one on their own, a slow site remains a concrete cause to check when a page doesn’t rank as it should, alongside poorly relevant content, weak structure or indexing problems.

In short, Core Web Vitals aren’t the only lever for rankings. But they’re one of the few you can control with objective data, without having to guess what the algorithm thinks.

Once the real weight of Core Web Vitals in rankings is clear, the next step is to monitor them over time, not just when the site goes live. Google’s thresholds stay the same, but the site changes: every new section, every script added for a campaign, every extra banner can push a Core Web Vital from good to poor. A quarterly check, cross-referenced with Search Console data, stops the problem from building up without anyone noticing.

If you also work on content, it’s worth looking at how to optimise content for AI search at the same time: speed, measured by Core Web Vitals, and content quality operate on the same ground, the overall page experience that Google assesses. You’ll find more articles like this in the guides and tutorials section.

To sum up: Core Web Vitals are three measurable metrics, LCP, INP and CLS, with precise thresholds set by Google. They don’t decide rankings on their own, but they directly affect conversions and user behaviour. Measuring them with the right tools and working through the right priorities is technical work that shows in the numbers, not just in theory.

If you want to know exactly where your site is losing speed, request a technical SEO audit: we’ll analyse your Core Web Vitals, LCP, INP and CLS, page by page and tell you what’s worth fixing first.