Core Web Vitals: LCP, CLS, INP Explained | SlapMyWeb
Technical Seo10 min read
Core Web Vitals: LCP, CLS, INP Explained
Core Web Vitals explained: what LCP, CLS, and INP measure, Google's thresholds, and the exact code fixes to hit "good" on every metric.
SlapMyWeb Team·
Core Web Vitals are three Google metrics — Largest Contentful Paint (LCP), Cumulative Layout Shift (CLS), and Interaction to Next Paint (INP) — that measure how fast a page shows its main content, how visually stable it stays while loading, and how quickly it responds to a tap or click. Google considers a page "good" when LCP is under 2.5 seconds, CLS is under 0.1, and INP is under 200 milliseconds, measured at the 75th percentile of real visitors. Hit those thresholds and you improve both the experience for real users and your standing as part of Google's page experience signals.
This guide explains each metric in plain language, shows you exactly what drags it down, and gives you concrete fixes — including the code — for LCP, CLS, and INP.
What Are Core Web Vitals?
Core Web Vitals are the subset of Google's web performance metrics that focus on three things people actually feel: loading, visual stability, and responsiveness. Google chose these three because they map to the most common frustrations on the web — staring at a blank screen, having a button jump away just as you tap it, and tapping something that doesn't react.
Each metric is reported as a single number at the 75th percentile of your real-user data. That percentile detail matters: it means three out of four visitors must have a good experience before the metric counts as "good." A blazing-fast test on your own laptop proves nothing if a quarter of your audience is on a mid-range phone over patchy mobile data.
There are two ways the numbers are gathered:
Field data (real users): collected from actual Chrome visitors via the Chrome User Experience Report (CrUX). This is what Google uses for ranking and what shows up in Search Console.
Lab data (synthetic): a single controlled test in a tool like Lighthouse or PageSpeed Insights. Great for debugging because it's repeatable, but it's one device on one network — not your real audience.
INP officially replaced First Input Delay (FID) as a Core Web Vital in March 2024, so if you read older guides that still talk about FID, they're out of date. Google documents the current set and thresholds in its Core Web Vitals reference on web.dev.
SEO specialist reviewing a Core Web Vitals report on a desktop monitor in an office
Understanding LCP (Largest Contentful Paint)
Largest Contentful Paint measures the moment the largest visible element in the viewport finishes rendering — usually a hero image, a video poster frame, a background image, or a big block of headline text. It's the closest single metric to the gut feeling of "the page has loaded." A good LCP is under 2.5 seconds; between 2.5 and 4 seconds needs work, and over 4 seconds is poor.
LCP is rarely caused by one thing. It's the sum of four phases: time to first byte from your server, resource load delay, resource load time, and render delay. Slow anywhere along that chain and your LCP suffers.
Why LCP Matters
It's the strongest perception of speed — users decide whether to stay in the first couple of seconds.
Slow LCP correlates tightly with abandonment, especially on mobile.
It's a confirmed input to Google's page experience signals.
How to Improve LCP
The biggest LCP wins almost always come from the LCP element itself — most often a large image. Work through these in order:
Optimize and right-size the LCP image. Serve modern formats (WebP or AVIF), compress aggressively, and never ship a 2000px image into a 600px slot. Our image optimization guide walks through compression and conversion step by step.
Preload the LCP resource so the browser fetches it early instead of discovering it late in the HTML.
Do NOT lazy-load the LCP image. Lazy loading is for below-the-fold media — applying it to your hero delays the very thing LCP is timing.
Cut server response time (TTFB) with caching and a CDN so the document and its critical resources arrive sooner.
Eliminate render-blocking CSS and JavaScript so the browser can paint without waiting on bloated stylesheets and scripts.
html
<!-- Preload the hero image and tell the browser it's high priority -->
<link rel="preload" as="image"
href="/hero.avif"
fetchpriority="high">
<!-- Hero image: explicit dimensions, eager load, high priority -->
<img src="/hero.avif"
width="1200" height="600"
fetchpriority="high"
alt="Product dashboard overview">
Cumulative Layout Shift measures how much visible content unexpectedly moves around while the page loads. Every time an image pops in without reserved space, a web font swaps and reflows the text, or an ad banner pushes the article down, the layout "shifts" — and CLS adds up the impact of those movements. A good CLS score is under 0.1. It's a unitless number, scored by how much of the screen moved and how far.
The classic CLS failure: you go to tap a link, an image finishes loading above it, everything jumps down, and you tap an ad instead. That's not just annoying — it's a real usability and trust problem.
Why CLS Matters
It prevents the maddening "page jumps as I'm about to tap" experience.
It cuts accidental clicks, which protects both UX and ad revenue quality.
Stable layouts read as polished and trustworthy; janky ones read as broken.
How to Improve CLS
Almost every CLS problem comes down to one rule: reserve space for anything that loads in later.
Always set `width` and `height` (or `aspect-ratio`) on images and video. This lets the browser hold the exact space before the media arrives.
Reserve space for ads, embeds, and iframes with a min-height container so they can't shove content when they load.
Never inject content above existing content after load — banners, cookie bars, and notices should overlay or push from a reserved slot.
Preload fonts and use `font-display: optional` or `swap` carefully to minimize the reflow when web fonts replace fallback text.
css
/* Reserve aspect ratio so the image slot never collapses */
img {
aspect-ratio: 16 / 9;
width: 100%;
height: auto;
}
/* Hold space for a lazy-loaded ad unit */
.ad-slot {
min-height: 250px;
}
CLS is one of the most fixable vitals once you spot the offenders. Our step-by-step guide to fixing CLS shows how to trace each shift back to the element that caused it, and lazy loading done correctly explains how to defer media without triggering shifts.
Two web developers debugging layout shift on a laptop with browser dev tools open
Understanding INP (Interaction to Next Paint)
Interaction to Next Paint measures how quickly your page visually responds after a user interacts with it — a click, a tap, or a key press. Specifically, it captures the delay from the interaction until the next frame the browser paints, and reports the worst (roughly) interaction across the whole visit. A good INP is under 200 milliseconds; 200–500ms needs work, and over 500ms feels broken.
INP is the responsiveness metric. While LCP and CLS are mostly about how the page loads, INP is about how the page feels to use once it's there. The usual culprit is JavaScript: a heavy main-thread task — analytics, a hydration burst, an expensive event handler — blocks the browser from responding for hundreds of milliseconds.
Why INP Matters
It captures the "I tapped and nothing happened" frustration that load metrics miss.
High INP usually points to JavaScript bloat — a fixable engineering problem.
Interactive sites (apps, forms, e-commerce checkouts) live or die on responsiveness.
How to Improve INP
Break up long tasks. Any main-thread task over ~50ms is a "long task" that can block interaction. Split heavy work and yield back to the browser.
Defer or remove non-critical JavaScript, especially third-party scripts that hydrate or run on every interaction.
Keep event handlers lean. Do the minimal visual update first, then schedule heavy work for after the next paint.
Use `requestIdleCallback` or `setTimeout`/`yield` to defer expensive work out of the interaction's critical path.
js
// Yield back to the browser so the click can paint immediately,
// then run the expensive work afterward.
button.addEventListener('click', async () => {
showSpinner(); // cheap, instant feedback
await scheduler.yield?.(); // let the browser paint
await processHeavyTask(); // expensive work, off the critical path
});
For the full diagnostic playbook — finding the slow interaction, profiling the long task, and rebuilding the handler — read our dedicated INP optimization guide.
Why Core Web Vitals Matter for SEO
Core Web Vitals are a confirmed part of Google's page experience signals. They are not the heaviest ranking factor — relevance, content quality, and links carry far more weight — but they act as a tiebreaker and a quality floor. When two pages are otherwise comparable, the faster, more stable, more responsive one tends to win. And consistently poor vitals can quietly cap how high an otherwise strong page ranks. Google describes this relationship in its page experience documentation.
Beyond rankings, the business case is simpler: pages that load fast, don't jump, and respond instantly convert better and bounce less. You're not optimizing for a metric — you're optimizing for the visitor, and the metric just happens to measure that.
Run a free SlapMyWeb audit to see exactly where your LCP, CLS, and INP stand and get a prioritized list of the fixes that move each one.
If you sell online, layout shift and slow interactions hit revenue directly — our Core Web Vitals for e-commerce guide covers product pages, carts, and checkout specifically. And to understand how these field metrics relate to the lab score everyone quotes, see what a Google PageSpeed score actually means.
Person using a smartphone with an e-commerce product page open on the screen
Aim for LCP under 2.5 seconds, CLS under 0.1, and INP under 200 milliseconds. Google considers these the thresholds for a "good" experience, and the score is measured at the 75th percentile of your real visitors — so three out of four people must hit the target, not just a lab test on fast hardware.
Do Core Web Vitals affect SEO rankings?
Yes. Core Web Vitals are a confirmed Google ranking signal as part of page experience. They are not the biggest factor — relevance and content quality matter more — but when two pages are otherwise close, the faster, more stable one tends to win, and consistently poor vitals can hold a good page back.
What replaced FID in Core Web Vitals?
Interaction to Next Paint (INP) replaced First Input Delay (FID) in March 2024. FID only measured the delay before the browser started processing the first interaction; INP measures the full response time across interactions throughout the visit, making it a far better picture of real responsiveness.
How do I measure my Core Web Vitals?
Use Google Search Console's Core Web Vitals report for real-user (field) data across your whole site, or run a single page through a tool like SlapMyWeb or PageSpeed Insights. Lab tools tell you exactly what to fix; field data tells you what real visitors actually experience — you need both.
Why are my Core Web Vitals good in Lighthouse but poor in Search Console?
Lighthouse runs a single lab test on one simulated device, while Search Console reports field data from real Chrome users on every device and network. If your audience skews toward older phones or slower connections, their real experience can be far worse than your clean lab run — always trust the field data for ranking decisions.
