Astro or WordPress: which one for your website?

Two quotes are on the table. One agency proposes rebuilding the site with Astro, the usual provider swears only by WordPress, and each sells what it knows. We are not neutral either: this site is built with Astro, as is Palmora Property, a real estate portal we run for a client, in six languages and across more than 3,000 URLs. This comparison therefore relies on what the two projects themselves write and on real-world measurements, not on our preferences. The answer depends less on the technology than on how your team publishes. If the decision to leave WordPress has already been made, go straight to why migrate to a static site with Astro.

Two ways to build a page

WordPress is written in PHP and relies on a MySQL database. On every visit, the server assembles the page: it reads the content from the database, applies the theme and plugins, then sends back the result. A cache narrows the gap by keeping pages already assembled, but the application server is still there, with its database, to run and to update.

Astro builds the pages at the moment of publication. The result is a folder of HTML, CSS and image files that a host serves as they are: no database and no code is called on when a visitor arrives. Astro can also render pages on demand, on a server, when they need to be: that is the case for Palmora Property’s pages, which are rendered server-side.

Astro’s documentation devotes a guide to migrating from WordPress. It is not neutral, but it stays honest about what you lose by switching:

The same guide notes what they share: both suit content sites such as blogs, both think of the page in blocks, and both accept Markdown, with a plugin on the WordPress side.

What real-world data measures

HTTP Archive’s technology report compares sites according to the technology that runs them. It counts the share of sites, in the sense of a domain, whose real visits pass the three thresholds Google sets for loading, visual stability and responsiveness, at the 75th percentile, meaning for at least three page loads out of four. These are field measurements, taken from visitors, not lab tests.

On desktop, the gap is of the same order: 84.6% of Astro sites pass all three thresholds, against 53.7% of WordPress sites. The sharpest difference concerns server response time, which is not one of the three thresholds: it is rated good for 63.1% of Astro sites on mobile, against 22.9% of WordPress sites. This is consistent with the two ways of building a page: a file that is already prepared goes out faster than a page assembled on demand.

Three caveats before drawing a conclusion:

1. WordPress does better on one point: responsiveness to interactions, rated good for 90.3% of its sites against 85.0% of Astro sites. The report does not say why.
2. These are two populations, not an experiment. The report measures 2,658,175 WordPress sites on mobile, against 47,277 Astro sites, and an Astro site is maintained from a code editor, which already says something about who builds it. Nothing guarantees that your site, rebuilt with Astro, would gain as much.
3. Nearly half of WordPress sites pass all three thresholds. A well-maintained WordPress can be fast: measure yours before concluding you need to change.

What WordPress does better

• The dashboard, out of the box. A non-technical person writes, formats and publishes without touching a file. With Astro, you have to connect a CMS to get that convenience back.
• The plugin market. Forms, bookings, memberships, SEO: most common needs already have their plugin. Astro’s guide warns that some features have to be rebuilt.
• The ecosystem. HTTP Archive’s report measures more than 2.6 million WordPress sites on mobile, against around 47,000 Astro sites: finding a provider, a theme or an answer to a question is easier there.
• Editorial teams. WordPress provides roles out of the box: a contributor writes without being able to publish, an editor publishes other people’s posts. Its statuses cover pending review and scheduled publication. An Astro site gets these features from the CMS you connect to it.
• Selling online. WordPress has ecommerce plugins; an Astro site hands the transaction to an ecommerce platform.

What Astro does better

Speed, first, for the reasons seen above: a page that is already built waits for neither a database nor an application server.

Security and maintenance. The WordPress hardening guide points out that old versions no longer receive security fixes and asks, before anything else, to keep plugins up to date; automatic updates have existed since version 3.7. A static Astro site has no database and no code running on each visit: there is little left to attack. The risk shifts to the dependencies used to build the site: they need updating too, but they essentially run at publication time, not in front of every visitor.

Multilingual sites. The WordPress documentation says it plainly: WordPress does not support a bilingual or multilingual site out of the box, and community plugins take care of it. Astro includes routing by language that builds, uses and checks the URLs for each language.

That cost comes from the model and the cache, not from Astro. What Astro brings is one URL per language, built and checked by the framework; the rest plays out in the hreflang tags, where the costly mistakes of multilingual SEO hide.

Content in files. On this site, each article is a file: it arrives as a draft, is reviewed on a preview URL and goes live once accepted. This format lends itself to working with a coding assistant built on an AI model: you ask for a correction, the assistant finds the file, edits it and shows the result on a preview before anything goes live. And these files can be served from almost anywhere: hosting a static site costs little, as long as the site does not run code on every visit.

The third way: WordPress to write, Astro to serve

The choice is not necessarily either-or. Astro’s documentation describes using WordPress as a headless CMS: the team keeps its dashboard, and the WordPress REST API, available by default on every site, supplies the content that Astro turns into pages. A GraphQL plugin is possible, not essential.

The price of this setup: two systems instead of one, a WordPress that still needs updating even if it no longer serves visitors, and a mechanism that rebuilds the site at every publication, or pages rendered on demand. The same reasoning applies to a CMS designed for this use: we covered it in a headless site with Astro and Sanity.

How to choose, in five questions

1. Who publishes, and how often? An editorial team that publishes every day from a dashboard leans towards WordPress, on its own or connected to Astro. A site updated a few times a month gets along very well with files.
2. Does the site sell, or manage visitor accounts? If so, the transaction or the customer area decides the rest: WordPress and its plugins, or Astro connected to a platform that handles it.
3. How many languages? Beyond one, compare the language routing built into Astro with the plugin you will have to choose and keep updated on the WordPress side.
4. Who will maintain the site a year from now? A WordPress gets updated, plugins included; an Astro site needs someone comfortable with a code editor, or a coding assistant that does this work for the team.
5. Which plugins really matter? Make the list. Do the ones that count exist on the Astro side, or will they have to be rebuilt?

If your answers lean towards Astro, our static site migration takes over every URL so that it leads to its page in a single hop, sets up an AI workflow that lets your team change the site just by asking, and monitors the launch for fourteen days, with the old site ready to come back. Before starting, we check with you, in 20 minutes, that it is the right project. If they lean towards WordPress, keep it and look after it: nearly half of WordPress sites already pass Google’s three thresholds.

Frequently asked questions

Sources

1. Migrating from WordPress (new tab)docs.astro.build
2. HTTP Archive: Tech Report (new tab)httparchive.org
3. Roles and Capabilities (new tab)wordpress.org
4. Post Status (new tab)wordpress.org
5. Hardening WordPress (new tab)developer.wordpress.org
6. Multilingual WordPress (new tab)developer.wordpress.org
7. Internationalization (i18n) Routing (new tab)docs.astro.build
8. Headless WordPress & Astro (new tab)docs.astro.build
9. Cloudflare Acquires Astro to Accelerate the Future of High-Performance Web Development (new tab)cloudflare.com