The result
Is Astro faster than WordPress? Usually the answer comes from comparing a lightweight Astro starter with a WordPress site full of plugins and a page builder. That isn’t much of a test.
So I took my own WordPress home page, which is already well optimised, rebuilt it in Astro, and put both on the same server behind the same CDN. Then I measured them the same way, at the same time, many times over. Astro came out ahead, by half a second on mobile and a tenth of a second on desktop. The more useful finding is how far a well-built WordPress site is ahead of a typical one.
Both versions are still live, so you can check them yourself: the Astro build and the WordPress home page. Run either through PageSpeed Insights and you should see numbers close to mine. The Astro copy is set to noindex so it can’t compete with the real home page in Google, which is why PageSpeed marks its SEO score down.
Was it a fair test?
This is the part most comparisons skip, so here is all of it. Everything stayed the same except how the page is built.
The form is the one thing the two can’t share: a static site has no server to process a submission. So the WordPress figures include a little work the Astro page doesn’t do.
Google’s own test
The PageSpeed Insights API, same settings, every run, on 22 October 2026.
Warm-up first
The first run of each page was thrown away, so a cold cache counted for neither.
Five runs each, alternating
Astro, WordPress, Astro… so changing network conditions hit both.
A fresh result every time
Each run forced a new report with its own timestamp; the URLs and CDN cache never changed.
Ten cities for server speed
The same ten Globalping test machines measured both sites, five rounds after a warm-up.
Medians, not best runs
Every figure is the middle value. Every individual run is shown below.
How fast each page appears
Two moments matter to a visitor: when something first appears on screen, and when the main content is there. Astro was ahead on both, on phones and on desktop.
Main content is Largest Contentful Paint; first paint is First Contentful Paint. Total Blocking Time and layout shift were 0 on every run for both sites.
Every run, not just the median
Astro’s numbers barely moved. Its main content landed at exactly 1.58 s in all five runs on mobile. WordPress varied by less than a tenth of a second.
Where the weight goes
Fonts were identical, as they should be. The difference is in the HTML, CSS, JavaScript and images. On the WordPress side the extra comes from block styles, the scripts behind interactive blocks and the menu, and plugin files.
Desktop page weight, by file type
Desktop requests: one square per file the browser fetched
Measured in a real browser after scrolling the whole page. Astro also has two small inline scripts. The empty squares are the five extra WordPress files. On mobile: 184 KB against 256 KB, 25 requests against 30.
Server response around the world
With the page cached at the CDN, the server never builds anything, so the platform makes almost no difference here. Across all ten test cities, Astro was quicker in five, WordPress in two, and three were level. A properly cached WordPress page responds as fast as a static file.
Astro 20 ms quicker
Astro 12 ms quicker
Astro 8 ms quicker
Level
Level
WordPress 14 ms quicker
Globalping HTTP: connection, TLS and first byte, DNS excluded. Median of 5 rounds after a warm-up. Six of the ten test cities shown; the median across all ten was Astro 51 ms, WordPress 55 ms.
The gap that actually matters
The same evening, with the same test, I ran a typical page-builder WordPress site, a real business site I won’t name. The difference between a well-built and a typical WordPress site is five times bigger than the difference between WordPress and Astro.
What each does better
Speed is one line on the list. Here is the rest of it, side by side.
So which should you choose?
Astro is a good fit if
- the site is mostly information pages that rarely change
- whoever updates it is happy working in code, or adding a headless CMS
- forms and dynamic features are simple or handled by outside services
WordPress is a good fit if
- you want to edit your own content without a developer
- the site relies on forms, bookings, a shop or memberships
- you need features that plugins already provide well
And if your WordPress site is slow, changing platform is rarely the first fix. The usual cause is what has been added over time: a heavy page builder, plugins loading files on every page, oversized images and third-party scripts. I covered the usual suspects in Core Web Vitals for WordPress: What Actually Matters?, and you can see what fixing them does on real sites in the case studies. If you want yours looked at, that’s what my performance audit is for.
I work through Codeable, where every WordPress developer is vetted before they take on client work. If you want help with your own site, you can hire me on Codeable.
What this test can’t tell you
- It’s lab data. The results come from Google’s PageSpeed test, run under the same conditions for both pages, rather than from real visitors’ devices.
- It’s one page. The Astro version only has the home page, with no translation and no form back end.
- Speed Index isn’t included. On mobile it jumped between two very different values from run to run on both sites.
- Responsiveness to taps isn’t included. It can only be measured with real visitors. Total Blocking Time, the closest lab measure, was 0 ms on both.
- The WordPress site was already optimised. That’s the point of the test, but it means these results don’t describe a typical WordPress site.
FAQ
Astro vs WordPress: common questions
Short answers, based on the test above.
In this test, yes, by about half a second on mobile and a tenth of a second on desktop, with the same design on the same server. Both pages passed every Core Web Vitals threshold.
Not by itself. Both pages pass Core Web Vitals and carry the same titles, descriptions and structured data. Content, links and how the site is built matter far more than the platform.
Yes. Astro can pull content from WordPress through its API, so editors keep the WordPress editor. You then run and maintain two systems instead of one.
Only with outside services or a separate back end. WordPress handles both itself.
Usually because of what has been added to it, not WordPress itself: a page builder, heavy plugins, large images and third-party scripts.
