Core Web Vitals: the complete guide to LCP, INP and CLS
What Core Web Vitals are, how Google measures them, where to find your numbers and how to fix each of the three, step by step.
Key takeaways
- They are three measurements of real visitor experience: loading (LCP), responsiveness (INP) and visual stability (CLS).
- Google looks at real-user data from the last 28 days, and a page passes when 75% of visits fall in the "good" range.
- Most problems come from oversized images, third-party scripts and elements with no reserved space.
In this guide
Core Web Vitals are three numbers Google uses to judge whether a page is pleasant to use. They are part of the page experience assessment, which counts as one of the ranking signals in search.
More important than Google, though, is the visitor: each of these numbers maps to a real frustration. A page that takes too long to show up, a button that does not respond, text that jumps just as you tap it. Improving all three makes life better for everyone who visits your site.
The three numbers in one table
| Metric | Good | Poor |
|---|---|---|
| LCP: when does the main content appear? | up to 2.5 s | over 4 s |
| INP: when I tap, does the page react quickly? | up to 200 ms | over 500 ms |
| CLS: do elements keep moving around? | up to 0.1 | over 0.25 |
Between "good" and "poor" sits the needs improvement range.
How Google measures (and why your test may differ)
There are two kinds of measurement, and understanding the difference saves a lot of confusion:
- Lab data: a simulated test run on a defined device and connection. This is what you see when you test a page. It is useful for finding problems and checking whether a fix worked.
- Field data: measurements from real Chrome users, collected in the Chrome User Experience Report. This is what Google uses to evaluate your site.
For field data, Google looks at the last 28 days and considers a page passing when 75% of visits fall in the "good" range. That means:
- A fix takes a few weeks to show up in Google's report.
- Low-traffic sites may have no field data at all. In that case, rely on the lab test.
- INP only exists with real interaction, so lab tests use TBT (Total Blocking Time) as a proxy.
Where to see your numbers
- Teste de Performance: shows LCP, CLS and the other lab metrics, with tips on what to fix.
- Google Search Console, in the "Core Web Vitals" report: field data, grouping pages that share the same problem.
- PageSpeed Insights: shows field and lab data side by side for a single page.
Check mobile first. Google evaluates your site based on its mobile version, and that is where the numbers are usually worse.
How to improve LCP (loading)
LCP marks the moment the largest visible element on the screen appears, usually the hero image or the main heading. It depends on four steps: the server responding, the browser discovering the image, downloading it and painting it.
1. Make the main image light
- Use WebP or AVIF and the right size for the screen (a 4,000 px photo does not need to go to a phone).
- Serve different versions for mobile and desktop with
srcset.
2. Make the browser fetch that image early
- Do not lazy-load (
loading="lazy") the hero image. Lazy loading is great for the rest of the page but delays exactly the most important image. - Mark the main image with
fetchpriority="high". - Avoid hero sections that depend on JavaScript to appear, such as script-built carousels.
3. Speed up the server
- Turn on page caching and use a CDN.
- If server response time (TTFB) is above 0.8 s, hosting may be the bottleneck.
4. Remove what blocks rendering
- CSS and fonts that hold up loading: load only what the top of the page needs and use
font-display: swapon fonts.
How to improve INP (responsiveness)
INP measures the delay between an interaction (tap, click, key press) and the next screen update. When the browser is busy running JavaScript, it cannot respond, and the visitor feels the site freeze.
1. Cut third-party scripts Chat widgets, pop-ups, heatmaps, ad pixels and embeds all compete for the same processor. Make a list and remove anything that does not bring results.
2. Defer what is not urgent
Scripts that are not needed right away can load later, with defer, or only when the visitor gets close to that part of the page.
3. Break up long tasks For developers: JavaScript tasks over 50 ms block the page. Split the work into smaller chunks and give the browser a chance to respond in between.
4. Watch out for huge pages Pages with thousands of elements make every update slower. Very long lists can be paginated or loaded progressively.
How to improve CLS (visual stability)
CLS measures how much content shifts without the visitor asking for it. It is the button that moves down just as you tap because something appeared above it.
1. Set width and height on images and videos
With width and height in the HTML (or aspect-ratio in CSS), the browser reserves the space before the image arrives.
2. Reserve space for ads, banners and embeds Give the area where they will appear a minimum height.
3. Do not insert content above what is already on screen Cookie notices, promo bars and messages should overlay the page, stick to the bottom or reserve space from the start.
4. Take care with fonts Swapping the fallback font for the final one can change text size. Using fonts with similar metrics and preloading the main font reduces the jump.
A 5-step action plan
- Measure your most important page (usually the homepage or your best-selling page) on mobile.
- Pick the worst of the three numbers and start there.
- Fix one thing at a time and test again, so you know what worked.
- Repeat on other key pages; problems tend to repeat across the whole site because pages share the same theme.
- Track Search Console over the following weeks to watch the field data improve.
Do not chase a perfect 100. What matters to Google is being in the "good" range for real users. After that, useful and relevant content weighs far more than a few extra points in a test.