Core Web Vitals are three measurements that describe how a page feels to a real person on a real device. Google uses them as a ranking signal, but the stronger argument is commercial: pages that pass all three convert noticeably better, because people do not wait for slow interfaces.
The three metrics in plain terms
- LCP, Largest Contentful Paint: how long until the main visual element is visible. Target under 2.5 seconds.
- INP, Interaction to Next Paint: how quickly the page responds after a tap or click. Target under 200 milliseconds.
- CLS, Cumulative Layout Shift: how much the layout jumps while loading. Target under 0.1.
Measure them in the field, not in the lab. Lighthouse gives you a simulated score on a simulated device. The Chrome User Experience Report and the Search Console report show what your actual visitors experienced over the past 28 days. When the two disagree, the field data is right.
Fixing LCP
In nine out of ten cases the largest element is the hero image or the headline above it, and the delay comes from three sources: a slow server response, render-blocking resources, and an image that starts downloading too late.
- Serve cached HTML from an edge location so the server responds in under 200 milliseconds.
- Preload the hero image and give it fetchpriority high; remove lazy loading from anything above the fold.
- Deliver images as AVIF or WebP with explicit width and height, sized for the breakpoint actually used.
- Self-host fonts, subset them to the characters you need, and use font-display swap with a matched fallback.
- Move third-party scripts such as chat widgets and tag managers below the fold or defer them entirely.
Fixing INP
INP replaced First Input Delay in March 2024 and is much harder to fake. It measures the full path from interaction to the next painted frame, so long JavaScript tasks are punished directly. The usual culprits are hydration of large component trees, unnecessary state updates and analytics listeners that run on every scroll.
Break long tasks above 50 milliseconds into smaller pieces, defer non-critical work with scheduler yielding, and reduce the amount of JavaScript shipped at all. In a React application, moving static sections to server components is usually the single most effective change: less code to parse, less to hydrate, less to block the main thread.
Every kilobyte of JavaScript you do not ship is a kilobyte that never has to be parsed on a five-year-old phone.
Fixing CLS
- Always set width and height or an aspect ratio on images, videos and iframes.
- Reserve space for consent banners, cookie bars and advertising slots before they load.
- Avoid inserting content above existing content after the page has rendered.
- Animate with transform and opacity rather than height, width or margin, because only those two properties avoid a new layout pass.
- Preload web fonts and match the fallback metrics so text does not reflow when the font arrives.
A realistic improvement plan
Start with a field-data baseline from Search Console for the three most important page templates. Fix the server response and the hero image first, because they usually account for more than half of the LCP problem. Then remove or defer third-party scripts, then work on JavaScript volume. Measure again after 28 days, since field data is a rolling window and will not update overnight.
For a typical corporate website this is two to five days of work, or 1,800 to 4,500 EUR. In our projects that effort moves mobile LCP from around 4 seconds to under 2 seconds and takes the passing rate for all three metrics from roughly 30 percent of page views to over 90 percent. Protect the result with a performance budget in the build pipeline, so the next marketing tag cannot silently undo six months of work.
