WordPress renders a page with PHP on every request and carries the CSS and JavaScript of its theme and plugins. Astro renders the page once, at build time, and sends HTML. The difference shows up in hosting, in the security surface and in what a client change looks like before it goes live.
What each stack does, rather than which one wins. Every row is something you can verify in either project's own documentation.
| What is compared | Astro | WordPress |
|---|---|---|
| What the browser downloads | HTML and CSS, plus JavaScript only for the components marked as islands. | HTML, plus the stylesheet and script of the theme and of each active plugin, which most themes enqueue on every page. |
| When the page is rendered | At build time, or per request through an adapter, chosen route by route. | Per request by PHP, unless a caching plugin or a host layer serves a stored copy. |
| What has to run to serve it | A static host or CDN. A purely static build needs no database and no application runtime. | PHP and a MySQL-compatible database, kept patched, plus the plugins on top of them. |
| Security surface | A static build exposes no login and no database. Forms and dynamic parts are separate endpoints you add deliberately. | A public admin login, a database and a plugin supply chain, each of which needs updating on the site that is live. |
| Who edits content | Editors work in Markdown or MDX files, or in a headless CMS connected to the build. | Editors work in the built-in admin and publish immediately, with no build step and no developer involved. |
| What a change looks like | A commit. It can be previewed and read as a diff before anyone deploys it. | A change in the database or in the files on the server. It is only reviewable if the team keeps themes and plugins in version control themselves. |
| What it costs to keep running | Build minutes and static hosting; no runtime to patch. | Managed hosting or a server, plus plugin licences and the maintenance those updates require. |
The two are not exclusive. WordPress can stay as the place editors write, with Astro reading its REST API at build time and shipping the result as static pages.
A speed comparison between two different sites measures the sites, not the stacks — and a number without its URL, date and throttling profile ages badly. Measure the project in front of you instead:
Compare the same page, not two different designs. A homepage with a video and a homepage with a heading are not a measurement.
Look at transferred bytes and the number of requests in the network panel, with the cache disabled and a cold profile.
Run the audit three times on the same throttling profile and report the median, not the best run.
Then check field data, which is what visitors actually experienced: the Core Web Vitals technology report is built from real Chrome users and is public.
Publish the URL, the date, the device and the throttling profile with every number, so someone else can get the same result.
Buy your licence. Download Astrology. Start creating.
Requires Node.js, npm and Git · AI features use your installed agent CLI