Core Web Vitals Explained: What LCP, INP and CLS Mean and How to Fix Each One
Core Web Vitals are three Google metrics that measure real users' experience of a page: Largest Contentful Paint (LCP) for loading, Interaction to Next Paint (INP) for responsiveness, and Cumulative Layout Shift (CLS) for visual stability. A page passes when, at the 75th percentile of real visits, LCP is 2.5 seconds or less, INP is 200 milliseconds or less, and CLS is 0.1 or less. You fix them by making the main content load early, keeping JavaScript off the main thread during interactions, and reserving space for everything that loads late.
This guide explains each metric in plain language, how to measure it correctly, and the fixes that move the needle most.
Key takeaways
- Thresholds: LCP ≤ 2.5 s, INP ≤ 200 ms, CLS ≤ 0.1, at the 75th percentile, for mobile and desktop separately.
- Field data (real Chrome users) decides whether you pass; lab tests are for debugging.
- LCP: make the main image discoverable and high priority, never lazy-load it, and cut server response time.
- INP: break up long JavaScript tasks and remove unnecessary scripts, especially third-party ones.
- CLS: set width and height (or aspect-ratio) on images, embeds and ads; keep pages eligible for the back/forward cache.
- Google says good Core Web Vitals align with what its core ranking systems reward, but content relevance still comes first.
The three metrics at a glance
| Metric | Measures | Good | What users feel when it's bad |
|---|---|---|---|
| LCP (Largest Contentful Paint) | When the largest image or text block in view finishes rendering | ≤ 2.5 s | "This page is slow to load" |
| INP (Interaction to Next Paint) | How quickly the page visually responds to taps, clicks and key presses | ≤ 200 ms | "I tapped and nothing happened" |
| CLS (Cumulative Layout Shift) | How much visible content moves unexpectedly | ≤ 0.1 | "I clicked the wrong thing because the page jumped" |
According to web.dev, a page should be considered passing if it meets the recommended targets at the 75th percentile for all three metrics, segmented by mobile and desktop.
INP became a stable Core Web Vital in 2024, replacing First Input Delay (FID). Google's web.dev documentation says stable metrics won't change more than once per year and changes are announced in advance.
Why Core Web Vitals matter
- Search: Google's Search Central documentation says it highly recommends achieving good Core Web Vitals for success with Search, and that along with other page experience aspects they align with what its core ranking systems seek to reward. Google lists good page experience among the SEO fundamentals that continue to matter for its AI features too.
- Conversions: slow, jumpy, unresponsive pages lose visitors before they act. For stores, see the ecommerce conversion rate optimization checklist.
Keep perspective: a fast page with unhelpful content won't outrank a slower page that answers the query far better. Fix vitals as part of quality, not instead of it.
How to measure Core Web Vitals correctly
Field data vs lab data
| Field data | Lab data | |
|---|---|---|
| Source | Real Chrome users (Chrome UX Report) or your own real-user monitoring | A simulated load on one device and network |
| Used for | Deciding whether pages pass | Debugging and testing changes before release |
| Measures INP? | Yes | No. Lighthouse uses Total Blocking Time (TBT) as a proxy |
| Tools | Search Console Core Web Vitals report, PageSpeed Insights field section, CrUX | Lighthouse, Chrome DevTools, PageSpeed Insights lab section |
A measurement routine
- Start in Search Console's Core Web Vitals report. It groups similar URLs and shows which templates fail on mobile and desktop.
- Open a failing URL in PageSpeed Insights. Read the field data first, then use the lab diagnostics to see what's slow.
- Reproduce in Chrome DevTools' Performance panel to see the LCP element, long tasks and layout shifts.
- Add real-user monitoring if you can. web.dev recommends the open-source
web-vitalsJavaScript library, which measures each metric the way Google's tools report it, so you can send data to your analytics. - Re-check field data after changes. CrUX data is based on a rolling window, so improvements take time to show.
How to fix LCP (loading)
LCP is usually a hero image, a main product image or a large heading. Find which element it is first (PageSpeed Insights and DevTools both show it).
web.dev's top recommendations:
- Make the LCP resource discoverable in the HTML. If the image is injected by JavaScript or set as a CSS background, the browser finds it late. Use a normal
<img>in the server-rendered HTML, or preload it. - Prioritize it. Add
fetchpriority="high"to the LCP<img>(or its preload link), and removeloading="lazy"from it. Lazy-loading the main image is one of the most common LCP mistakes. - Defer non-critical resources so they don't compete with the LCP image: move scripts later, load them async, and lazy-load below-the-fold images and iframes.
- Reduce Time to First Byte (TTFB) with a CDN and caching. web.dev suggests caching HTML even for a short time where content can be a few minutes stale.
- Use instant navigations where possible: back/forward cache restoration and prerendering can make repeat navigations near-instant.
Other common LCP wins:
- Serve correctly sized, compressed images in modern formats
- Inline critical CSS and avoid render-blocking stylesheets for below-the-fold content
- Reduce web font delays (preload key fonts, limit families and weights)
How to fix INP (responsiveness)
INP fails when the browser's main thread is busy running JavaScript at the moment a user interacts.
- Break up long tasks. web.dev recommends yielding to the main thread often so rendering and other interactions can happen sooner. The
scheduler.yield()API breaks up long tasks while keeping your work's place in the queue. - Avoid unnecessary JavaScript. Use DevTools' Coverage tool to find unused code, split bundles so code not needed for the first render loads later, and prefer built-in browser features over JavaScript re-implementations.
- Avoid large rendering updates. Huge DOM changes after a click (re-rendering a whole product grid, for example) delay the next paint. Update only what changed, and use CSS containment for complex off-screen areas.
- Audit third-party scripts. Chat widgets, A/B testing tools, tag managers, review widgets and trackers often run heavy code on every interaction.
- Give instant feedback. Show a pressed state or spinner immediately, then do the heavy work.
On Shopify and similar platforms, INP problems often come from app scripts that remain installed after the app is no longer used. Removing them is a quick win.
How to fix CLS (visual stability)
- Set explicit sizes on images using
widthandheightattributes or CSS. web.dev reports that 66% of pages have at least one unsized image. - Reserve space for embeds and ads using the CSS
aspect-ratioproperty or fixed-size containers. - Keep pages eligible for the back/forward cache (bfcache). web.dev says bfcache can eliminate layout shifts on back and forward navigations entirely; common blockers are
no-storecache headers andunloadevent listeners. Chrome DevTools includes a bfcache tester. - Avoid animating layout properties such as
top,left,widthandheight; animatetransforminstead. - Don't insert content above existing content (cookie bars, promo banners, late-loading notices) unless space is reserved or it overlays the page.
- Handle web fonts carefully so text doesn't reflow badly when fonts swap in.
Fix priority by platform
| Platform | Usual LCP culprit | Usual INP culprit | Usual CLS culprit |
|---|---|---|---|
| Shopify | Large or lazy-loaded hero and product images | App scripts, review and upsell widgets | Announcement bars, unsized app blocks |
| WordPress | Slow hosting (TTFB), page builders | Plugins and page-builder scripts | Ads, embeds, late-loading fonts |
| Next.js / React | Client-rendered hero content | Large hydration and re-renders | Client-only components popping in |
| Webflow | Oversized images and background videos | Interactions and third-party embeds | Embeds without reserved space |
From experience: On Next.js builds deployed to Vercel, the biggest LCP gains usually come from rendering the hero on the server and marking the main image as priority, not from shaving kilobytes. On Shopify Plus stores, INP is more often an app problem than a theme problem: list every script on the product page and ask what each one earns.
Protect your gains
- Add performance checks to your release process (Lighthouse CI or similar) to catch regressions before launch.
- Review new apps, plugins and tags for performance cost before installing.
- Re-check the Core Web Vitals report monthly and after redesigns or migrations. If you're changing platforms, include vitals in your website migration SEO checklist.
Core Web Vitals checklist
- [ ] Search Console Core Web Vitals report reviewed for mobile and desktop
- [ ] Failing templates identified (home, category, product, article)
- [ ] LCP element identified for each template
- [ ] LCP image in server-rendered HTML, not lazy-loaded, with fetchpriority="high"
- [ ] CDN and HTML caching in place to reduce TTFB
- [ ] Non-critical scripts deferred; unused apps and plugins removed
- [ ] Long tasks broken up; heavy third-party scripts audited
- [ ] Images, embeds and ads have explicit dimensions or aspect-ratio
- [ ] Pages eligible for bfcache (no unnecessary no-store or unload handlers)
- [ ] Real-user monitoring with the web-vitals library (optional but recommended)
- [ ] Performance checks added to the release process
Next steps
- Open Search Console's Core Web Vitals report and list failing URL groups by template.
- Fix the LCP image priority and lazy-loading on your most important template this week.
- Inventory third-party scripts and remove anything unused.
- Re-measure field data after four weeks.
- For help with performance and technical SEO on a Shopify, Next.js or Webflow site, see AI SEO consulting or read how to rank in Google AI Overviews.
Sources
- web.dev, Web Vitals: https://web.dev/articles/vitals
- web.dev, The most effective ways to improve Core Web Vitals: https://web.dev/articles/top-cwv
- Google Search Central, Understanding Core Web Vitals and Google search results: https://developers.google.com/search/docs/appearance/core-web-vitals
- Google Search Central, AI features and your website: https://developers.google.com/search/docs/appearance/ai-features
Frequently asked questions
What are the three Core Web Vitals?
Largest Contentful Paint (LCP) measures loading, Interaction to Next Paint (INP) measures responsiveness, and Cumulative Layout Shift (CLS) measures visual stability. Google's recommended good thresholds are LCP within 2.5 seconds, INP of 200 milliseconds or less, and CLS of 0.1 or less, measured at the 75th percentile of real page loads on mobile and desktop.
Do Core Web Vitals affect Google rankings?
Google says it highly recommends good Core Web Vitals for success with Search and that, along with other page experience aspects, they align with what its core ranking systems seek to reward. They are not a trump card: relevant, helpful content still matters most. Treat good vitals as a baseline that helps both rankings and conversions.
Why does PageSpeed Insights show different scores from Search Console?
They often show different data types. Search Console's Core Web Vitals report and the field section of PageSpeed Insights use real-user Chrome data, while the Lighthouse score in PageSpeed Insights is a lab test from one simulated load. Lab tests can't measure INP because there's no real user interaction. Prioritize field data when judging whether you pass.
What replaced First Input Delay?
Interaction to Next Paint (INP) replaced First Input Delay (FID) as the responsiveness Core Web Vital in 2024. INP is stricter because it considers the latency of interactions throughout a page visit, not just the first one. Pages heavy with JavaScript, such as large single-page apps or stores with many apps, are most likely to struggle with INP.
What's the fastest way to improve LCP?
Make sure the LCP element, often the hero or main product image, is discoverable in the HTML, not lazy-loaded, and given high priority with fetchpriority set to high. Then reduce server response time with caching and a CDN, and remove render-blocking resources that delay the image. These changes usually matter more than micro-optimizing file sizes.