Core Web Vitals: What They Mean and Why Google Cares
LCP, CLS, INP — the three metrics Google uses to judge your website, explained in plain English with real numbers and fixes.
What are Core Web Vitals
Google measures three things about every website it crawls. These three metrics are called Core Web Vitals, and they directly influence where you rank. Not in a vague way. Google has said, on the record, that page experience is a ranking signal. If two pages have equally good content, the faster, more stable one wins.
Here are the three, in plain English.
LCP — Largest Contentful Paint. How long until the biggest visible element finishes loading. Usually a hero image or a large headline. Target: under 2.5 seconds. Above 4 seconds and Google considers your page slow.
CLS — Cumulative Layout Shift. How much the page jumps around while it loads. You know the feeling — you go to tap a link and the page lurches and you tap the wrong thing. Target: under 0.1. Above 0.25 and it is bad.
INP — Interaction to Next Paint. How quickly the page responds when someone taps or clicks. This replaced the old FID metric in 2024. Target: under 200 milliseconds. Above 500 milliseconds and the page feels broken.
Why Google cares
Google’s job is to show people the best answer to their question. A slow, janky page is a bad answer, even when the words on it are great. So Google folds page experience into ranking. It is not the strongest signal — content and links still matter more — but it is a real one, and it is one you can control.
There is also a commercial reality. A slow page loses visitors before they ever read your content. The ranking penalty and the bounce-rate penalty point the same direction. Fix performance and you fix both.
How to measure them
You do not need expensive tools.
- PageSpeed Insights (pagespeed.web.dev) gives you lab data for any URL in about ten seconds, with field data from real Chrome users alongside it.
- Google Search Console has a Core Web Vitals report that shows you which of your pages are failing, based on real visitor data over the previous 28 days.
- Lighthouse, built into Chrome DevTools, runs the same audit locally and tells you exactly which requests are dragging you down.
The number to trust most is the field data in Search Console, because that is from real people on real phones. Lab data is useful for diagnosing. Field data tells you whether you actually have a problem.
The usual suspects for bad LCP
LCP is almost always one of three things.
- A large, unoptimized hero image. A 2MB JPEG at the top of your page is the single most common cause. Fix: serve WebP or AVIF, resize the image to the actual display dimensions, and set it to load eagerly with a fetch priority hint.
- Render-blocking JavaScript. A 200KB script in the
<head>that the browser has to download, parse, and run before it can paint. Fix: defer non-critical scripts, or remove them if the page does not need them. - Slow server response. If your origin server takes 800 milliseconds to send the first byte, nothing else can be fast. Fix: put your site behind a CDN and serve static files from the edge.
The usual suspects for bad CLS
CLS comes from things that change size after they appear.
- Images without explicit width and height. The browser reserves no space, the image loads, and the content below it gets shoved down. Fix: always set
widthandheightattributes (or an aspect-ratio in CSS). - Late-loading ads and embeds. A banner that pops in three seconds after load. Fix: reserve fixed space for them or load them below the fold.
- Web fonts that swap in late. The fallback font and the real font have different metrics, so text reflows. Fix: use
font-display: swapand match the fallback’s metrics to the web font.
The usual suspects for bad INP
INP measures the gap between a tap and the next painted frame. It is almost always JavaScript.
- A heavy main thread. A long task that runs for 100ms or more blocks the page from responding. Fix: break long work into chunks, or move it off the main thread.
- Third-party scripts. Analytics, chat widgets, ad tags. Each one runs on your main thread and each one adds latency to every interaction. Fix: audit them, delay non-critical ones, and remove the ones you do not need.
- Client-side hydration of a large page. The framework is busy wiring up the page while the user is trying to use it. Fix: ship less JavaScript. Hydrate less.
How Astro fixes all three
This is not theory. Here is how a static Astro site handles each metric by default.
LCP. Static HTML loads the moment the bytes arrive from the CDN. There is no JavaScript parsing delay before the first paint. A well-built Astro page hits LCP in well under a second.
CLS. Every element is in the HTML from the first byte. Images carry dimensions. There is no late-injected content. Nothing pops in. CLS is effectively zero.
INP. With zero JavaScript on most pages, the main thread is always free to respond to input immediately. There is nothing competing for attention. INP lands in single-digit milliseconds.
Every site we build scores in the green on all three metrics, and 100 across the board on Lighthouse Performance. That is not a brag. It is the natural result of shipping less. You do not have to optimize what you never shipped.
The one caveat
Core Web Vitals are necessary but not sufficient. A fast page with thin content still ranks poorly. A slow page with the best content on the internet still loses visitors. You need both — solid content and a solid technical foundation. The good news is that the technical foundation, once set, mostly takes care of itself. You set it up once and it keeps paying off on every page you publish.
Want scores in the green without fighting your own site? We build fast pages by default. See pricing or get in touch.
Need a website like this?
We build fast, SEO-optimized sites that actually rank. From $199.
Get in touch →
