Core Web Vitals Explained: LCP, INP and CLS (and How to Improve Them)
What Google's Core Web Vitals measure, the thresholds that count as "good," how to find problems, and the fixes that move each metric.
Core Web Vitals are three metrics Google uses to measure real-world user experience on a page: how fast the main content loads, how quickly the page responds to interaction, and how stable the layout is while it loads. They are part of Google’s page experience signals, and they are one of the clearest, most measurable parts of technical SEO.
Good scores will not rescue weak content, but poor scores create friction for visitors and can hold back pages competing with similarly relevant results.
The three Core Web Vitals
| Metric | What it measures | Good | Needs improvement | Poor |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Loading: when the largest visible element finishes rendering | ≤ 2.5 s | 2.5–4.0 s | > 4.0 s |
| INP (Interaction to Next Paint) | Responsiveness: delay between a user interaction and the next visual update | ≤ 200 ms | 200–500 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | Visual stability: how much content unexpectedly moves | ≤ 0.1 | 0.1–0.25 | > 0.25 |
Google assesses each metric at the 75th percentile of real page loads, separately for mobile and desktop. That means at least three out of four visits need to hit the “good” threshold for the page to pass.
INP replaced First Input Delay (FID) as a Core Web Vital in March 2024. If an older guide still talks about FID, it is out of date.
Field data vs lab data
Before fixing anything, understand the two kinds of data you will see:
- Field data comes from real Chrome users through the Chrome User Experience Report (CrUX). This is what Google uses for page experience. You will find it in Search Console’s Core Web Vitals report and at the top of PageSpeed Insights.
- Lab data comes from a simulated test, for example Lighthouse in Chrome DevTools. It is reproducible and great for debugging, but it is not what Google uses to assess your pages.
Use field data to decide *what* to fix, and lab tools to work out *why*.
How to improve LCP
The LCP element is usually a hero image, a large heading or a featured image. Improving LCP is about getting that element on screen sooner.
- Reduce server response time (TTFB). Use good hosting, page caching and a CDN so the HTML arrives quickly.
- Make the LCP image discoverable early. Do not lazy-load the hero image. Add
fetchpriority="high"to it, and avoid loading it through CSS backgrounds or JavaScript. - Compress and resize images. Serve modern formats such as WebP or AVIF, at the size they are actually displayed, with responsive
srcset. - Remove render-blocking resources. Inline critical CSS, defer non-essential JavaScript and limit third-party scripts in the
<head>. - Preload key fonts and use
font-display: swapso text paints immediately.
How to improve INP
INP measures how long the browser takes to respond visually after a click, tap or key press. Slow INP is almost always caused by too much JavaScript running on the main thread.
- Ship less JavaScript. Audit plugins, tag managers and widgets. Every script you remove is work the browser no longer has to do.
- Break up long tasks. Split work over 50 ms into smaller chunks and yield to the main thread so the browser can respond to input.
- Defer non-critical work. Load chat widgets, analytics extras and below-the-fold features after the page is interactive.
- Keep event handlers light. Do the minimum needed to update the screen, then do heavier work afterwards.
- Avoid huge DOM sizes. Very large pages make every style and layout update slower.
How to improve CLS
Layout shifts happen when something loads late and pushes content around. They are frustrating, especially when a reader is about to tap a link.
- Always set dimensions for images and videos. Use
widthandheightattributes or CSSaspect-ratioso space is reserved. - Reserve space for ads, embeds and banners. Give dynamic slots a fixed minimum height.
- Do not insert content above existing content, such as cookie bars or promos that push the page down. Use overlays instead.
- Load web fonts carefully. Preload them and choose fallbacks with similar metrics to minimise text reflow.
- Animate with
transformrather than properties that trigger layout, such astoporheight.
A simple workflow for fixing Core Web Vitals
- Open Search Console → Core Web Vitals and note which URL groups fail, and on which device.
- Test a representative URL from each group in PageSpeed Insights to see the field data and the main opportunities.
- Reproduce the issue in Chrome DevTools (Performance panel and Lighthouse) and identify the LCP element, long tasks or shifting elements.
- Fix the root cause in your template rather than page by page, so every similar page benefits.
- Deploy, then click Validate fix in Search Console. Field data uses a rolling 28-day window, so improvements take a few weeks to show.
Common mistakes
- Optimising only for a Lighthouse score. A 100 in the lab does not guarantee good field data on real phones and networks.
- Lazy-loading everything. Lazy-loading the LCP image delays it and makes LCP worse.
- Installing another plugin to fix plugin bloat. Removing scripts is usually more effective than adding optimisation layers.
- Testing only on fast desktop hardware. Most failing sites fail on mid-range mobile devices.
Key takeaways
Core Web Vitals turn user experience into three measurable numbers: LCP for loading, INP for responsiveness and CLS for visual stability. Aim for good scores on at least 75% of real visits, fix problems at the template level, and treat performance as an ongoing habit rather than a one-off project. For the bigger picture of how speed fits into ranking, start with our beginner’s guide to SEO.
