What Are Core Web Vitals and Why Do They Matter for SEO?

Core Web Vitals are three specific metrics Google uses to measure how real users experience your website. They track loading speed (LCP), interactivity (INP) and visual stability (CLS). Google made them a ranking signal in 2021, and they’ve been part of the algorithm ever since. They won’t single-handedly decide where you rank, but when two pages are otherwise comparable, the one with better Core Web Vitals gets the edge.

Most guides on this topic are written for developers. This one isn’t. If you’re a business owner or marketing manager who needs to understand what these metrics mean, whether your site passes, and which fixes to prioritise, you’re in the right place. We’ll keep the technical detail to what’s actually useful for making decisions rather than implementing code.

What Are Core Web Vitals?

Core Web Vitals are a subset of Google’s broader page experience signals. Google introduced them in 2020 and rolled them into the ranking algorithm as part of the Page Experience update in mid-2021. The idea is straightforward: Google wants to reward sites that are genuinely pleasant to use, not just well-optimised for keywords.

There are three metrics, each measuring a different dimension of user experience:

Largest Contentful Paint (LCP) – how quickly the main content loads

Interaction to Next Paint (INP) – how fast the page responds when someone interacts with it

Cumulative Layout Shift (CLS) – how stable the layout is while the page loads

That’s it. Three numbers. Each has a threshold you need to hit, and Google evaluates your performance based on real user data from the Chrome User Experience Report (CrUX), not lab simulations.

One thing worth knowing upfront: Google assesses these metrics at the 75th percentile (p75) of all page visits. That means 75% of your visitors need to have a “good” experience for the page to pass. It’s not enough for the page to load fast on your laptop over fibre broadband. It needs to work well for the majority of your actual audience, including the ones on older phones with patchy 4G.

The Three Metrics at a Glance

Anything between “good” and “poor” is classified as “needs improvement.” Google’s traffic light system is simple: green means good, amber means needs improvement, red means poor.

Largest Contentful Paint (LCP)

LCP measures how long it takes for the largest visible element on the page to finish rendering. That’s usually a hero image, a large text block, or a video poster frame – whatever takes up the most screen space above the fold when the page first loads.

The threshold is 2.5 seconds from when the user first navigates to the page. Under 2.5 seconds is good. Over 4 seconds is poor.

Why LCP Matters

LCP is the metric your visitors feel most directly. It’s the difference between a page that snaps into view and one where someone stares at a blank screen wondering if they should hit the back button. Google’s data consistently shows that users abandon pages that take too long to show meaningful content. That’s lost traffic, lost leads, lost revenue – regardless of where you rank.

What Causes Poor LCP

Four things account for most LCP problems:

Slow server response time (TTFB). If your server takes too long to respond to the initial request, everything else is delayed. Time to First Byte (TTFB) is the starting line for LCP. A slow host, an overloaded server, or no content delivery network (CDN) can all drag this out.

Render-blocking resources. CSS and JavaScript files that the browser has to download and process before it can show anything on screen. If your site loads a dozen stylesheets and scripts before rendering the first pixel, LCP suffers.

Unoptimised images. The single most common LCP problem. A 3MB hero image that hasn’t been compressed or served in a modern format (WebP or AVIF) will blow your LCP budget on its own. Serving the same massive image to mobile and desktop compounds the problem.

Client-side rendering. Sites built with JavaScript frameworks that render content in the browser rather than on the server often have worse LCP. The browser has to download the JavaScript, execute it, and then render the content – adding steps before anything visible appears.

LCP is closely related to two other metrics you’ll see in Lighthouse reports: First Contentful Paint (FCP), which measures when the first piece of content appears, and Time to First Byte (TTFB), which tracks the server’s initial response time. Neither is a Core Web Vital, but both feed into LCP. If your TTFB is slow, your LCP will be too.

Quick Wins for LCP

Compress and resize images; serve them in WebP or AVIF format

Lazy load images below the fold (but never lazy load the LCP element itself)

Use a CDN to reduce server response times

Preload the LCP element (tell the browser to prioritise it)

Defer non-critical JavaScript and CSS

Consider server-side rendering if you’re on a JS-heavy framework

We’ll cover site speed optimisation in more depth in a dedicated article. For now, these are the CWV-specific fixes that move the needle on LCP.

Interaction to Next Paint (INP)

INP measures how responsive your page is when someone actually does something – clicks a button, taps a menu, types in a form field. Specifically, it tracks the delay between the user’s interaction and the next time the browser paints a visual update to the screen.

The threshold is 200 milliseconds. Under 200ms is good. Over 500ms is poor.

INP Replaced FID in March 2024

If you’ve seen older articles referencing First Input Delay (FID), that metric was retired. Google replaced FID with INP on 12 March 2024.

The reason was straightforward: FID only measured the delay on the very first interaction. If someone clicked a button the moment the page loaded and there was a delay, FID caught it. But if every subsequent interaction was sluggish, FID didn’t care. It was a single-event metric trying to represent the full user experience, and it wasn’t up to the job.

INP fixes this by measuring all interactions throughout the entire page visit and reporting the worst one (with some statistical smoothing for pages with many interactions). It’s a far more honest picture of how responsive your site actually feels to use.

This change caught a lot of sites off guard. Many had comfortable FID scores but failed INP because their pages were sluggish after the initial load. Two years on, INP remains the most commonly failed Core Web Vital, with a significant proportion of sites still missing the 200ms threshold.

What Causes Poor INP

INP problems are almost always caused by JavaScript. Three components make up each interaction’s latency:

Input delay. The time between the user’s action and the browser starting to process it. If the main thread is busy executing other JavaScript, the interaction has to wait in a queue.

Processing time. How long the event handler takes to run. Complex calculations, DOM manipulation, or synchronous API calls during event processing all extend this.

Presentation delay. The time between the event handler finishing and the browser painting the visual update. Layout recalculations and rendering work after the event handler runs add to this.

What to Look At for INP

Identify and break up long-running JavaScript tasks (anything over 50ms blocks the main thread)

Reduce the amount of JavaScript loaded on the page overall

Defer third-party scripts (analytics, chat widgets, ad scripts) that compete for main thread time

Use web workers to move heavy processing off the main thread

Audit event handlers for unnecessary complexity

One useful proxy: Total Blocking Time (TBT) in Lighthouse measures total time the main thread was blocked during page load. It’s a lab metric, not a Core Web Vital, but it correlates well with INP. If your TBT is high, your INP almost certainly is too.

INP is the metric that most often requires developer involvement to fix. If your site runs on WordPress with a dozen plugins, each adding its own JavaScript, INP is probably where you’ll struggle most.

Cumulative Layout Shift (CLS)

CLS measures unexpected layout movement – those moments when you’re about to tap a link and the page jumps because an ad loaded above it, or text shifts down because a web font finished downloading. It’s a unitless score calculated from how much of the viewport shifted and how far it moved.

The threshold is 0.1. Under 0.1 is good. Over 0.25 is poor.

Why CLS Frustrates Users

Layout shifts are the metric users notice without knowing the technical name for it. Everyone’s had the experience of reaching for a button only to accidentally click an ad because the page moved at the last second. Or reading an article and losing their place because a banner loaded and pushed the text down.

It’s not just an annoyance. On mobile, where screen space is tight and touch targets are small, layout shifts cause misclicks that send people to the wrong page. That erodes trust quickly.

Common Causes of CLS

Images and videos without dimensions. If you don’t specify width and height attributes (or use CSS aspect-ratio), the browser doesn’t know how much space to reserve. When the media loads, everything below it shifts down.

Ads and embeds that load dynamically. Third-party ad slots are notorious for CLS problems. They inject content into the page after the initial render, pushing everything else around.

Web fonts causing FOUT/FOIT. When a custom font loads and replaces the fallback font, text can reflow if the fonts are different sizes. Flash of Unstyled Text (FOUT) or Flash of Invisible Text (FOIT) both contribute to layout shift.

Content injected above existing content. Banners, cookie notices, or notification bars that push content down after the page has already rendered.

Fixing CLS

Always set explicit width and height on images and videos

Reserve space for ad slots and dynamic embeds with CSS

Use `font-display: swap` with size-matched fallback fonts

Avoid inserting content above existing content after the initial render

Use CSS `contain` properties to isolate layout recalculations

CLS is often the easiest of the three metrics to fix because the causes are visual and the solutions are well-documented. Most CLS improvements don’t even need a developer – a competent content editor who knows to add image dimensions can make a measurable difference.

Field Data vs Lab Data: Why the Distinction Matters

This is something most guides either skip or explain in a way that only makes sense if you already understand it. But it genuinely matters for how you interpret your Core Web Vitals scores.

Lab data comes from tools that simulate a page load in a controlled environment. Lighthouse (built into Chrome DevTools) and the lab section of PageSpeed Insights both generate lab data. They use a fixed device profile, a throttled network connection, and a fresh browser with no extensions. Lab data is consistent and reproducible, which makes it useful for debugging specific issues.

Field data comes from real users visiting your site in the real world. Google collects this through the Chrome User Experience Report (CrUX), which aggregates anonymised performance data from Chrome users who’ve opted into usage statistics. Field data appears in Google Search Console, the field section of PageSpeed Insights, and the CrUX dashboard.

Here’s why this distinction matters: Google uses field data for ranking, not lab data.

Your Lighthouse score might be 95, but if your real users – the ones on older Android phones, the ones with three tabs open and spotty mobile signal – are getting slow load times, that’s what Google sees. Lab data is your debugging tool. Field data is your report card.

This catches people out constantly. A developer runs Lighthouse, sees a score of 90+, and declares the site is fine. Meanwhile, Google Search Console is flagging dozens of pages with poor LCP because the real audience is on slower devices and connections than the developer’s machine. The two data sources aren’t contradicting each other – they’re measuring different things.

This also means you need enough traffic for Google to have field data on your pages. Newer or lower-traffic pages may not have CrUX data at all, in which case Google falls back to origin-level data (your site’s overall performance across all pages). If your site is brand new or gets very little Chrome traffic, Google may not have enough data to assess your Core Web Vitals at all. That’s not necessarily a problem – it just means CWV won’t be a factor in your rankings until the data exists.

Which Tool Shows What

For most business owners and marketing managers, Google Search Console and PageSpeed Insights are the two tools that matter. Search Console tells you which pages are passing and failing. PageSpeed Insights tells you why.

How Much Do Core Web Vitals Affect Rankings?

This is the question everyone wants answered, and the honest answer is: less than you’ve probably been told, but more than you should ignore.

Google has confirmed that Core Web Vitals are a ranking signal. But they’ve also been clear that content relevance, quality, and authority still carry far more weight. Google’s own Search Relations team has consistently framed page experience as a tiebreaker rather than a dominant factor – something that matters when other signals are roughly equal, not something that overrides them.

Think of it this way. If your content is thin, your backlink profile is weak, and your keyword targeting is off, perfect Core Web Vitals won’t save you. But if you’re in a competitive SERP where multiple pages offer similar content quality and authority, the one with better user experience metrics has an advantage.

The practical implication: don’t panic about Core Web Vitals if you’ve got bigger SEO problems to solve first. Fix your content. Build your authority. Sort out your technical SEO foundations. Then optimise for CWV. But don’t ignore them either – especially if you’re already competitive and looking for every edge you can find.

Mobile vs Desktop: Separate Assessments

Google evaluates Core Web Vitals separately for mobile and desktop. Your site might pass all three metrics on desktop but fail on mobile, or vice versa. Since Google uses mobile-first indexing, mobile performance is the one that matters most for search.

This is where many sites fall down. Pages that feel snappy on a developer’s MacBook Pro can be painfully slow on a mid-range Android phone with 4G. The processing power gap is significant – a flagship phone can handle JavaScript several times faster than a budget Android device. And your budget-Android users are often the majority of your mobile audience.

Testing only on desktop gives a misleading picture. Always check your mobile field data in Search Console – that’s the version Google cares about. If you want to simulate a more realistic experience in the lab, Lighthouse’s default throttling helps, but even that’s generous compared to what many real users experience.

Which Metric Should You Fix First?

If your site fails multiple Core Web Vitals, you need a prioritisation framework. Fixing everything at once isn’t realistic, and some improvements deliver more impact than others.

Start with the Metric That Fails Most Pages

Open Google Search Console, navigate to the Core Web Vitals report, and look at the mobile tab. Which metric has the most URLs in “poor” or “needs improvement”? That’s your starting point – not because it’s the most important metric in isolation, but because fixing the most widespread issue lifts the most pages.

Then Prioritise by Effort vs Impact

CLS is usually the quickest win. Adding image dimensions, reserving ad space, and fixing font loading are relatively straightforward changes. If CLS is your problem, you can often fix it in days rather than weeks.

LCP improvements tend to have the biggest perceived impact. A faster-loading page is something everyone notices – your users, your team, and your conversion rate. Image optimisation, server upgrades, and CDN implementation are well-understood solutions with predictable outcomes.

INP is typically the hardest to fix. It requires JavaScript optimisation, which means developer time and potentially architectural changes. If INP is your main issue, expect it to take longer and budget accordingly.

The Priority Matrix

This isn’t a rigid rule. If your LCP is 2.6 seconds (barely failing) but your INP is 800ms (well into red territory), flip the order. Context matters.

How to Monitor Core Web Vitals

Checking your scores once and walking away isn’t enough. Core Web Vitals shift over time as you add content, update plugins, run new ad campaigns, or push code changes. Ongoing monitoring catches regressions before they affect rankings.

Google Search Console (Your Primary Dashboard)

The Core Web Vitals report in Search Console groups your URLs into good, needs improvement, and poor for both mobile and desktop. It updates as Google collects new field data, which means changes you make today won’t show up immediately – expect a 28-day rolling window before improvements are reflected.

When you fix an issue, use the “Validate Fix” button in Search Console. Google will re-evaluate the affected URLs and confirm whether the fix worked.

Real User Monitoring (RUM)

For larger sites, Real User Monitoring tools provide more granular data than CrUX alone. RUM scripts run on your live pages and collect performance data from every visitor, giving you faster feedback and more detailed breakdowns by page type, device, geography, and traffic source. Tools like SpeedCurve, DebugBear, and Vercel Analytics offer RUM dashboards specifically designed around Core Web Vitals.

Set Up Alerts

If your CMS or hosting provider offers performance monitoring, set thresholds that trigger alerts before you cross from “good” into “needs improvement.” Catching a regression at 2.3 seconds LCP is better than finding out at 3.5 seconds during your next monthly review.

Watch for Regressions After Changes

The most common time for Core Web Vitals to degrade is after a site change – a CMS update, a new plugin, a design refresh, or a third-party script added by someone in the marketing team. Each of these can introduce new render-blocking resources, heavier JavaScript, or layout-shifting elements without anyone realising.

Build CWV checks into your deployment process. Even a quick PageSpeed Insights test before and after a major change can catch problems before they hit your field data. By the time a regression shows up in Search Console, it’s already been affecting your users for weeks.

Core Web Vitals and the Bigger SEO Picture

Core Web Vitals don’t exist in isolation. They’re one part of a broader set of page experience signals that Google considers, alongside HTTPS security, mobile-friendliness, and the absence of intrusive interstitials (those full-screen pop-ups that block content). Google rolled all of these into the Page Experience update in 2021, though Core Web Vitals are the only page experience signals that directly feed into ranking.

But even zooming out further, page experience itself is just one of many ranking factors. Content quality, backlink authority, topical relevance, E-E-A-T signals, and hundreds of other factors all play a role. The sites that rank well are the ones that get most of these things right, not the ones that obsess over a single metric while neglecting everything else.

That said, Core Web Vitals have an indirect effect that goes beyond their direct ranking weight. A faster, more responsive, more stable site keeps users on the page longer, reduces bounce rates, and improves conversion rates. Those user behaviour signals may not be direct ranking factors, but they affect the business outcomes that SEO is ultimately trying to drive. Fixing your Core Web Vitals is rarely wasted effort, even if the ranking boost is modest.

If you’re thinking about your SEO strategy holistically, Core Web Vitals sit in the “technical foundations” category. They’re the kind of thing that should be right – like having a secure certificate or a mobile-friendly layout – rather than the thing you build your entire strategy around.

Getting Your Core Web Vitals Right

For most businesses, Core Web Vitals fall into one of two categories: either your site passes and you just need to keep an eye on it, or it doesn’t and you need someone to diagnose and fix the issues.

If you’re in the second camp and you’re not sure where to start, that’s exactly the kind of problem a technical SEO audit is designed to solve. At Gorilla Marketing, we include Core Web Vitals diagnostics in every technical audit – not just the scores, but a prioritised list of what to fix, why it matters, and what the expected impact will be. Senior strategists work directly on every account, translating performance data into plain-English recommendations your dev team can act on. If you want a straight assessment of where your site stands, get in touch.