In an A/B test run by Vodafone Italy on two visually and functionally identical pages, a 31% improvement in LCP was enough to drive 8% more sales — according to the official web.dev case study. This is not a technical footnote for your development team: it is a direct revenue variable. Core Web Vitals precisely measure the experience that determines, in the first few seconds, whether a visitor buys, gets in touch, or leaves for a competitor.
If you manage a B2B company website, this concerns you just as much as it would an e-commerce store. A contact form that lags on submission, a hero image that shifts as it loads, or a slow mobile page are silent conversion leaks. In this guide you will learn exactly what Core Web Vitals are, what thresholds Google requires in 2026, how to measure them with reliable data, and how to optimize each metric step by step.
What Are Core Web Vitals and Why Do They Matter for SEO in 2026
Core Web Vitals are a subset of page experience signals that Google considers essential for evaluating the real user experience on any website. They do not measure whether a page "looks nice" — they measure three quantifiable dimensions of how it behaves: how quickly the main content appears, how it responds to user interactions, and how much the layout shifts while loading.
In 2026, there are three metrics:
- LCP (Largest Contentful Paint) — how fast the largest visible element loads.
- INP (Interaction to Next Paint) — responsiveness to user interactions.
- CLS (Cumulative Layout Shift) — visual stability of the layout.
They matter for SEO because they form part of the page experience signals Google evaluates. But they matter even more for the business itself. Google has documented results such as iCook increasing ad revenue by 10% after improving CLS by 15%; Tokopedia seeing a 23% increase in average session duration after reducing LCP by 55%; and Nykaa achieving 28% more organic traffic after improving LCP by 40%. These figures come from the web.dev case study repository — not from agency estimates.
The practical takeaway: optimizing Core Web Vitals is not "plumbing work" that only pleases Google. It is a lever for conversion, retention, and ultimately, commercial pipeline.
LCP, INP and CLS: Google's Recommended Thresholds
Google does not use a continuous scale: it classifies each metric into three categories — "good", "needs improvement", and "poor" — based on fixed thresholds. To pass, your goal is always the "good" category. These are the official values from web.dev's documentation on defining Core Web Vitals thresholds:
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP | Load speed of the main content | <= 2.5 s | 2.5 s – 4.0 s | > 4.0 s |
| INP | Responsiveness to interactions | <= 200 ms | 200 ms – 500 ms | > 500 ms |
| CLS | Visual stability (layout movement) | <= 0.1 | 0.1 – 0.25 | > 0.25 |
There is a nuance that completely changes how you should interpret your reports: Google evaluates these thresholds at the 75th percentile of real visits. That means for a URL to pass a metric, at least 75% of page views must reach the "good" threshold. It is not enough for the page to be fast on your high-end laptop with fiber internet: it also needs to be fast for the fourth-slowest user out of every four — typically someone with a mid-range phone on a patchy mobile connection.
That is why a page can "feel fast" when you test it yourself and still fail Core Web Vitals in the field. The 75th percentile forces you to design for the worst reasonable case, not the best.
Why INP Replaced FID in March 2024
For years, the responsiveness metric was FID (First Input Delay), which only measured the delay on the first user interaction — and even then, only the delay until the browser started processing it. It was a generous metric: most sites passed it easily, making it poor at distinguishing truly smooth experiences from those that were not.
INP (Interaction to Next Paint) officially replaced FID as the Core Web Vitals responsiveness metric on March 12, 2024, having been announced on January 31 of that year, according to the web.dev blog. The difference is substantial:
- FID measured only the first interaction; INP observes all interactions during the session and reports (approximately) the worst one.
- FID measured only the input delay; INP measures the full cycle, all the way through to when the next paint visually reflects the response.
In practice, INP is far more demanding — and far more representative of how users perceive the responsiveness of your site. A page that opened menus slowly, validated forms with a lag, or reacted sluggishly to clicks — things invisible to FID — is now exposed. For B2B sites with long forms, product filters, or configurators, this change was especially significant.
How to Measure Your Core Web Vitals: PageSpeed Insights, CrUX and Search Console
Here is the most common — and most costly — mistake: confusing lab data with field data. They are not the same thing, and only one of them counts for rankings.
Field Data vs. Lab Data
- Field data: measurements from real users visiting your site, collected via the Chrome User Experience Report (CrUX). This is a rolling 28-day average.
- Lab data: a controlled simulation in a fixed environment, generated by Lighthouse.
According to web.dev's documentation on why lab and field data can differ, Google uses only CrUX field data for rankings — not Lighthouse lab data. Lab data is useful for diagnosis: it tells you why something is wrong, but it is not the score that matters. This is why it is perfectly possible to score 100 in Lighthouse and still fail Core Web Vitals in CrUX if your real users have a worse experience than the simulated environment assumes.
Which Tool to Use for What
| Tool | Data type | Granularity | Best use |
|---|---|---|---|
| PageSpeed Insights | Field (CrUX) + lab (Lighthouse) | Individual URL; CrUX updated daily | Diagnosing a specific page |
| Google Search Console | Field only (CrUX) | Aggregated by URL groups | Site health overview and identifying problematic URLs |
| Lighthouse / DevTools | Lab only | Individual URL, on-demand run | Debugging and testing improvements before deploying |
According to Google for Developers' documentation on PageSpeed Insights, the tool displays both CrUX field data (updated daily at URL level) and Lighthouse lab data. Google Search Console, by contrast, reports exclusively CrUX field data aggregated by URL groups, making it the ideal dashboard for identifying at scale which templates or site sections are failing.
The recommended workflow:
- Search Console to identify which URL groups are failing.
- PageSpeed Insights to diagnose why a representative URL is underperforming.
- Lighthouse / DevTools to iterate on fixes locally.
- Deploy and wait for the 28-day CrUX rolling average to register the improvement.
That last point is critical: because CrUX is a 28-day average, a fix does not appear instantly. Patience is required — do not revert good changes out of impatience.
How to Optimize Each Metric Step by Step
Each Core Web Vital has distinct root causes and, therefore, distinct solutions. Here is a prioritized checklist based on typical impact.
Optimizing LCP (<= 2.5 s)
LCP is usually constrained by how long it takes to load and render the main element — typically a hero image, a large text block, or a video.
- Serve the LCP image with priority (
fetchpriority="high") and avoid lazy-loading on that specific element. - Optimize image format (AVIF or WebP) and size correctly for each breakpoint.
- Preload critical resources (fonts, hero image) and eliminate render-blocking resources.
- Reduce server response time (TTFB) with caching, a CDN, and efficient rendering.
- Minimize critical CSS and JavaScript that delays the first paint.
Optimizing INP (<= 200 ms)
INP is almost always caused by JavaScript blocking the main thread when the user interacts.
- Break up long tasks into smaller chunks to avoid blocking the thread.
- Defer or eliminate non-essential third-party JavaScript (live chats, widgets, heavy marketing tags).
- Use
content-visibilityand deferred rendering for off-screen content. - Avoid unnecessary re-renders in frameworks like React by optimizing state and memoization.
- Provide immediate visual feedback on interaction even if processing continues in the background.
Optimizing CLS (<= 0.1)
CLS is the cheapest to fix and the most irritating for users: elements jumping just as they are about to click.
- Reserve space for images and videos using
widthandheightattributes oraspect-ratio. - Reserve space for ads and embeds before they load.
- Preload fonts and use
font-display: optionalorswapto avoid text reflows. - Never inject content above existing content except in direct response to a user action.
- Animate with
transform, not with properties that trigger layout recalculation.
This type of work — field data measurement, performance budgets, and impact-prioritized fixes — is exactly what we address in a well-governed technical SEO engagement, where performance stops being an occasional incident and becomes a continuous quality standard. And when the problem lies in the codebase itself, we resolve it at the web development layer, intervening in front-end architecture, rendering, and asset delivery.
Do Core Web Vitals Actually Affect Rankings?
This is the million-dollar question, and the honest answer has two parts.
Yes, they are a ranking signal — but not the most important one. According to Google Search Central's documentation on Core Web Vitals, Google confirms that page experience — including Core Web Vitals — is one of the many signals its systems evaluate. In the same source, Google explicitly states that great content remains the priority over page experience.
How to translate this into a realistic strategy:
Core Web Vitals will not rank mediocre content above excellent content. But when two pages compete with comparable quality content, page experience can be the tiebreaker — and, more importantly, the factor that determines whether the visitor who arrives actually stays and converts.
That is why the correct approach is not to chase a Lighthouse score of 100 as an end in itself, but rather to:
- Prioritize valuable content first that genuinely answers the search intent.
- Pass Core Web Vitals at the 75th percentile of real users as a non-negotiable quality standard.
- Treat performance as a business variable, not just an SEO one, given its proven impact on conversion and retention.
The greatest risk is not being a few milliseconds above a threshold: it is ignoring field data entirely and discovering, month after month, why users are leaving — while lab data explains nothing.
Want to know where your site is losing performance and how much it is costing you in conversions? At Technova Partners we audit your Core Web Vitals using real field data, prioritize fixes by business impact, and implement them until you pass at the 75th percentile. Talk to our team and turn web performance into a measurable competitive advantage.
