Core Web Vitals: why speed makes or breaks your visibility

A beautiful website that loads slowly loses visitors before they have seen anything. Google poured that experience into measurable numbers: the Core Web Vitals. They help determine how you rank and how user-friendly your site feels. Anyone who understands them also understands why architecture matters more than a final round of optimisation: a site that starts light scores better almost by itself than a site you have to try to fix afterwards.

What exactly are the Core Web Vitals?

The Core Web Vitals are three metrics that together approximate how a real visitor experiences your site, not how it looks in an ideal lab.

• LCP (Largest Contentful Paint): how quickly is the largest content (often a hero image or title) visible? This measures perceived loading speed.
• INP (Interaction to Next Paint): how quickly does the page respond when someone clicks, taps or types? This measures smoothness.
• CLS (Cumulative Layout Shift): how much does the layout shift while loading? This measures visual stability.

Which thresholds count as good?

Google sets clear limits per metric (source: web.dev). They apply to the 75th percentile of your visitors, so your site needs to stay below them for the large majority.

Metric	Good	Needs improvement	Poor
LCP	up to 2.5 s	2.5 to 4 s	more than 4 s
INP	up to 200 ms	200 to 500 ms	more than 500 ms
CLS	up to 0.1	0.1 to 0.25	more than 0.25

So the target is not “as fast as possible” in absolute terms, but staying below these limits for as many real visitors as possible, including on an average phone.

Why is JavaScript the biggest enemy?

Most slow sites have the same problem: too much JavaScript. The browser has to download, parse and execute it before the page is truly usable. That pushes the LCP up and makes the INP slow, certainly on a device with less processing power.

The less JavaScript you ship, the less work the browser has, and the better your scores. That is why the amount of JavaScript sent is so decisive, and why sites with many plugins or a heavy client-side approach often lose points here.

What is the difference between lab data and field data?

This confuses a lot of people. A Lighthouse test in your browser is lab data: a measurement in a controlled environment, handy for tracking down problems. The numbers Google uses for ranking come from field data, the Chrome User Experience Report (CrUX), based on real visitors with real devices and connections.

A green Lighthouse score is therefore no guarantee: if your real visitors are on slow phones, your field data can disappoint. So steer by the field data, not by a lab number.

The starting position of a content-first stack

This is where the structural advantage of Astro lies. By delivering pages as static HTML and shipping little JavaScript by default, an Astro site starts from a better position for the Core Web Vitals. You do not have to fight plugin scripts afterwards; you start light.

Independent data supports that. According to Search Engine Journal, based on the HTTP Archive and CrUX (data April 2026), roughly 67% of Astro sites achieve a good Core Web Vitals score, compared with roughly 49% of WordPress sites. An important nuance: that difference also reflects the type of sites, and the advantage can shrink as a site becomes more complex. It says something about the default starting position, not that every site automatically becomes faster.

That is no guarantee of a perfect score (images, fonts and third-party scripts also play a part), but it is the difference between fighting against a heavy base and starting from a light one. How that approach works technically you can read in the islands architecture explained.

How do you measure your Core Web Vitals?

You do not have to guess; the tools are free.

• PageSpeed Insights: paste a URL and you get both lab and field data per page, with concrete recommendations.
• Google Search Console: the Core Web Vitals report shows how your whole site is doing based on real visitors, grouped by type of page.
• Lighthouse (in the browser): handy during building to catch regressions early.

Start with Search Console for the overview, and use PageSpeed Insights to dig into a specific slow page.

Common mistakes that break your scores

• Images without fixed dimensions, which makes the layout shift (poor CLS).
• A heavy hero image that drives the LCP up; compress it and serve modern formats.
• Render-blocking third-party scripts (chat widgets, trackers) that load early.
• Too much or too early loaded JavaScript that makes the INP slow.
• Web fonts that load late and cause text to shift or hide.

SEO and GEO: the same win twice

Speed pays off twice. For classic SEO the Core Web Vitals are one of the signals for user experience, and fast pages get crawled more smoothly. For GEO, your visibility in AI answer engines, what counts is that content can be retrieved quickly, semantically and in a well-structured way. Clean, fast HTML serves both at once. Whether you optimise for Google or for an AI assistant, you build on the same foundations.

Practical checklist

• Give images and embeds fixed dimensions, so they do not cause layout shift.
• Load JavaScript only where interaction is needed (the islands approach).
• Defer heavy, non-critical scripts until after loading.
• Self-host your fonts and preload only what is needed above the fold.
• Compress images and serve modern formats.
• Measure with field data, not just with a lab test.

Conclusion

Core Web Vitals are not a separate task on your to-do list, they are a consequence of how your site is built. Start light, with little JavaScript and stable HTML, and you win both with Google and with AI search engines, and you have to adjust far less afterwards. If you want to see how that approach works in practice, read why Astro is fast by design or how Astro compares to WordPress.