Website audit
Core Web Vitals Explained: What Your Speed Score Means (and How to Fix It)
July 21, 20266 min readUpdated August 17, 2026
Google scores every page on three measurements it calls Core Web Vitals. They sound technical, but each one maps to a feeling a visitor has: how long until something appears, how quickly the page responds to a click, and whether the layout jumps around. Here's what each one means, what good looks like, and the fastest ways to fix a failing score.
The three vitals, decoded
- LCP — Largest Contentful Paint: the time until the largest visible element (usually a hero image or heading) renders. Under 2.5 seconds is good. It's the 'is anything happening?' moment.
- INP — Interaction to Next Paint: how quickly the page responds to clicks, taps, and key presses. Under 200 ms is good. It's the 'is this thing alive?' moment.
- CLS — Cumulative Layout Shift: how much visible content jumps around during load. Under 0.1 is good. It's the 'why did everything move?' moment — the button that dodges your cursor right as you click it.
What actually drags your score down
Slow servers and huge images are the classic LCP killers — a hero photo shipped at 5 MB with a slow origin response will fail LCP no matter what else you do. INP usually fails because of heavy JavaScript on the main thread: analytics, chat widgets, and animation libraries all queue up behind each other. CLS fails when images and embeds load without reserved space, or when fonts swap in after text has already rendered.
The fastest fixes, in order of impact
- Compress and resize images: convert to WebP/AVIF, cap dimensions, and let the server handle the heavy lifting.
- Preload the LCP element: an explicit preload for your hero image can shave a second off LCP.
- Reserve space for media: width/height attributes or aspect-ratio CSS stop layout shift cold.
- Cut third-party scripts: each tracker adds work — keep the ones that pay for themselves.
- Use font-display: swap: text renders instantly in a fallback font instead of waiting.
- Lazy-load below-the-fold content: offscreen images and iframes load only when scrolled to.
- Cache aggressively: a CDN with long cache lifetimes turns repeat visits into near-instant loads.
Measure, fix, measure again
Field data (real users) and lab data (synthetic tests) tell different stories — a fast test in a datacenter doesn't mean fast on a 4G phone. Use both: real-user monitoring for the trend, and a lab test to isolate which element is the LCP bottleneck. After a change, give field data a week or two to catch up; scores move slowly because they average real visits.
Core Web Vitals are a floor, not a ceiling. Passing them won't rank you, but failing them quietly caps everything else you do. A quick free audit will tell you in seconds whether your speed, along with the rest of your site health, is on the right side of the line.
Frequently asked questions
What are Core Web Vitals?+
Three measurements Google uses to score page experience: LCP (how fast the main content appears), INP (how quickly the page responds to clicks), and CLS (how much the layout jumps around). Good targets are under 2.5s, under 200ms, and under 0.1.
What is a good Core Web Vitals score?+
LCP under 2.5 seconds, INP under 200 milliseconds, and CLS under 0.1 are considered good on mobile. Field data from real users tells the true story better than a single lab test.
How do I fix poor Core Web Vitals?+
Compress and resize images, preload the LCP element, reserve space for media so nothing shifts, cut heavy third-party scripts, and cache aggressively. Measure, fix, then re-measure — field data takes a week or two to catch up.
How do I check my Core Web Vitals?+
Use both field and lab data: real-user monitoring (like CrUX) for the trend, and a lab test to isolate which element is the LCP bottleneck. A fast datacenter test doesn't mean fast on a 4G phone — and give field data a week or two to catch up after a change, since it averages real visits.