Core Web Vitals are Google's three user-experience metrics that measure how fast a page loads, how quickly it responds and how visually stable it stays: LCP (Largest Contentful Paint), INP (Interaction to Next Paint) and CLS (Cumulative Layout Shift). They matter because they feed both search ranking and real conversion behaviour — slow, janky pages lose customers before they ever see your offer.
What are the three Core Web Vitals in 2026?
The Core Web Vitals are three metrics, each with a defined "good" threshold measured at the 75th percentile of real visits. You want most of your users, not just the lucky fast ones, to fall inside these bounds.
- LCP — Largest Contentful Paint (loading): the time until the largest visible element, usually a hero image, heading or video, has rendered. Good is under 2.5 seconds.
- INP — Interaction to Next Paint (interactivity): how quickly the page visibly responds to taps, clicks and key presses across the whole visit. Good is under 200 milliseconds.
- CLS — Cumulative Layout Shift (visual stability): how much content unexpectedly jumps around as the page loads. Good is under 0.1.
The important change to internalise: INP replaced FID (First Input Delay) as a Core Web Vital in March 2024. FID only measured the delay before the first interaction was processed; INP is far stricter, measuring the full latency of interactions throughout the session. Many sites that comfortably passed FID now fail INP, because the metric finally reflects how sluggish a heavy JavaScript page feels in real use.
Why do Core Web Vitals affect ranking and revenue?
Core Web Vitals are a confirmed part of Google's page-experience signals. They will not rescue thin content, but between two comparable pages, the faster and more stable one has an edge — and that edge compounds across thousands of queries. For competitive commercial keywords across Europe, performance is one of the few technical levers still fully in your control.
The stronger argument is commercial. Every hundred milliseconds of delay measurably erodes conversion, and layout shifts that move a button under a user's thumb cause mis-taps, frustration and abandonment. Performance is not a back-office engineering concern; it is directly upstream of your checkout completion rate and your cost per acquisition. Faster pages turn the same traffic into more revenue, which is why we treat Core Web Vitals as a design and business metric, not just a Lighthouse score.
Field data versus lab data: measure the right thing
There are two ways to read your vitals, and confusing them is the most common mistake teams make.
- Field data (CrUX): the Chrome User Experience Report aggregates real Chrome users' experiences over a rolling 28-day window. This is what Google uses for ranking and what actually reflects your customers, including their older phones and patchy mobile connections.
- Lab data (Lighthouse): a single synthetic test in a controlled environment. Excellent for debugging and catching regressions in CI, but it is a simulation — it cannot report INP, because there is no real user interacting.
Use lab data to diagnose and reproduce, and field data to decide whether you have actually passed. A perfect Lighthouse score means little if your CrUX report shows real users on mid-range Android devices timing out. Segment your field data by device and country too — a page that flies on London fibre can crawl on a rural Baltic 4G connection.
How to fix LCP (loading)
LCP problems are almost always about the hero and the resources blocking it. The largest element needs to arrive fast and early.
- Serve hero images in modern formats (AVIF, WebP), correctly sized and responsive; never ship a 3000px image to a phone.
- Preload the LCP image and set fetchpriority="high" so the browser fetches it first.
- Deliver critical CSS inline and defer the rest so the first paint is not blocked.
- Adopt a disciplined font strategy: self-host, subset, preload key fonts and use font-display: swap to avoid invisible text.
- Put static assets behind a CDN with edge caching so European users are served from a nearby node, not a distant origin.
How to fix INP (interactivity)
INP is a main-thread problem. When JavaScript monopolises the main thread, the browser cannot respond to input, and the interaction feels dead. The fixes are about doing less work, later.
- Ship less JavaScript. Audit your bundle, remove dead code and lazy-load anything not needed for the first interaction.
- Break up long tasks so the main thread can respond between chunks rather than freezing.
- Review hydration in your framework — full-page hydration is a frequent INP killer. Prefer partial or progressive hydration and server-render what you can.
- Debounce expensive handlers and move heavy computation to a web worker.
- Reserve heavy work until after the user has interacted, not on initial load.
How to fix CLS (visual stability)
CLS is the most preventable of the three, and it is almost entirely a matter of reserving space before content arrives.
- Always set explicit width and height (or aspect-ratio) on images, video and embeds so the browser reserves the box.
- Reserve space for ads, banners and any late-loading third-party widget rather than letting them push content down.
- Preload fonts to avoid the reflow when a web font swaps in.
- Insert dynamic content, cookie banners and notifications without shoving existing content around.
Third-party scripts: the usual culprit
Analytics tags, chat widgets, A/B testing tools and marketing pixels are the single most common cause of degraded vitals, because they run on your main thread with none of your performance discipline. Audit every tag ruthlessly and ask whether it earns its cost. Load what remains asynchronously or deferred, consider a server-side or edge tag setup, and treat a heavy chat widget as a conversion trade-off, not a free addition. This is where performance-minded web design pays off — a lean page has fewer places for third parties to hide.
The prioritised performance checklist
You cannot fix everything at once, so sequence the work by impact. Start with what your field data flags as failing, and move in this order.
- Measure first: pull CrUX field data, segmented by mobile and desktop, to see which vital is actually failing for real users.
- Fix the hero: optimise, size and preload the LCP element — usually the fastest visible win.
- Cut JavaScript: trim and defer bundles and rethink hydration to bring INP under control.
- Reserve space: add dimensions and placeholders to eliminate layout shift.
- Tame third parties: defer, remove or move tags to the edge.
- Monitor continuously: add Lighthouse to CI and watch field data so regressions surface before customers feel them.
Performance is a design decision as much as an engineering one. The heavy hero video, the extra web font, the animation library, the fourth analytics tool — each is a trade against speed, and each should be chosen deliberately. Teams that treat Core Web Vitals as part of the design brief, alongside UX and conversion goals, ship faster products that rank and convert better across the UK, the Baltics and the wider European market. If your vitals are dragging revenue down, that is exactly the kind of problem we like to fix.
Frequently asked questions
What are good Core Web Vitals scores?
At the 75th percentile of real users, LCP should be under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1. These thresholds are measured on real visits, so most of your audience — including people on older phones and slower networks — needs to fall inside them, not just your fastest users.
When did INP replace FID?
INP (Interaction to Next Paint) replaced FID (First Input Delay) as a Core Web Vital in March 2024. INP is stricter: FID only measured the delay before the first interaction was processed, while INP measures the full latency of interactions across the whole visit, better reflecting how responsive a page actually feels.
What is the difference between field data and lab data?
Field data (from the Chrome User Experience Report) reflects real users over a rolling 28-day window and is what Google uses for ranking. Lab data (from Lighthouse) is a single synthetic test, ideal for debugging and CI. Lighthouse cannot measure INP because no real user is interacting, so pass or fail on field data.
Do Core Web Vitals affect Google rankings?
Yes. Core Web Vitals are a confirmed part of Google's page-experience signals. They will not outrank genuinely better content, but between comparable pages the faster, more stable one gains an edge that compounds across many queries. Their bigger impact is commercial: better vitals lift conversion and lower acquisition cost.
What most commonly hurts Core Web Vitals?
Third-party scripts — analytics tags, chat widgets, A/B tools and marketing pixels — are the most frequent cause, because they run on the main thread without your performance discipline. Oversized hero images hurt LCP, heavy JavaScript and hydration hurt INP, and unsized images or injected banners hurt CLS.