Core Web Vitals are three field metrics Google uses to quantify loading, responsiveness and visual stability on real visits. Largest Contentful Paint is good at 2.5 seconds or under and poor above 4.0. Interaction to Next Paint is good at 200 milliseconds or under and poor above 500. Cumulative Layout Shift is good at 0.1 or under and poor above 0.25. INP replaced First Input Delay in the Core Web Vitals set on 12 March 2024.
The thresholds are the easy part. What trips teams up is which data source Google actually reads, and how much ranking benefit months of engineering time will buy. Both have honest answers. You won’t enjoy the second.
Field data from CrUX is the only Core Web Vitals data that counts
Search Console’s Core Web Vitals report takes its numbers from the Chrome User Experience Report, which collects anonymized measurements from real Chrome users rather than running a simulation. That’s the dataset behind any page experience signal, and it’s the one your engineering team gets judged against.
Lighthouse, PageSpeed Insights lab mode and WebPageTest all run a synthetic device on a synthetic connection. They’re diagnostic tools, they’re excellent at telling you why a page is slow, and they decide nothing about where you rank. A Lighthouse score of 98 next to a failing CrUX LCP is extremely common, usually because the lab test carries neither your consent banner nor your tag manager payload.
Two mechanics matter operationally. The first is the 75th percentile rule. A group passes only when 75% of visits to its URLs reach the threshold, so a comfortable median with a slow tail still fails. That tail is normally mobile users on older hardware, which on most estates is the segment with the most commercial headroom left in it.
The second is grouping and fallback. Search Console buckets URLs into groups with a similar user experience and rolls up to origin-level groups when one doesn’t have enough data of its own. So the highest-return work almost always sits on your two or three busiest templates. Fix those and you move the number everything in the long tail inherits.
CrUX also lags, and it only sees Chrome. Chrome on iOS and the other Chromium browsers aren’t in the dataset, so a real share of your mobile traffic never shows up. So I also instrument the web-vitals library into GA4 or BigQuery. That gives you per-template, per-device numbers inside a day instead of a month, which is the difference between debugging and waiting.
What actually moves LCP on an enterprise template
Find the LCP element first. Before you change anything. It’s usually a hero image or a large block of text, and on a surprising number of templates it turns out to be something nobody expected, like a background image on a promo bar. DevTools and the field data both report it, so guessing costs you a sprint and you’ll have spent it optimizing an asset that wasn’t the one holding the page up.
Then split the metric into its four parts (time to first byte, resource load delay, resource load time and element render delay) and go after the largest. Most teams optimize the image and then discover the problem was 900ms of server response time sitting in front of it.
Serve HTML from cache at the edge. Rendering uncached HTML on every request is the most common cause of slow time to first byte on large sites, and full-page caching or incremental static regeneration usually fixes it.
Preload the LCP image and set fetchpriority="high". Check it isn’t also carrying loading="lazy", because lazy-loading your own hero is a frequent own goal.
Serve AVIF or WebP with correct srcset and sizes, so a phone isn’t pulling down a 2,400px desktop asset.
Clear render-blocking CSS and third-party font requests. Use font-display: swap with a metric-matched fallback and preconnect to the image CDN.
INP is a main thread problem before it's a framework problem
INP watches every interaction across the visit and reports at or near the worst one, which makes it unforgiving in a way FID never was. FID only measured the delay before processing started.
On enterprise sites the cause is nearly always the main thread doing work that has nothing to do with the interaction the user just made. Tag manager payloads, consent platforms, chat widgets, session recording and framework hydration all compete for the same thread, and the click handler queues behind them.
Audit the tag manager and delete every tag whose owner nobody can name. Usually the single largest INP win available, and it costs no engineering time.
Break up long tasks. Yield to the main thread, use scheduler.yield() where supported, and stop doing 200ms of work inside a click handler.
Avoid forced synchronous layout in event handlers. Read, then write, and never alternate.
Defer or island your hydration so the whole page tree isn’t becoming interactive at once.
Virtualize long lists. A 4,000-row result set re-rendering on every filter click is an INP failure by construction.
On most enterprise sites INP is a tag governance problem long before it’s a framework problem, and marketing owns more of the fix than engineering does. That lands badly in a room where everyone had agreed it was the front-end team’s fault.
CLS is mostly discipline and a performance budget
The causes are well documented and there are only a handful. Google names media without dimensions, fonts that render at a different size from their fallback, and content injected above what’s already on screen as the usual offenders.
Set explicit width and height, or aspect-ratio, on every image, iframe and embed.
Reserve space for anything injected after load. Ad slots, consent banners, promo bars, personalized hero variants.
Never insert content above existing content once the page has painted. If a banner must appear, size its container from the first byte.
Match fallback font metrics with size-adjust so the swap doesn’t reflow the article mid-sentence.
CLS is the cheapest of the three to fix and the easiest to regress, because any new marketing component reintroduces it in an afternoon. It belongs in a performance budget enforced in CI, not a quarterly audit.
How much ranking benefit to expect from Core Web Vitals
Less than the vendors selling performance tooling imply.
Google’s been consistent about this for years. The industry keeps not hearing it. Google is unusually direct about it. Search looks for the most relevant content even where the page experience is sub-par, and good results in the Core Web Vitals report (Google’s words, not mine) don’t guarantee that your pages rank at the top. A page sitting 30th because it doesn’t answer the query won’t move because LCP came down from 4.5 seconds to 2.3.
Core Web Vitals have never, in my experience, carried a page from irrelevant to competitive. What they do decide is which of two equally good pages wins. On a crowded term that’s real money, quarter after quarter, and it compounds. It just isn’t the number on the vendor’s slide.
Where they do pay is a competitive set at near parity. A tiebreaker settles the position that takes most of the clicks. There’s an indirect crawl benefit too, since Google crawls less when a site slows down or starts returning server errors, which makes the reverse worth having on a large estate.
The stronger argument is commercial, and it’s the one to take to a CFO. Page speed and conversion move together often enough in publicly reported retail and publisher experiments to treat the relationship as real. Don’t borrow somebody else’s percentage to size it. Run a before-and-after on one template, or an A/B test if traffic supports it, and measure your own elasticity.
So don’t fund a six-month performance program on the SEO case alone. Fund it on the revenue case, treat the search benefit as a secondary return, and you’ll have an argument that survives a budget review. Plenty of consultants disagree, and being useful beats selling the work.
How to start a Core Web Vitals program
Pull CrUX data grouped by template rather than by URL and work out which templates fail at the 75th percentile. Instrument web-vitals into GA4 alongside it for per-device data inside a day. Then find the real LCP element on your top three templates and break its timing into the four components before anybody writes code.
Fix the busiest template first, because origin-level fallback carries the benefit into the long tail on its own. Re-measure after a full 28-day window and not before, because reading the report on day six produces a bad meeting, a worse decision and a second program to undo the first.
If performance is tangled up with rendering strategy, which on a Next.js or Nuxt application it usually is, solve both at once rather than optimizing a template you’re about to rebuild. Getting that sequencing right is a standing part of my technical SEO engagements.