Core Web Vitals Explained: LCP, INP, and CLS for Beginners
Google's Core Web Vitals measure how fast, responsive and stable your pages feel. What LCP, INP and CLS mean, the thresholds for "good", how to check your scores, the difference between lab and field data, and the usual fixes.
Core Web Vitals are three measurements Google uses to judge how a page feels to real visitors: how fast the main content appears, how quickly the page responds when you interact, and whether things jump around while loading. They show up in Google Search Console, in PageSpeed Insights, and as one of the signals in Google's ranking.
The three metrics
| Metric | Measures | Good | Poor |
|---|---|---|---|
| LCP — Largest Contentful Paint | Loading: when the main content appears | ≤ 2.5 s | > 4 s |
| INP — Interaction to Next Paint | Responsiveness: how fast the page reacts to taps, clicks and typing | ≤ 200 ms | > 500 ms |
| CLS — Cumulative Layout Shift | Visual stability: how much things jump around | ≤ 0.1 | > 0.25 |
Between "good" and "poor" is "needs improvement". Google evaluates each at the 75th percentile of real visits — so 3 out of 4 visits need to be "good" for the page to pass.
INP replaced an older metric, FID (First Input Delay), in March 2024. Old articles that mention FID are out of date.
LCP: when does the main content show?
LCP is the time until the largest visible element — usually a hero image, a big heading or a product photo — has rendered.
Common causes of a slow LCP:
- a huge, unoptimised hero image (optimize images for the web),
- the hero image is lazy-loaded (never do that for the top image),
- a slow server response — the page HTML itself takes a long time (why is my website slow?),
- large CSS or JavaScript files that block rendering,
- web fonts delaying text.
Fixes: compress and resize the hero image, give it fetchpriority="high", speed up the server (caching, database indexes), serve static files from a CDN.
INP: does the page respond quickly?
INP measures the delay between a user's interaction (tap, click, key press) and the screen visibly updating. A poor INP feels like "I tapped the button and nothing happened".
The cause is almost always too much JavaScript running at once on the main thread — big re-renders, heavy calculations, or third-party scripts (chat widgets, analytics, ads) hogging the browser.
Fixes: remove scripts you don't need, load third-party widgets later, avoid re-rendering huge lists on every keystroke, and split up heavy work. Show immediate feedback (a pressed state, a spinner) even when the real work takes longer.
CLS: does the page jump around?
CLS adds up unexpected movement of content while you're looking at the page — the classic "I went to tap a link and an ad pushed it down".
Common causes and fixes:
- Images without dimensions → always set
widthandheightoraspect-ratio. - Ads, embeds, banners injected above content → reserve space for them.
- Web fonts swapping and changing text size → use
font-displayand fallback fonts with similar metrics. - Content inserted after load (a cookie banner pushing the page down) → overlay it instead.
How to check your scores
- PageSpeed Insights (pagespeed.web.dev): enter a URL. The top section shows field data from real Chrome users (if your site has enough traffic); the bottom shows a lab test.
- Google Search Console → Core Web Vitals report: which groups of pages pass or fail, from real visitors. (Get your website on Google covers setting it up.)
- Chrome DevTools → Lighthouse and Performance panels, for testing and debugging on your own machine. (Browser developer tools for beginners)
Lab vs field data
Lab data is one simulated visit under fixed conditions — great for debugging and comparing before/after. Field data is what real visitors actually experienced over the last 28 days — that's what Google uses. A perfect Lighthouse score doesn't guarantee good field data (real phones are slower than your laptop), and new sites often have no field data until they get enough visits.
How much do they matter for SEO?
Core Web Vitals are one ranking signal among many. Relevant, useful content matters far more; a fast page with nothing useful won't rank. But between similar pages, better experience helps — and the same improvements make more visitors stay, which is reason enough on its own. (SEO basics for your app.)
The summary
- LCP (≤2.5 s): the main content appears quickly.
- INP (≤200 ms): the page responds quickly to interactions.
- CLS (≤0.1): content doesn't jump around.
- Check with PageSpeed Insights and Search Console; Google uses real-visitor (field) data.
- Big wins: optimise the hero image, cut JavaScript, set image dimensions.
EasySpawn runs your app on a dedicated server with your database beside it, so the server response that LCP starts from isn't waiting on a cold start or a far-away database. See how it works or join the waitlist.
Related: Why Is My Website Slow? · HTTP Caching Headers · Optimize Images for the Web · What Is Latency?
Keep reading
React App Shows a Blank Page After Deploying? Here's How to Fix It
Works locally, white screen in production. The usual causes of a blank page after deploying a React or Vite app — wrong base path, missing environment variables, a JavaScript crash, routing, caching — and how to diagnose each in two minutes with DevTools.
Why Refreshing Your React Page Gives a 404 (and How to Fix It on Any Host)
Your single-page app works when you click around but shows 404 Not Found when you refresh or share a link. Why client-side routing causes it, and the exact fix for Nginx, Caddy, Netlify, Vercel, GitHub Pages and Express.