Astro Sites Pass Core Web Vitals 67% of the Time. WordPress 49%. Here's Where the Gap Comes From.

Forty-nine percent of WordPress sites pass Core Web Vitals. Sixty-seven percent of Astro sites do. That's April 2026 field data from the Chrome UX Report and HTTP Archive, as reported by Search Engine Journal, and it's the closest thing we have to a fair fight: millions of real sites, real visitors, real networks.

I want to be careful here, because most astro vs wordpress performance posts are written by people selling one of the two. So this one is built out of numbers I can point at. Published benchmarks, public field data, real price pages, and one set of measurements I ran myself and already wrote up. Where I'm estimating, I'll say so out loud.

Let me start with the part that surprised me most, because it isn't the part people argue about.

Astro 7 Cut Build Times 15% to 61%, and I Measured 40% of That Myself

Astro 7 shipped on June 22, 2026 and rewrote the .astro compiler from Go to Rust, replaced the Markdown and MDX pipeline with a Rust processor called Sätteri, and moved to Vite 8 with Rolldown. Astro's own release post publishes the benchmark table on an M4 Pro: astro.build's 308 pages went from 62.70s to 24.24s (61.3% faster), docs.astro.build's ~6,313 pages from 114.54s to 73.53s (35.8%), and developers.cloudflare.com's 8,431 pages from 386.89s to 261.94s (32.3%). The Rolldown bundler is quoted at 10 to 30 times faster than Rollup, and the new queued renderer at roughly 2.4x the old recursive one.

Vendor benchmarks make me itchy, so I ran my own before I wrote a word of this. On a 129-page site, the production build went from 4.95s on Astro 6 to 2.95s on Astro 7, median of five runs, same machine, same Node version. Forty percent, for the price of changing a version number. The full breakdown, including the numbers that refused to move, is in Astro 6 to 7: the real numbers from upgrading a 129-page site.

Here's the honest catch: WordPress has no build step at all, so this entire column is a category difference, not a win. WordPress renders on request instead. That trade is the whole story, and it's where the runtime numbers come from.

The Field Data: 2.76 MB Versus 1.65 MB

The April 2026 CrUX and HTTP Archive snapshot puts WordPress median page weight at 2.76 MB and Astro at 1.65 MB. Median Lighthouse score: WordPress 44, Astro 68. Core Web Vitals pass rate: WordPress 49%, Astro 67%. For context, the 2025 Web Almanac put the median page across the whole web at about 2.4 MB, so WordPress is heavier than the average site and Astro is meaningfully lighter.

Two caveats I refuse to skip. First, this is a population comparison, not a controlled experiment. Astro sites skew toward developer-built marketing sites and docs; WordPress carries everything from a hand-tuned agency build to a 2014 theme with 43 plugins that nobody has touched since. Second, Astro at 67% still means a third of Astro sites fail Core Web Vitals. The framework is not a magic pass.

What the data does support is a directional claim: the median WordPress site ships roughly a megabyte more per page than the median Astro site, and the gap shows up in field measurements taken on real visitors, not lab tests.

TTFB Is Where the Architecture Actually Decides Things

Page weight is a symptom. The structural difference is what happens in the first few hundred milliseconds.

An uncached WordPress request wakes PHP, boots the core, loads every active plugin, queries MySQL several times, renders a theme template, then starts sending bytes. A static Astro page is a file that already exists on a CDN edge node. Google's threshold puts a Time to First Byte of 800ms or under in the "good" band, 800ms to 1.8s in "needs improvement," and anything above 1.8s as poor. HTTP Archive's median mobile TTFB sits around 1.3s, which tells you how much of the web is stuck in that middle band.

I'll flag this clearly: I do not have a published, apples-to-apples TTFB benchmark of identical content on both stacks. Anyone who hands you one probably built it to win. What I can tell you from client work is the shape of it. Uncached PHP page generation typically lands in the high hundreds of milliseconds; a full-page cache hit or an edge-served static file lands in the low tens. That's a rough characterization from sites I've worked on, not a controlled measurement, and you should measure your own before quoting it. My guide to testing website load time walks through how.

The Whole Comparison in One Table

Here's the whole astro vs wordpress performance comparison in one place. Every cell says where it comes from, and every estimate is labelled as one.

Metric	WordPress	Astro 7	Source
Build time	No build step	24.24s for 308 pages, 73.53s for 6,313	Astro 7 release post, M4 Pro
Build speedup, v6 to v7	n/a	15% to 61% published, 40% on my own 129-page site	Astro release post; my upgrade numbers
Median page weight	2.76 MB	1.65 MB	CrUX + HTTP Archive, April 2026
Median Lighthouse score	44	68	Same dataset
Core Web Vitals pass rate	49%	67%	Same dataset
TTFB, uncached	Hundreds of ms (estimate)	Not applicable, files are prebuilt	My client work, labelled estimate
TTFB, cached or edge-served	Low tens of ms (estimate)	Low tens of ms (estimate)	Same
JS shipped by default	Theme plus plugin scripts, jQuery still common	0 KB unless you opt into an island	Framework defaults
Hosting, entry tier	$25/mo WP Engine, $35/mo Kinsta	$0 on Cloudflare Pages free tier	Vendor pricing pages, 2026

That last row is the one clients react to, and it's also the one that's most misleading on its own. More on that in a minute.

Where WordPress Closes the Gap, and It Closes a Lot of It

A good caching layer changes almost everything in the runtime half of that table. When a full-page cache serves a prebuilt HTML file, WordPress stops being a PHP application for that request and becomes, functionally, a static file server. PHP doesn't boot. MySQL isn't queried. The architectural advantage I described two sections ago mostly evaporates.

I've written about the tooling that does this. FlyingPress handles page caching, critical CSS, lazy loading, and unused CSS removal well enough that I've seen it turn genuinely slow client sites into ones that pass Core Web Vitals. Pair it with a host that has server-level caching and a real CDN rather than $4/month shared hosting, and you're in a different conversation entirely. I reviewed Cloudways for exactly this reason.

So the fair version of the claim is narrower than the headline: a well-hosted, well-cached WordPress site can absolutely beat a badly built Astro site. The 49% pass rate isn't a verdict on WordPress the software. It's a verdict on the median WordPress installation, which is a very different thing. The gap in the field data is mostly a gap in defaults, plugin discipline, and hosting budget.

Where WordPress still structurally loses: the JavaScript row. Astro ships zero JS unless you explicitly hydrate a component. WordPress ships whatever your theme and every active plugin queue up, and cache plugins can defer that but can't delete features you're actually using. If your site loads five plugins that each enqueue their own script, no caching layer makes those bytes disappear.

The Cost Column Has a Second Half Nobody Shows You

Free hosting is real. Cloudflare Pages serves static sites on a free tier with unlimited bandwidth and requests, and I run client sites on it. Against $25 to $35 a month for entry managed WordPress, that's $300 to $420 a year saved on paper.

Except the paper is incomplete. If the client needs to edit content, an Astro site needs a CMS behind it, and that's either a hosted service with its own bill or a self-hosted one with its own server. Add the developer hours for a build pipeline that a WordPress site gets from an admin login. For a five-page brochure site that changes twice a year, the free tier is the honest answer. For a site where three non-technical people publish weekly, the hosting savings can vanish into the first invoice for "can you add a field to the blog template."

I go through that whole calculation, and how it decides the stack, in WordPress, Next.js, or Astro? Here's how I actually decide for client projects. And if you're wondering whether the switch itself is survivable, I moved three client sites from WordPress to Astro and nothing broke.

What I Actually Conclude from All This

The measurable astro vs wordpress performance gap is real, it's roughly a megabyte of page weight and 18 percentage points of Core Web Vitals pass rate at the median, and it comes from architecture: one stack ships a file, the other assembles one.

But the gap is not fixed. Most of the runtime half closes with a caching plugin and a competent host, which costs less and breaks less than a migration. The build half doesn't apply to WordPress at all. And the cost half depends entirely on who edits the site and how often.

What I'd tell you to do before believing me or anyone else: measure your own site. Field data from CrUX, not a Lighthouse run on your gigabit office connection. If your WordPress site already passes Core Web Vitals, the performance argument for switching is over, and you should be arguing about maintenance and security instead. If it doesn't, try the caching layer first. It's a Tuesday afternoon, not a quarter.

I do this measurement work for clients at Wunderlandmedia: benchmark first, then decide what's actually worth rebuilding. Usually less than the pitch deck says.