How do you reach 100/100 Core Web Vitals with Astro?

Not through after-the-fact tuning, but through the architecture. Astro delivers pure HTML by default and only sends JavaScript to the browser where real interaction is needed (Islands Architecture). Together with static delivery without a database query on every request and deliberately optimized assets, there's little that blocks rendering – hence stably green scores and a Total Blocking Time of 0 ms.

Is the Speed Index a Core Web Vital?

No. The Core Web Vitals are Largest Contentful Paint, Cumulative Layout Shift and Interaction to Next Paint; in the lab test, Total Blocking Time serves as a proxy for it. The Speed Index is a supplementary lab measurement. That's why it's no contradiction when the Speed Index fluctuates on mobile while the actual Core Web Vitals stay stably in the green.

What's the difference between lab and field data?

Lab data comes from a simulated test on a throttled connection such as PageSpeed or Lighthouse and measures technical quality under controlled conditions. Field data from Google's CrUX comes from real visits on real devices. The two can diverge: a heavy test can cost points in the lab while real users experience the site smoothly – and conversely, field data is missing as long as there's too little visitor traffic.

Is WordPress slower than Astro?

Not fundamentally. WordPress can be fast even for feature-rich sites – but that takes ongoing discipline: consistent caching, lazy-loading, careful plugin selection and image optimization. With Astro, the lean, fast state is the default. So the advantage lies less in the peak score than in not having to constantly defend it.

Core Web Vitals with Astro: How We Achieve 100/100 PageSpeed

PageSpeed scores are often paraded around as trophies – usually a single screenshot with a green 100. We’re doing it differently here and laying out the real numbers from our own site, including the spots where they fluctuate. Anyone selling performance shouldn’t be massaging the numbers.

The site in question is codeaeffchen.com – our own bilingual website built on Astro. Here are the measured Lighthouse scores (version 13.3.0, as of June 6, 2026):

Metric	Mobile	Desktop
Performance	98 (fluctuates 98–100)	100
Accessibility	100	100
Best Practices	100	100
SEO	100	100
Largest Contentful Paint (LCP)	1.9 s	0.4 s
Cumulative Layout Shift (CLS)	0	0.005
Total Blocking Time (TBT)	0 ms	0 ms
First Contentful Paint (FCP)	1.0 s	0.3 s
Speed Index	3.8 s (sometimes 2.4 s)	0.5 s

On desktop, that’s 100 points across all four categories. On mobile we sit at 98 to 100 – and it’s worth talking about exactly this fluctuation.

Why the Score Fluctuates on Mobile – and Why That’s Fine

If you run the site through PageSpeed twice in a row, you won’t necessarily get the same score. Sometimes mobile shows 100, sometimes 98; the Speed Index jumps between 2.4 and 3.8 seconds. That’s not a flaw – it’s the nature of a lab test: it runs on a simulated, throttled mobile connection, and small variations in each run affect the number.

What matters is which values are stable. And those are exactly the ones that count: the Core Web Vitals – LCP, CLS, and (as a lab proxy) Total Blocking Time – are consistently green and stable. The only value that occasionally dips into yellow on mobile is the Speed Index. And that is not a Core Web Vital – it’s a supplementary lab measurement.

What this means for you: anyone handing you a single 100-screenshot as proof is showing you a snapshot in time. The more useful view is the individual metrics – and whether they remain stably in the green across multiple measurements.

An honest note: PageSpeed shows “No data” for this site’s field report. That simply means there isn’t yet enough real visitor data for Google’s field data (CrUX). The scores here are lab data – meaningful for technical quality, but not a substitute for measurement against real user traffic later on.

Why Astro Is So Far Ahead Here

These scores aren’t a tuning feat we painstakingly extracted from the site. They’re the result of the architecture. Three things carry it:

Almost no JavaScript at startup. Astro delivers pure HTML by default and only sends code to the browser where interaction is genuinely needed (Islands Architecture). Less JavaScript means: almost nothing blocks rendering – hence the Total Blocking Time of 0 ms.
Static delivery. The pages are pre-built. There’s no database query and no server-side processing on every request – the HTML is there immediately.
Control over every asset. Images, fonts, and stylesheets are optimized and delivered deliberately, without the bloat that a grown plugin setup often drags along.

The point isn’t that we optimized particularly hard. The point is that with Astro there was little to optimize in the first place, because there’s little overhead from the start. Performance is the default state here, not the goal of a cleanup campaign.

And WordPress? It’s Not Slow.

Now the uncomfortable honesty that most “Astro is fast” articles leave out: WordPress is not slow. We build feature-rich WordPress sites ourselves that are fast – with video heroes, sliders, event calendars, and social feeds. It works.

A concrete example from our projects is the YAYLA ARENA website – a genuine heavyweight: video hero, event slider, social feed, all on WordPress. In the lab test on a throttled test device it scores “only” 93 points, with the Largest Contentful Paint at 3.1 s there. But in real-world usage – the field data Google collects from actual visits – the site passes Core Web Vitals: LCP 1.9 s, Interaction to Next Paint 129 ms, Layout Shift 0. A feature-rich WordPress site that’s fast for real people.

This is exactly where the distinction between lab and field data matters: the throttled lab test penalizes the heavy hero, while real users on real devices experience the site smoothly. Conversely, for our Astro site: flawless lab scores, but no field data yet – simply because more visitor traffic is needed for that. No single metric tells the whole story; you need to know what each one measures.

The difference between the two paths lies in effort. On WordPress, you earn those scores: through consistent caching, aggressive lazy-loading, disciplined plugin selection, and careful image optimization. It works – the YAYLA ARENA proves it – but it’s ongoing work, and every new plugin can undermine the hard-won performance again.

With Astro, that constant effort largely falls away, because the lean state is the default. That’s the real advantage: not “faster than WordPress,” but “fast without having to constantly defend it.”

Which path is right depends on your project – that’s exactly what we examine in the honest Astro vs. WordPress comparison. And if you want to keep WordPress but want Astro’s speed, there’s a middle path: Headless WordPress with Astro.

What These Numbers Mean for You

Top performance isn’t an end in itself and it’s not a bragging screenshot. It pays off in concrete ways:

SEO: Core Web Vitals are a ranking factor. Stably green scores are the technical foundation on which content can actually rank well – more on this in our piece on Core Web Vitals. How Astro helps with search engine optimization beyond that is covered in Astro & SEO.
Conversion: Every saved second of load time reduces the bounce rate. Fast pages retain visitors; slow ones lose them – especially on mobile.
Peace of mind in operations: When performance is the default state, you don’t need to constantly recalibrate it. That saves ongoing effort.

Conclusion

100 on desktop, 98–100 on mobile, all Core Web Vitals stably green – those are the real scores from our Astro site, with all the fluctuations laid out honestly. We didn’t achieve them through after-the-fact optimization, but through an architecture where speed is the normal state.

And no, that doesn’t mean WordPress is slow. It means that on WordPress you need more discipline and maintenance to reach the same result. Which path fits you – we’ll tell you honestly, even if the answer is “stay with WordPress.”

Want to know where your site stands? Send us the URL – we’ll look at your real Core Web Vitals and tell you whether a performance rebuild is worth it, whether targeted cleanup of the existing site would be enough, or whether everything is already fine. Drop us a line.