We Rebuilt the Same Site Twice: WordPress vs. Astro, Measured on Everything

I went looking for an open-source alternative to WordPress. Then I tested it the only way that counts: head to head, on a live site, with Google doing the scoring.

Let me start with a confession: I like WordPress. We’ve built on it for years, and with the new Elementor 4.0 atomic editor it’s genuinely the best it has ever been. But every WordPress site carries the same baggage; a database that has to answer every request, a stack of plugins that each need updates, and a single server that has to stay standing.

The support ticket that forced my hand

It started with a support ticket from one of our SaaS clients: their website was being flagged by SecurityScorecard, one of the rating services that large companies use to vet vendors before signing, and their score was costing them enterprise deals. That’s the part most people don’t know about enterprise sales: procurement teams run automated security scans on your website, and an imperfect grade can quietly end a deal before anyone talks price. That’s something I learned the hard way.

When we dug in, we found that no matter what we did, we couldn’t get them from a B to an A score. Ultimately the root cause wasn’t sloppy work. It turns out, it was the platform itself. WordPress ships with zero security headers; none of the browser-level protections that scanners check for are on by default, because with every site running a different mix of plugins and themes, no universal policy could work. Managed platforms handle this automatically; WordPress leaves it entirely to the site owner. Worse, a previous attempt to bolt headers on had silently broken things: the security policy only whitelisted three services while the site actually depended on more than a dozen, so analytics, conversion tracking, and cookie consent had been quietly failing with no visible sign on the site. This meant we have to whitelist services like CookieYes, Calendly, LinkedIn, SalesLoft, on each site individually on each launch.

So, we built a custom plugin and fixed what could be fixed, across every WordPress site we manage. But two findings can never go green on WordPress. Its security policy must include exceptions called “unsafe-inline” and “unsafe-eval,” because WordPress and Elementor literally require them to function; remove them and the site breaks. And a protection called Subresource Integrity, which proves that the scripts a page loads haven’t been tampered with, simply can’t be implemented in WordPress’s script system. Read that back: the platform requires the exact exceptions the scanners flag. The best possible WordPress score is a permanently imperfect one. That’s the just the way it is. It’s been like this for years, and it seems WordPress has chosen this hill to die on.

On a compiled, static site, none of those compromises are required; strict security headers are just settings. So I went hunting for an open-source alternative that could drop the baggage without dropping the design quality our clients expect.

That search ended at Astro, an open-source framework that compiles your entire site ahead of time into pure, static code, paired with Cloudflare’s global edge network, which copies that site to hundreds of data centers around the world. No database. No plugin stack. No single server.

Promising on paper. But I don’t ship “promising on paper” to clients, so we ran a real test.

The test

We took one of our most demanding builds; an animation-heavy site full of scroll effects and motion, and built it twice. Same design, same content, same imagery:

1. WordPress, running the brand-new Elementor 4.0 atomic editor
2. Astro, deployed on Cloudflare’s edge network

Both live on real domains, both measured with Google PageSpeed Insights; the same lab Google uses to judge the speed signals that feed your search rankings. Because lab scores naturally vary a little between runs, we tested each site three times and report the medians. Every report is linked at the bottom of this post, so you can check our math.

tgiq.madebyproxy.com (Astro) vs thegirlinquestion.me (Elementor 4.0)

Credit where it’s due: WordPress showed up

Here’s the part that surprised me. On desktop, the WordPress build scored a 95 on performance with a 1.1-second largest contentful paint, and it posted a perfect 100 on best practices; a category where it beat our Astro build outright. For a WordPress site running heavy animation, those are the best numbers we’ve ever pulled from the platform. Elementor 4.0 is a real leap forward, and if you’re staying on WordPress, there has never been a better time.

For a moment I wondered if this experiment was about to be embarrassing.

Then Astro ran

Same design, same animations, on Astro + Cloudflare. Medians of three runs each:

Look at the mobile row first, because that’s where your visitors actually are: 77 versus 95. Eighteen points, on the exact same design; the difference between Google’s “needs improvement” zone and an excellent score. The main content appears in 2.9 seconds instead of 5.0. And in every single run, Astro recorded zero milliseconds of blocking time; the page never once froze while loading. That’s with every animation intact… we didn’t strip a single effect to get there.

Full transparency: WordPress took the best-practices category, and SEO was a tie. We’re publishing that anyway, because the point isn’t that WordPress is bad. It’s that a genuinely great WordPress build, on its best editor ever, still can’t close the speed gap; and speed is the metric that feeds rankings, ads, and conversions.

Why this happens (and why it can’t really go the other way)

This isn’t about one platform being “better made.” It’s structural. WordPress assembles your page on demand: a request comes in, PHP runs, the database answers, plugins fire, and then the page goes out. Astro does all of that work once, at build time, and ships the finished page to Cloudflare’s edge; so your visitor in Denver or Dubai gets it from a data center a few miles away, already assembled.

That structure is also why the security story changes completely. There’s no database to hack, because there’s no database in the request path. There’s no plugin bloat, which closes the #1 source of WordPress breaches. And because Cloudflare caches the whole site at the edge, a viral traffic spike that would flatten a WordPress server barely registers; the site just keeps serving.

But what about the dynamic stuff?

Fair question. Static pages are fast, but real businesses need features: forms, comments, gated content, search, integrations. On WordPress, every one of those is a plugin; and every plugin adds weight to every page, because it runs inside your site with access to everything. On our stack, those jobs go to Cloudflare Workers: tiny, isolated programs that run beside your site on the same global network. The feature exists; the page never gains a gram. Plugins add features by adding weight. Workers add features without touching the page.

We know because we run our own products on them. Our client-feedback platform, Gizmonote, lets clients click anywhere on a live design and leave comments with screenshots and image attachments; it handles storage, access gating, and even a feature-voting board, all on Workers and edge storage. No server to patch, no database server to babysit, and hosting costs measured in pennies. It’s free to try: gizmonote.madebyproxy.com.

This is the part that quietly changes what a “website” even is. The line between websites and apps is blurring; a site on this stack can listen, think, and respond like an app, without app-sized infrastructure. Here’s a proof of concept we built: a voice-responsive AI chatbot that deals out automation advice. You talk to it; it talks back. The voice runs on your browser’s built-in speech engine, and the intelligence is an AI model reached through a tiny Cloudflare function (a Worker) that keeps the API key safely server-side; with no actual server anywhere. It took about thirty minutes to set up. I couldn’t believe it either! Now if I can only get it to sound like Morgan Freeman…

Why Astro and Cloudflare, specifically

One more reason this pairing isn’t duct tape: in January 2026, the team behind Astro joined Cloudflare. The framework and the network are now developed under one roof, so the integration keeps getting tighter by design. And here’s the part that matters for you: Astro remains free, open source, and fully platform-agnostic. Your site is standard code you own, deployable anywhere. We choose Cloudflare because it’s the best home for it; not because anything locks you there.

What this means for your business

Speed isn’t a vanity metric. It feeds your Google rankings, your ad quality scores, and the patience of every visitor deciding whether to stay; especially on phones, where the gap was eighteen points. Security isn’t abstract either; it’s the difference between a site you check on and a site you worry about. Astro + Cloudflare bakes both in at the architecture level, not the plugin level.

Try it first

We’re opening early access to Astro builds for a small group of clients before we roll them out wide. If you want your next site (or your current one, rebuilt) on this stack, reach out; we’ll walk you through what the move looks like for your specific site.

The future of content-driven web design is compiled, cached, and everywhere at once. We’ve measured it!

Sources

Every PageSpeed Insights report from this test, unedited. Medians reported above.

WordPress (Elementor 4.0):

• WordPress · Run 1
• WordPress · Run 2
• WordPress · Run 3

Astro + Cloudflare:

• Astro · Run 1
• Astro · Run 2
• Astro · Run 3