Core Web Vitals are three performance metrics Google uses to measure how your site feels to real users. They track loading speed, interactivity, and visual stability – and since 2021, they’ve been a confirmed ranking factor. Not the most important one. Not even close. But a factor nonetheless, and one that directly affects user experience, conversion rates, and whether visitors stick around or bounce.
At Gorilla Marketing, we’ve spent over a decade building SEO strategies grounded in technical fundamentals. Core Web Vitals sit at the intersection of technical SEO and user experience, and getting them right supports everything else your organic strategy is trying to do. This guide covers what the three metrics measure, what thresholds you need to hit, and how to prioritize fixes when your engineering team asks “what should we work on first?”
What Are Core Web Vitals?
Core Web Vitals are a set of three specific metrics that Google considers essential to delivering a good page experience. They measure three distinct aspects of how users experience your pages:
Largest Contentful Paint (LCP) – how fast the main content loads
Interaction to Next Paint (INP) – how quickly the page responds when someone interacts with it
Cumulative Layout Shift (CLS) – how visually stable the page is while it loads
Google introduced these metrics as part of the Page Experience update in 2021, alongside existing signals like mobile-friendliness, HTTPS, and no intrusive interstitials. The idea was to give site owners clear, measurable targets for the aspects of user experience that matter most.
Here’s the quick reference:
| Metric | What It Measures | Good | Needs Improvement | Poor |
|---|---|---|---|---|
| LCP | Loading performance | ≤ 2.5 seconds | 2.5 – 4.0 seconds | > 4.0 seconds |
| INP | Interactivity / responsiveness | ≤ 200 milliseconds | 200 – 500 milliseconds | > 500 milliseconds |
| CLS | Visual stability | ≤ 0.1 | 0.1 – 0.25 | > 0.25 |
These aren’t arbitrary numbers. Google set these thresholds based on research into what users perceive as fast, responsive, and stable. The targets represent the point where most users report a good experience, and they apply equally to every page on your site. A homepage passing all three metrics while your product pages fail still means you have a problem. Google evaluates at the URL level, not the domain level.
How Does Google Actually Measure These?
This is where most guides get it wrong or gloss over the details. Google evaluates your Core Web Vitals using the 75th percentile (p75) of real user data, not averages. That distinction matters.
If your LCP is 1.8 seconds for 70% of visitors but 5.2 seconds for the remaining 30%, you don’t pass. Google looks at the 75th percentile, which means 75% of your page loads need to meet the threshold for you to be considered “good.” This approach prevents sites from gaming the numbers with fast experiences for most users while leaving a significant chunk stuck with poor performance.
Field data vs lab data
Two fundamentally different types of performance data exist, and confusing them is one of the most common mistakes.
Field data (also called Real User Monitoring, or RUM) comes from actual visitors using your site on their real devices and connections. Google collects this through the Chrome User Experience Report (CrUX), which aggregates anonymized data from Chrome users who’ve opted in to sharing usage statistics. This is the data Google uses for ranking purposes.
Lab data comes from controlled simulations. Tools like Lighthouse or PageSpeed Insights simulate a page load on a specific device at a specific connection speed. It’s useful for diagnosing problems, but it doesn’t reflect what real users experience. Your lab scores can look great while your field data tells a different story, especially if your audience skews toward older devices or slower connections.
The practical takeaway: use lab tools for debugging. Use field data for measuring whether you actually pass. Google Search Console’s Core Web Vitals report pulls from CrUX field data, so that’s your source of truth for how Google sees your site.
This distinction catches people out regularly. A developer runs Lighthouse, sees a score of 95, and assumes everything is fine. Meanwhile, the CrUX data shows failing LCP because real users on slower connections and older devices have a very different experience than a high-spec laptop on a corporate network.
Mobile vs desktop: two separate assessments
Google evaluates Core Web Vitals separately for mobile and desktop. A page can pass on desktop and fail on mobile, or vice versa. Since Google uses mobile-first indexing, the mobile scores carry more weight for most sites. If you’re forced to prioritize, fix mobile first.
Mobile failure rates tend to be higher because users are on less powerful hardware and less reliable network connections. A page that loads in 1.5 seconds on a MacBook over fiber might take 4 seconds on a mid-range Android over 4G. That same page passes LCP on desktop and fails it on mobile.
Largest Contentful Paint (LCP): The Loading Metric
LCP measures how long it takes for the largest visible element to render in the viewport. Not the full page load. Not every asset. Just the biggest piece of content the user sees when the page first appears.
That element is usually a hero image, a featured video poster, or a large block of text. Whatever occupies the most screen real estate above the fold, that’s your LCP element.
The threshold: 2.5 seconds or faster.
Why LCP matters beyond SEO
Loading speed is the first thing a user experiences. If the main content takes four seconds to appear, a portion of those visitors are already gone before they’ve read a word. Studies from Google and others consistently show that bounce probability increases with every additional second of load time. This isn’t just a ranking signal. It’s a conversion factor. Every second you shave off LCP is a measurable improvement in the percentage of visitors who actually engage with your content.
Common LCP problems
Most LCP issues trace back to a few root causes:
Unoptimized images. The single most common culprit. A 3MB hero image that could be 200KB with proper compression and modern formats (WebP or AVIF) is leaving seconds on the table.
Render-blocking resources. CSS and JavaScript files that block the browser from rendering anything until they’ve fully loaded. If the browser has to download and parse a 500KB CSS file before it can show the hero image, your LCP suffers.
Slow server response time (TTFB). Time to First Byte is the time between a user requesting a page and receiving the first byte of data. If your server takes 1.5 seconds just to start responding, hitting a 2.5-second LCP target becomes nearly impossible. CDN configuration, server-side caching, and hosting infrastructure all factor in here.
Client-side rendering. Single-page applications that require JavaScript to execute before any content appears add significant delay. The browser downloads HTML, then JavaScript, then executes it, then renders the content. Each step adds time.
Web font delays. Custom fonts that block text rendering until they load can push LCP out if they’re large or served from slow origins.
How to fix LCP
The prioritization order for most sites: compress and properly size images first (biggest bang for the effort), implement lazy loading for below-the-fold images, preload your LCP element, remove or defer render-blocking CSS and JavaScript, and evaluate your hosting and CDN setup if TTFB is the bottleneck.
Interaction to Next Paint (INP): The Responsiveness Metric
INP measures how quickly your page responds to user interactions. When someone clicks a button, taps a menu, or types in a form field, INP captures the delay between that input and the next visual update on screen.
The threshold: 200 milliseconds or faster.
INP replaced First Input Delay (FID) as an official Core Web Vital in March 2024. The change was significant. FID only measured the delay of the first interaction on a page. If a user’s first click was fast but the tenth was slow, FID never caught it. INP measures all interactions throughout the entire page session and reports the worst one (technically, a high percentile of all interactions). It’s a much more honest assessment of how responsive a page actually is.
Why INP matters beyond SEO
A page that feels sluggish when you interact with it creates friction. Users can’t always articulate why a site feels bad, but they notice when buttons don’t respond immediately, when dropdowns lag, or when form fields feel sticky. That friction translates directly into lower engagement and fewer conversions.
Common INP problems
Heavy JavaScript execution. The main thread can only do one thing at a time. If a user clicks a button while the browser is busy executing a large JavaScript task, the interaction has to wait. Long tasks (anything over 50 milliseconds) are the primary enemy of good INP scores.
Third-party scripts. Analytics, chat widgets, ad scripts, marketing tags. Each one competes for main thread time. The cumulative effect of five or six third-party scripts can be devastating.
Excessive DOM size. Pages with thousands of DOM elements take longer to update. When the browser needs to repaint after an interaction, a bloated DOM makes that repaint slower.
Inefficient event handlers. JavaScript that runs expensive operations in response to user input without yielding back to the browser.
How to fix INP
Audit your third-party scripts and remove anything that isn’t earning its keep. Break up long JavaScript tasks so the main thread can respond to user input between chunks. Reduce your DOM size where possible. For complex interactions, consider using web workers to offload processing away from the main thread.
INP is typically the hardest of the three metrics to fix because it requires JavaScript-level changes, not just asset optimization. If your development team is resource-constrained, this is the one most likely to need a phased approach.
One more thing worth noting: INP failures often don’t surface until real users interact with the page under real-world conditions. Lab tools can estimate responsiveness through Total Blocking Time, but actual INP issues depend on when users interact and what the main thread is doing at that exact moment. This is why field data matters so much for INP specifically.
Cumulative Layout Shift (CLS): The Stability Metric
CLS measures how much the visible content shifts around unexpectedly while the page loads and while the user interacts with it. You’ve experienced bad CLS: you start reading an article, an ad loads above your text and shoves everything down, and you lose your place. Or you go to tap a link on mobile and a late-loading element pushes the link down, causing you to tap the wrong thing.
The threshold: 0.1 or lower.
CLS is calculated using a formula that combines how much content shifted with how far it moved. A small element shifting a large distance and a large element shifting a small distance can produce similar scores. The metric captures the cumulative effect of all unexpected shifts during the page’s lifecycle.
Why CLS matters beyond SEO
Layout shifts are the most directly annoying of the three CWV issues for users. They cause misclicks, disrupt reading, and make a site feel broken. On mobile, where screen real estate is limited, a layout shift of even a few pixels can cause someone to tap the wrong element.
Common CLS problems
Images and videos without dimensions. If the browser doesn’t know how tall an image will be before it loads, it reserves zero space, then shifts everything when the image finally renders. Always set explicit width and height attributes (or use CSS aspect-ratio).
Late-loading ads and embeds. Third-party ad slots that inject content after the initial render are one of the worst CLS offenders. The ad loads, claims its space, and everything below it jumps.
Dynamically injected content. Banners, cookie notices, or promotional bars that push page content down after load.
Web fonts causing text reflow. When a custom font loads and replaces the fallback font, the text can resize and shift surrounding elements. Using font-display: swap with a well-matched fallback minimizes this.
How to fix CLS
Set dimensions on all images and video elements. Reserve space for ad slots and embeds using CSS. Load web fonts with font-display: optional or font-display: swap with size-matched fallback fonts. Avoid inserting content above existing content after the initial render.
CLS is generally the easiest of the three to fix. Most fixes are CSS-level changes rather than JavaScript rewrites.
Which Metric Should You Fix First?
If your site fails all three Core Web Vitals, you need a prioritization framework. Here’s how to think about it.
Start with the metric that’s failing the worst relative to its threshold. A CLS of 0.45 is more urgent than an LCP of 3.0 seconds, because the CLS score is 4.5x the threshold while the LCP is only 1.2x the threshold. Proportional distance from “good” tells you where the biggest gap is.
Factor in fix complexity. CLS fixes are usually the simplest (CSS changes, adding image dimensions). LCP fixes are moderate (image optimization, server-side changes). INP fixes are typically the most complex (JavaScript refactoring, third-party script audits). If two metrics are equally far from passing, fix the easier one first to get quick wins.
Consider traffic impact. If 80% of your traffic is mobile and only mobile fails, focus there. If a specific page template fails and that template covers 60% of your pages, fix the template, not individual pages.
Here’s a practical decision framework:
Quick wins first. Add image dimensions (CLS), compress hero images (LCP), remove unused third-party scripts (INP). These often take hours, not weeks.
Template-level fixes second. Most sites use a handful of templates. Fix the template, fix hundreds of pages at once.
Deep JavaScript work last. INP fixes that require refactoring application code should be scoped as engineering projects with proper testing.
How Much Do Core Web Vitals Actually Affect Rankings?
This is the question that matters most to anyone allocating budget, and the honest answer is: less than you might expect from the attention they get.
Google has confirmed that Core Web Vitals are a ranking factor. But they’ve also been clear that content relevance, backlinks, and search intent alignment are far more important. Core Web Vitals work like a tiebreaker, not a dominant signal. If two pages have equally relevant content and similar authority, the one with better CWV may get the edge. But a page with great content and poor CWV will consistently outrank a page with great CWV and thin content.
John Mueller, Gary Illyes, and other Google representatives have said this repeatedly. The ranking impact is real but modest. Where CWV makes a bigger difference is in user behavior signals. A page that loads fast, responds quickly, and doesn’t jump around earns more engagement, lower bounce rates, and more conversions. Those outcomes matter whether Google is watching or not.
That said, there are situations where CWV fixes produce noticeable ranking improvements. If your site is in a competitive niche where the top results are closely matched on content quality and authority, CWV can be the differentiator that moves you from position 6 to position 3. And for sites with severely poor performance (LCP over 6 seconds, CLS over 0.5), fixing these issues removes an active drag on rankings.
The smart way to think about it: don’t optimize Core Web Vitals expecting a rankings windfall. Optimize them because they improve user experience, reduce bounce rates, and lift conversions. The SEO benefit is a bonus on top of the direct business impact.
Where to Check Your Core Web Vitals
Several tools report CWV data, and each serves a different purpose.
Google Search Console – the CWV report groups your URLs into “Good,” “Needs Improvement,” and “Poor” based on field data. This is the best place to monitor your status over time and see which URL groups have issues.
PageSpeed Insights – enter any URL and get both field data (from CrUX, if available) and lab data (from Lighthouse). The field data section shows your real-world p75 scores. The lab data section provides diagnostic details about what’s causing poor performance.
Chrome DevTools – the Performance panel lets you record a page load and see exactly what’s happening at each millisecond. This is where developers diagnose the root cause of specific issues. The Experience section within the Performance panel flags layout shifts and long tasks in real time.
Lighthouse – built into Chrome DevTools and available standalone. Runs lab-based audits and gives specific recommendations. Useful for debugging but doesn’t represent real user experience.
CrUX Dashboard – Google’s Chrome User Experience Report can be accessed via BigQuery or the CrUX API for more granular analysis. Most useful for enterprise sites tracking performance across large page sets.
Web Vitals Chrome Extension – a lightweight extension that shows real-time CWV metrics as you browse your own site. Handy for spot-checking during development.
One thing to keep in mind: if your site has low traffic, it may not have enough CrUX data to produce field scores. Google requires a minimum threshold of page loads to generate p75 field data. Newer or lower-traffic sites may only see lab data in PageSpeed Insights. In that case, lab data is your best diagnostic tool, but recognize it’s simulated, not measured from real users.
Related Metrics Worth Knowing
Core Web Vitals don’t exist in isolation. Several related metrics provide additional context.
Time to First Byte (TTFB) measures server responsiveness. It’s the time between the browser requesting a page and receiving the first byte of the response. While TTFB isn’t a Core Web Vital itself, it directly affects LCP. A slow TTFB makes it nearly impossible to hit a good LCP score because the page can’t start rendering until the server responds.
First Contentful Paint (FCP) measures when the first piece of content appears on screen. It’s an earlier signal than LCP. If FCP is slow, LCP will be slow. Think of FCP as the first sign of life and LCP as the moment the page feels usable.
Total Blocking Time (TBT) measures the total amount of time between FCP and Time to Interactive where the main thread was blocked long enough to prevent input responsiveness. TBT is a lab metric (not measured in the field), but it correlates strongly with INP. If your TBT is high, your INP is likely to be poor.
These metrics are diagnostic, not ranking factors. But they help pinpoint where the bottleneck is when a Core Web Vital fails.
Connecting CWV to Business Outcomes
Performance optimization isn’t an abstract technical exercise. It has measurable business impact, and if you’re trying to get engineering time allocated to CWV fixes, you need to make that case with numbers.
Faster pages convert better. Google’s own research found that as page load time increases from 1 second to 3 seconds, the probability of bounce increases by 32%. From 1 second to 5 seconds, that probability increases by 90%. Those aren’t theoretical numbers. They’re measured across millions of mobile page loads.
For e-commerce sites, every 100 milliseconds of improvement in load time has been associated with measurable increases in conversion rate. Vodafone ran an A/B test focused specifically on Web Vitals optimization: a 31% improvement in LCP led to an 8% increase in sales, a 15% improvement in lead-to-visit rate, and an 11% improvement in cart-to-visit rate. No visual or functional changes to the page. Just faster loading.
These aren’t guaranteed outcomes for every site, but the pattern is consistent across industries: faster, more responsive, more stable pages produce better business results. The investment case writes itself when you can show the CFO that performance work directly lifts revenue metrics.
When you’re making the case for engineering resources, frame it this way: “We’re not doing this because Google told us to. We’re doing it because faster pages make us more money, and Google happens to reward that too.” That framing gets engineering buy-in faster than any SEO argument ever will.
Staying on Top of Core Web Vitals
CWV isn’t a one-time fix. New code deploys, third-party script updates, content changes, and design revisions can all regress your scores. We’ve seen sites go from all-green CWV to failing metrics after a single marketing tag was added without testing. Build performance monitoring into your workflow so regressions get caught early.
Set up alerts in Google Search Console for CWV regressions. If a URL group drops from “Good” to “Needs Improvement,” you want to know immediately, not at the next quarterly review. Google Search Console emails these alerts automatically if you’ve verified the property and enabled notifications.
Include performance budgets in your development process. Define maximum JavaScript bundle sizes, image weights, and CLS thresholds. When a developer’s pull request pushes a page over the performance budget, it gets flagged before it ever reaches production. This is the most effective way to prevent regressions at scale.
Run Lighthouse audits as part of your CI/CD pipeline. Automated performance checks on staging environments prevent deployment of code that tanks your metrics. Tools like Lighthouse CI make this straightforward to set up, and the upfront investment pays for itself the first time it catches a regression.
Review third-party scripts quarterly. Marketing teams add scripts constantly. Each new analytics tool, chat widget, or tag manager configuration consumes main thread time and can impact INP. Audit what’s actually being used and remove what isn’t. If a script was added for a campaign that ended six months ago, it shouldn’t still be loading on every page.
Getting Your Site Where It Needs to Be
Core Web Vitals sit at the intersection of user experience and technical SEO. They won’t single-handedly determine your rankings, but failing them drags down both your search performance and your conversion rates. The fixes are often straightforward, and the impact compounds across every page of your site.
If your CWV report is full of red and amber, you don’t need to fix everything at once. Start with the quick wins, prioritize by impact, and work through the fixes methodically. And if your development team needs guidance on what to prioritize or how to implement the changes, get in touch. Our technical SEO team works directly with engineering teams to diagnose, prioritize, and fix performance issues that move the needle on both rankings and revenue.
