Core Web Vitals explained
What LCP, INP and CLS measure, the thresholds you need to hit, and exactly what to change to fix each one.
Core Web Vitals are three measurements Google uses to score real user experience. LCP measures how quickly the main content appears and should be under 2.5 seconds. INP measures how quickly the page responds to interaction and should be under 200 milliseconds. CLS measures unexpected layout movement and should be under 0.1.
What they are and why they exist
Core Web Vitals replaced a long list of vague performance metrics with three that correlate with how a page actually feels to use. They are measured on real visitors, not in a laboratory, which is why your field data can differ sharply from a synthetic test score.
They are a ranking signal, but the stronger argument is commercial: pages that fail these thresholds lose visitors before the content loads.
LCP — Largest Contentful Paint
How long until the largest visible element — usually the hero image or headline — finishes rendering. Target: under 2.5 seconds.
Common causes of a poor LCP:
- Slow server response, which delays everything downstream.
- A large, uncompressed hero image.
- Render-blocking CSS or JavaScript in the head.
- Client-side rendering that leaves the page blank until JavaScript executes.
- Web fonts blocking text rendering.
Fixes: preload the hero image, serve it as WebP at the correct dimensions, inline critical CSS, defer non-essential JavaScript, and improve server response time with caching.
INP — Interaction to Next Paint
How quickly the page responds visually after a tap, click or key press. It replaced First Input Delay and is considerably harder to pass, because it measures every interaction rather than only the first. Target: under 200 milliseconds.
Common causes: heavy JavaScript occupying the main thread, oversized third-party scripts, inefficient event handlers, and expensive work triggered on every interaction.
Fixes: break long tasks into smaller chunks, remove or defer third-party scripts, avoid layout work inside event handlers, and audit anything running on scroll or input.
CLS — Cumulative Layout Shift
How much content jumps around unexpectedly while the page loads. Target: under 0.1.
Common causes: images and iframes without width and height attributes, ads and embeds injected into the flow, web fonts swapping and changing text dimensions, and content inserted above what the visitor is already reading.
Fixes: always set explicit dimensions on images and embeds, reserve space for anything injected dynamically, use font-display: swap with a well-matched fallback, and never insert content above existing content after load.
How to measure properly
| Tool | Data type | Use it for |
|---|---|---|
| Search Console — Core Web Vitals report | Field (real users) | The scores that actually count |
| PageSpeed Insights | Both | Field data plus specific recommendations |
| Lighthouse | Lab | Debugging while developing |
| Chrome DevTools Performance | Lab | Finding what blocks the main thread |
Always trust field data over lab scores. A perfect Lighthouse result on a fast desktop connection means little if your visitors are on mobile networks.
Frequently asked questions
They are a confirmed ranking signal, but a modest one compared with relevance and authority. Treat them as a tie-breaker and, more importantly, as a conversion factor.
Lighthouse is a simulated test on one device. Search Console reports real visitors on real devices and networks over 28 days. The field data is the one that counts.
The report uses a rolling 28-day window, so expect several weeks before changes are fully reflected.
It can fix the server-response component of LCP. It cannot fix oversized images, heavy JavaScript or layout shift.