--- title: "Core Web Vitals Guide: LCP, INP and CLS Explained" description: "A practical guide to Core Web Vitals. What LCP, INP and CLS measure, the thresholds Google uses, and the specific fixes that move each metric — with no jargon." url: https://frontendhelpers.com/core-web-vitals-guide updated: 2026-10-12 --- # Core Web Vitals, practically explained What LCP, INP and CLS actually measure, the thresholds that matter, and the fixes that genuinely move each one. Guide · By [AurumCodeWorks](https://frontendhelpers.com/about) · 4 min read · Updated 19 July 2026 ## What Core Web Vitals are, and why they matter Core Web Vitals are three metrics Google uses to quantify user experience: how fast the main content appears, how quickly the page responds to interaction, and how much it moves around while loading. They're part of Google's ranking systems — a genuine tiebreaker between pages of similar relevance, though never a substitute for useful content. Crucially, Google grades you on **field data** from real Chrome users, not lab tests. A page that scores perfectly in Lighthouse on your fast laptop can still fail for visitors on mid-range phones. Check the Core Web Vitals report in Search Console for what real users experience. ## LCP — Largest Contentful Paint LCP measures when the largest visible element finishes rendering: usually your hero image, a heading, or a large text block. **Good is 2.5 seconds or under; poor is over 4 seconds.** The fixes, roughly in order of impact. Never lazy-load your LCP element — adding `loading="lazy"` to a hero image is a self-inflicted wound that delays the exact thing being measured. Serve images in modern formats (WebP or AVIF) at appropriate sizes. Preload the LCP image with `` so the browser starts fetching it immediately rather than after CSS parsing. Eliminate render-blocking resources in the head, and make sure your server responds quickly — a slow Time to First Byte puts a floor under everything else. ## INP — Interaction to Next Paint INP replaced First Input Delay in 2024, and it's stricter. Rather than measuring only the first interaction's delay, it measures the _full_ latency of interactions throughout the visit — from tap to the next frame painted. **Good is 200ms or under; poor is over 500ms.** Poor INP is almost always long JavaScript tasks blocking the main thread. Break up work over 50ms into smaller chunks, yielding with `await scheduler.yield()` or `setTimeout`. Debounce expensive handlers on input and scroll — the technique in our [JavaScript tricks](https://frontendhelpers.com/js-tips) collection. Audit third-party scripts ruthlessly, since analytics, chat widgets and ad scripts are frequently the real culprit. And make sure visual feedback happens in the same frame as the interaction, even if the underlying work continues. ## CLS — Cumulative Layout Shift CLS measures unexpected movement: content jumping as the page loads. It's the metric behind tapping the wrong button because an ad loaded above it. **Good is 0.1 or under; poor is over 0.25.** Four causes account for nearly all of it. **Images without dimensions** — always set `width` and `height`, which our [aspect ratio calculator](https://frontendhelpers.com/aspect-ratio-calculator) works out for you. **Ads and embeds** — reserve their space with a min-height container. **Web fonts** — use `font-display: swap` with a fallback whose metrics are close, or the swap itself causes reflow. **Content injected above existing content** — banners and notification bars pushing the page down after load. ## Measuring properly Use two sources together. **PageSpeed Insights** shows both lab data and, where available, real field data for the URL. **Search Console's Core Web Vitals report** groups your whole site by URL pattern, so you can see which templates are failing rather than chasing individual pages. Test on a throttled connection and a simulated mid-range device. Your own machine on office broadband is the least representative environment you could possibly measure from. ## Where to actually start Do the cheap structural fixes first, because they're where most of the gain sits: set image dimensions everywhere, remove `loading="lazy"` from anything above the fold, add `font-display: swap`, and reserve space for ads and embeds. That combination typically fixes CLS entirely and meaningfully helps LCP. Then attack JavaScript, which is where INP problems live and where the work is hardest. Audit what you actually ship — the most reliable performance fix remains deleting code you don't need. The [performance essentials](https://frontendhelpers.com/essentials#ess-perf) checklist covers the habits that keep these metrics healthy once you've fixed them. ## Frequently asked questions ### What are good Core Web Vitals scores? LCP of 2.5 seconds or less, INP of 200 milliseconds or less, and CLS of 0.1 or less. Google measures the 75th percentile of real user experiences, so most visitors must hit those numbers, not just the average. ### Do Core Web Vitals affect Google rankings? Yes, as part of Google’s page experience signals — but they act as a tiebreaker between pages of similar relevance rather than overriding content quality. Better content still beats a faster page with nothing to say. ### Why does my page score well in Lighthouse but fail in Search Console? Lighthouse is a lab test on your machine and connection. Search Console reports field data from real Chrome users on real devices and networks, which is what Google actually uses for ranking. ## Keep going - [Aspect Ratio Calculator](https://frontendhelpers.com/aspect-ratio-calculator): Get image dimensions right and stop layout shift. - [CSS animation performance](https://frontendhelpers.com/css-animation-performance): Which properties are cheap to animate, and which cause jank. - [Dev Essentials](https://frontendhelpers.com/essentials): Performance, security and accessibility checklists.