Core Web Vitals: What Actually Matters for Revenue in 2026
A practical guide to LCP, INP and CLS. Where Core Web Vitals affect conversions and revenue, which template to fix first, and what passing thresholds really buys you.
On this page
- Core Web Vitals: the short version
- Why these three metrics, and not others
- How to read your Core Web Vitals like a decision-maker
- Look per template, not per site
- Look at the slow tail, not the average
- Mobile and desktop are different products
- The metric that gets the most attention but is rarely the bottleneck
- INP is the metric most teams underinvest in
- CLS is usually a cheap fix that nobody owns
- What the evidence actually says about revenue
- Where Core Web Vitals quietly intersect with accessibility
- A prioritisation framework that survives contact with finance
- What “passing” Core Web Vitals does and does not mean
- Questions buyers actually ask
- What this looks like as a 90-day plan
- FAQ: Core Web Vitals, revenue and prioritisation
- What are the Core Web Vitals thresholds in 2026?
- Do Core Web Vitals affect Google rankings?
- What is a good LCP, INP, and CLS score?
- Why did INP replace First Input Delay?
- Is a Lighthouse score the same as Core Web Vitals?
- How long does it take for Core Web Vitals improvements to show up?
- Should we look at Core Web Vitals per page or sitewide?
- XIII Studios point of view
- Closing thoughts
Someone in your team has probably mentioned Core Web Vitals. There were three letters involved - LCP, INP, CLS - a colour-coded chart, and a vague suggestion that Google cares about them. You nodded; the chart got filed.
This article is the version of that conversation that actually helps you decide where to spend money. Core Web Vitals are not an SEO checkbox. They are three measurements of friction between your visitors and the thing you want them to do; buy, book, enquire, sign up. Google chose them because they correlate with abandonment, and real businesses have measured what happens when they fix them. The numbers are large enough to matter to a board.
This piece walks through what each metric actually costs you, where to look first, and how to recognise when a “performance project” is really a revenue project; grounded in Google’s own thresholds and case studies (opens in new tab), the Deloitte / Google / Fifty-Five “Milliseconds Make Millions” study (opens in new tab), and a stack of published before/after results.
Core Web Vitals: the short version#
Three metrics, three forms of commercial failure: LCP is the cost of making someone wait for the promise, INP is the cost of making them wait once they have committed, CLS is the cost of making them click the wrong thing. Google’s “good” thresholds - LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1 - are measured at the 75th percentile of real visits, which is a long way from the average laptop on fibre most teams test on.
Most agencies are slow, expensive, and unnecessarily complicated about this. They sell passing Google’s thresholds as the finish line. It is the floor. The case study evidence is consistent: revenue keeps moving as you push past “good” on the templates that drive the money.
If you only do three things:
- Look at your Core Web Vitals per page template (homepage, product, listing, checkout), not as a sitewide score.
- Prioritise fixes on the templates that earn the money, not the ones that are easiest to fix.
- Tighten your targets below Google’s thresholds on those money pages.
Why site speed actually matters covers the upstream commercial case - bounce, conversion, SEO. This piece is the next layer down: which of the three metrics is costing you what, and where to spend first.
Why these three metrics, and not others#
Google did not pick these by committee. They picked them because they map to the three ways a page can fail a user before the user even gets to act.
Chromium’s Science Behind Web Vitals (opens in new tab) analysis of millions of page impressions reports that when a site meets Core Web Vitals thresholds, users are 24% less likely to abandon before any content has painted. That number alone justifies the framework. The same data holds for news and shopping sites.
Each metric maps to a distinct commercial cost.
LCP: the cost of making someone wait for the promise.
Largest Contentful Paint is when the main thing on the page becomes visible; the hero, the product image, the headline. Until that appears, your visitor cannot tell whether they are on the right page. Renault found that a 1-second LCP improvement (opens in new tab) drove a 14 percentage point reduction in bounce rate and a 13% increase in conversions. Vodafone’s A/B test (opens in new tab), where Web Vitals work was the only change, turned a 31% LCP improvement into 8% more sales.
INP: the cost of making someone wait after they have committed.
Interaction to Next Paint measures how quickly the page responds when someone taps, types, or clicks. This is the metric that breaks when a filter takes a second to respond, when “add to cart” feels stuck, when a form drops a keystroke. Trendyol reduced INP by 50% (opens in new tab) on listing pages and saw a 1% lift in click-through to product. QuintoAndar cut INP by 80% (opens in new tab) and lifted conversions 36% year-on-year.
CLS: the cost of making someone click the wrong thing.
Cumulative Layout Shift measures how much the page jumps around while loading. Late-arriving images, ads, banners, and consent prompts shove content downward; and visitors mis-tap, mis-trust, and bounce. Farfetch reported (opens in new tab) that exit rate fell by 3.1% for every 0.01 improvement in CLS.
The reason there are three metrics, not one, is that they break the experience at different stages. Fast loading is not enough if the page then feels broken under your thumb. Snappy interaction is not enough if the layout jumps the moment you reach for a button. They have to hold up together.
How to read your Core Web Vitals like a decision-maker#
The way most owners see CWV data (a single sitewide green/amber/red) is the least useful view possible. Two things change that view immediately.
Look per template, not per site#
Your homepage, your product detail page, your category/listing page, your lead form, and your checkout each behave differently. Different code, different images, different third-party scripts, different intent.
Deloitte’s Milliseconds Make Millions (opens in new tab) study - 37 brands, 30 million mobile sessions - found that in retail, the steepest sensitivity to speed sits between the product detail page and the basket. Not the homepage. Their explicit recommendation: focus more on product pages than the homepage.
Translate that to your own situation: if your business runs on paid ads, the landing template is your money page. If it runs on organic listings, the listing template is. If it runs on a quote form, the form page is. The Core Web Vitals score that matters is the one on those templates, not the average across the site.
Look at the slow tail, not the average#
Google reports CWV at the 75th percentile. That is already a step beyond averages, but on high-value pages it is worth going further. Field-measurement guidance recommends looking at p90 and p95 (opens in new tab) on important templates; those are the customers having the worst experiences, and they are often the ones you can least afford to lose.
A site that “passes” Core Web Vitals at p75 but has a brutal p90 is leaking the most expensive 25% of its visits. That is fine on a low-traffic blog. It is a serious problem on a checkout page.
Mobile and desktop are different products#
Splitting the data by device is non-negotiable. Mobile has slower CPUs, slower networks, and more interactions per session. The same code can pass on desktop and fail badly on mobile. Most published case studies - Vodafone, Trendyol, Renault, QuintoAndar - report mobile and desktop separately because the conclusions are different.
The metric that gets the most attention but is rarely the bottleneck#
When LCP is slow, the instinct is to compress the hero image. Sometimes that works. Most of the time it does not, because the image download is rarely where the time is going.
Google’s field-data breakdown of poor LCP (opens in new tab) splits the metric into four sub-parts:
LCP sub-part
What it really is
LCP sub-part
What it really is
LCP sub-part
What it really is
LCP sub-part
What it really is
| LCP sub-part | What it really is |
|---|---|
| TTFB | How long before the server starts responding at all |
| Resource load delay | How long before the browser even *requests* the image |
| Resource load duration | How long the image takes to download |
| Element render delay | How long after the image arrives before it appears on screen |
On a typical poorly-performing page, the image download is the smallest sub-part. The biggest contributors are the server response time and the delay before the browser knows the image exists.
This matters commercially because it changes who fixes the problem. “Compress the hero image” is a designer task. “Reduce TTFB” is a hosting and backend task. “Make the LCP image discoverable in HTML and preload it” is a frontend developer task. If your performance work is being scoped as “compress images” and your TTFB is two seconds, you are paying for the wrong fix.
A good signal: when someone proposes LCP work, ask which of the four sub-parts is the largest. If they cannot answer, the diagnosis has not been done.
INP is the metric most teams underinvest in#
INP became a Core Web Vital in March 2024, replacing First Input Delay (opens in new tab) because FID only measured the first tap. INP measures responsiveness across the whole visit; every interaction.
That change matters because the interactions that drive revenue are rarely the first one. Filtering a listing page. Choosing a variant on a product page. Typing into a checkout form. Tapping “submit”. Each of those is an INP event, and each is a place where the page can feel broken without ever looking broken in a screenshot.
The 2024 Web Almanac (opens in new tab) found that 74% of mobile sites have “good” INP overall, but the figure drops to 53% on the top 1,000 sites, with a median long task duration of 108ms on mobile; ore than double the 50ms threshold that defines a “long task”. The more interactive a site is, the harder responsiveness becomes, because more interactivity usually means more JavaScript blocking the main thread when the user taps.
INP problems rarely show up in a Lighthouse run because Lighthouse is mostly a load-time test. They show up when someone tries to use the site. If your performance reporting never mentions INP - only LCP - you are missing the metric most likely to be quietly costing you conversions on interactive pages.
CLS is usually a cheap fix that nobody owns#
The most common cause of layout shift is an image without width and height attributes. The 2024 Web Almanac (opens in new tab) found that 66% of mobile pages fail to set explicit dimensions on at least one image, and the median page has two unsized images.
The fixes are technically small: size your images, reserve space for ads and embeds, stop dynamically inserting content above existing content, and make sure font swaps do not reflow your headlines. Cookie banners and consent widgets are the chronic offenders; they protect a legal objective at the cost of CLS and accidental clicks on whatever is underneath them.
The reason CLS often goes unfixed is not technical. It is ownership. The marketing team owns the consent banner. The ads team owns the ad slots. The frontend team owns the image markup. CLS is the metric where nobody is responsible for the whole picture, and it stays broken on otherwise well-built sites for that reason.
For an executive, CLS is one of the most useful metrics to ask about. It is cheap to fix relative to its conversion impact, and a high CLS number is usually a sign of process problems, not engineering problems.
What the evidence actually says about revenue#
The case study evidence on Core Web Vitals is strong enough to act on, but it deserves an honest read.
The cleanest examples are the A/B tests and controlled rollouts where performance was the only meaningful change:
Company
Change
Business result
Company
Change
Business result
Company
Change
Business result
Company
Change
Business result
Company
Change
Business result
Company
Change
Business result
| Company | Change | Business result |
|---|---|---|
| Vodafone | 31% LCP improvement (A/B test) | +8% sales |
| Trendyol | 50% INP reduction (A/B test) | +1% CTR to product pages |
| QuintoAndar | 80% INP reduction | +36% conversions YoY |
| Renault | 1-second LCP improvement | −14pp bounce rate, +13% conversions |
| Rakuten 24 | Core Web Vitals work | +33% conversion rate, +53% revenue per visitor |
| Farfetch | LCP and CLS work | −1.3% conversion per +100ms LCP, −3.1% exit rate per −0.01 CLS |
The broader Deloitte / Google / Fifty-Five retail study (opens in new tab) found that a 0.1-second improvement in mobile speed correlated with +8.4% conversion rate and +9.2% average order value in retail, and that progression from product page to basket improved +9.1%.
The honest caveat: most case studies are before/after, not pure experiments. Marketing changes, seasonality, and product launches all confound the numbers. The Deloitte study itself warns that its results should be treated as directional, not as a universal calculator. “Every 100ms is worth X%” is not a claim the evidence supports.
What the evidence does support is narrower and more useful:
- There is real money in Core Web Vitals, not just nicer scores.
- The biggest gains sit on high-intent pages and interactions, not the homepage.
- The right way to size investment is observational analysis first, then a controlled A/B test on the most valuable template.
That is the pattern Vodafone, Trendyol, and Farfetch all followed: model the opportunity, ship the change in isolation, read both the metric and the revenue.
Where Core Web Vitals quietly intersect with accessibility#
Core Web Vitals and accessibility are usually treated as separate workstreams. They should not be.
CLS is not a cosmetic problem when shifting layouts make people miss buttons; particularly on mobile, and particularly for users with motor difficulties. INP is not abstract for keyboard users or for people on assistive technology and lower-spec devices, where every interaction needs to respond predictably. LCP is part of whether content is actually available to everyone, not only to visitors on fast networks.
Treating performance and accessibility as one brief - measured together, fixed together, owned by the same people - almost always produces a better commercial result than tackling them as separate projects on different timelines.
A prioritisation framework that survives contact with finance#
Most performance plans fail not because the engineering is wrong but because the prioritisation is wrong. Here is a framework that holds up in front of a board.
Priority = traffic × revenue per visit × performance sensitivity × metric gap × fixability
That is not a Google standard. It is the most defensible synthesis of the case study evidence.
- Traffic is obvious; fix where the visits are.
- Revenue per visit weights the high-intent templates: checkout, product, lead form.
- Performance sensitivity is the variable most teams skip. Retail and lead gen are highly sensitive. A read-only knowledge base is much less so.
- Metric gap is how far you are from “good” on the relevant Core Web Vital. A small gap is sometimes harder to close than a large one.
- Fixability is the engineering reality check; small change vs. platform-level rebuild.
Different business models weight this differently. Retail loads weight on product detail and listing pages. Lead generation loads weight on landing and form pages. Subscription products load weight on signup and onboarding flows. Whatever the model, the principle is the same: rank your top ten templates by revenue at risk, not by sitewide score, and start there.
What “passing” Core Web Vitals does and does not mean#
This is where most performance proposals quietly mis-sell you. Passing Google’s thresholds is the floor. A lot of the industry sells it as the ceiling.
Passing them buys you three things:
- You are no longer leaving an obvious SEO signal on the table.
- You are removing the most punishing experience problems from the slow tail.
- You are no longer the worst-performing site in your category.
It does not buy you the conversion ceiling. The case study evidence consistently shows gains continue below the thresholds on high-value pages. Tightening internal budgets, for example, LCP ≤ 1.8s on the product page even though Google considers ≤ 2.5s “good”, is where the second wave of revenue comes from.
A useful executive question: “Where on our site are we already passing CWV but still leaking conversions to the slow tail?” The answer is usually where the next investment should go.
Questions buyers actually ask#
“We have a 90+ Lighthouse score. Are we fine?”
No, and not for the reason you think. HTTP Archive analysis (opens in new tab) found that 43% of pages with a Lighthouse score of 90+ still failed at least one Core Web Vitals threshold in the field. Lighthouse is a lab tool on a controlled device. Your customers are not on a controlled device. Always read the field data.
“Does Google actually rank on this?”
Yes, but it is one signal among many. Treat it as a competitiveness lever, not a “rank #1” lever. The bigger commercial story is direct user behaviour, abandonment, conversion, exit rate; not the ranking change.
“How long until improvements show up?”
Field data (CrUX) is a 28-day rolling window (opens in new tab). You will see the change in your own RUM in days; you will see it in Search Console and PageSpeed Insights in weeks. Plan the conversation with your stakeholders accordingly.
“Should we focus on mobile or desktop?”
Mobile, almost certainly. The slow tail is mobile, the case study evidence is mobile, and the metric thresholds are harder to hit on mobile. Desktop usually follows for free.
“Is this an engineering project or a product project?”
Both. The biggest CWV wins on most sites are product decisions; what goes in the hero, how many third-party scripts the marketing team has added, whether the consent banner is allowed to shove content. If your performance work is scoped as engineering-only, you are leaving the cheapest gains on the table.
What this looks like as a 90-day plan#
Most owners do not need a research project. They need an order of operations.
- Weeks 1–2: instrument and segment. Get Core Web Vitals data per template, split by device. Use PageSpeed Insights (opens in new tab), Search Console (opens in new tab), or your own RUM. Stop relying on a sitewide green/amber/red.
- Weeks 3–4: rank by revenue at risk. Map your top ten templates against revenue contribution and metric gap. Pick the top two or three.
- Weeks 5–8: fix the biggest sub-part first. For LCP, that is usually TTFB or resource load delay before image weight. For INP, it is usually long tasks and startup JavaScript. For CLS, it is sizing and reserved space.
- Weeks 9–10: validate with a controlled rollout. A/B test if you can. If you cannot, stagger the release and read both the metric and the revenue KPI together.
- Weeks 11–12: set guardrails. Performance budgets and alerts so the next feature release does not undo the work.
That is the difference between a performance project and a revenue project. The work is largely the same. The framing - and therefore the prioritisation, the team involvement, and the success criteria - is completely different.
FAQ: Core Web Vitals, revenue and prioritisation#
What are the Core Web Vitals thresholds in 2026?#
LCP ≤ 2.5 seconds, INP ≤ 200 milliseconds, and CLS ≤ 0.1, measured at the 75th percentile of real visits, split by mobile and desktop. Hitting those is the floor for “good” - not the ceiling. Case study evidence (Vodafone, Renault, Trendyol, Farfetch) shows revenue continues to move as you push tighter on the templates that actually earn money.
Do Core Web Vitals affect Google rankings?#
Yes, but as one signal among many. Treat CWV as a competitiveness lever for SEO and a conversion lever for revenue; the bigger commercial story is direct user behaviour (abandonment, conversion, exit rate), not the ranking change. Chromium’s own data shows users are 24% less likely to abandon a page that meets CWV thresholds.
What is a good LCP, INP, and CLS score?#
“Good” is LCP ≤ 2.5s, INP ≤ 200ms, CLS ≤ 0.1 at p75. On revenue-critical templates it is worth setting tighter internal budgets - for example LCP ≤ 1.8s on a product page - because the published case studies consistently show conversion gains continuing below Google’s thresholds.
Why did INP replace First Input Delay?#
FID only measured the first interaction on a page, which rarely reflects how the site actually feels. INP measures responsiveness across the whole visit - every tap, click and keystroke - and replaced FID as a Core Web Vital in March 2024. It is the metric most likely to be quietly costing conversions on interactive pages.
Is a Lighthouse score the same as Core Web Vitals?#
No. Lighthouse is a lab test on a synthetic device. Core Web Vitals are measured in the field on real visits. HTTP Archive analysis found that 43% of pages with a Lighthouse score of 90+ still failed at least one CWV threshold in field data. Always read the field data (CrUX, Search Console, RUM) before declaring a site “fast enough”.
How long does it take for Core Web Vitals improvements to show up?#
Field data uses a 28-day rolling window. You will see the change in your own RUM within days, in PageSpeed Insights and Search Console within weeks. Conversion impact usually shows up immediately on the templates you fixed.
Should we look at Core Web Vitals per page or sitewide?#
Per template, split by device. A sitewide score hides the answer. The Deloitte / Google retail study found the steepest revenue sensitivity sits between the product detail page and the basket - not the homepage. Rank your top templates by revenue at risk, not by sitewide green/amber/red.
XIII Studios point of view#
Most clients we meet have at least one Core Web Vital failing on at least one money page, and most of them did not know it until we showed them. The reason is almost always the same: their reporting view is sitewide, the score is averaged, and the slow tail on the templates that actually drive revenue is invisible.
Our website performance optimisation work - page speed, Core Web Vitals improvements, technical audits - starts by putting real-user data per template in front of the people who own the revenue, not just the people who own the code. We split the metrics into sub-parts, prioritise by impact and fixability, and tie the work back to a measurable business outcome.
AI-assisted workflows make the diagnostic side of this faster - sitewide pattern matching across templates, cross-referencing CrUX with code locations, drafting the boilerplate fixes (image dimensions, loading attributes, deferred third-parties) so engineers can spend their time on the trade-offs that actually require judgement. The decisions that move revenue - which template gets defended first, which third-party earns its weight, which Core Web Vital is worth chasing this quarter - still belong to people with full business context. AI shortens the diagnosis. It does not change who owns the call.
Closing thoughts#
A Core Web Vitals score is not a verdict on your website. It is a measurement of how much friction sits between your visitors and your business outcome; and how unevenly that friction is distributed across your most valuable pages.
The sitewide green-amber-red view hides the answer. The per-template, slow-tail, per-device view reveals it. Once you can see which template is leaking and which metric is the cause, the work becomes a prioritisation problem with a known shape; not a vague “we should look at performance” line item that never gets scheduled.
The boring version: look at your metrics per template, fix the biggest sub-part on your highest-value pages first, and tighten the targets below Google’s thresholds where the money is. Pass the floor, then beat it.
XIII Studios builds high-performance websites and software without the usual agency overhead.
If your Core Web Vitals report is a sitewide colour and you are not sure what to spend on first, start with a website audit (opens in new tab). We will review your site and give you clear, actionable feedback on which template is leaking, which metric is the cause, and whether it is worth fixing now or later.
