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 <link rel="preload"> 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 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 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 checklist covers the habits that keep these metrics healthy once you've fixed them.