WordPress or Astro: what the platform choice costs you

WordPress builds a page when a visitor asks for it. A static site generator builds every page once, before anyone arrives, then serves a file. The choice moved because the second path stopped needing someone to hand-write HTML for every page.

What changed in the calculation

Twenty years ago a content management system earned its place by removing one job: turning writing into web pages. Doing that by hand for a few hundred pages was work nobody wanted to repeat, so a database and an admin screen paid for themselves.

That job is now done by a build step. A generator reads markdown, applies a template, and writes HTML files into a folder. Publishing happens in a pipeline, and the pipeline can be triggered by a commit, a form, or a scheduled job. The cost of producing HTML fell to almost nothing, and the cost of running a live application didn’t fall with it.

What didn’t change is the reason a CMS exists at all. Some sites genuinely produce a different page for every visitor. A membership area, a cart with live stock, or a comment thread needs code running at request time. For those, a static folder is the wrong shape.

WordPress also changed. The block editor made publishing easier, automatic minor updates reduced a class of maintenance work, and WordPress Playground runs WordPress instantly, on any device, with no hosting to set up. This isn’t a story about old against new.

How each path delivers the page

Almost everything else depends on how the page reaches the visitor.

On WordPress, the visitor’s request reaches a web server that runs PHP. WordPress starts, queries the database, runs the theme and every active plugin, assembles an HTML document, and sends it back. The requirements page is explicit that WordPress needs a web server with PHP and a database behind it. That work repeats on every request unless a cache stores the finished page and serves it instead.

Caching is the standard answer, and it is a real answer. It is also one more moving part to configure, invalidate, and keep working after an update.

On a static build, the same HTML was written earlier. Astro’s own documentation on rendering states that by default its pages and routes are pre-rendered at build time as static pages. The visitor’s request resolves to a file, usually at a CDN edge close to them. No PHP process starts, no database is queried, and no plugin code runs to produce that document.

The point here is dependency, not just speed. On WordPress the visitor’s experience depends on the health of a running application at that moment. On a static site it depends on whether a file exists and is reachable.

Static isn’t the only option inside a generator either. Astro documents on-demand rendering through a server adapter, which brings the server back for routes that need it. Choosing a generator doesn’t force the static path.

Security read through attack surface

WordPress’s own hardening handbook frames the whole subject in one line: security is risk reduction, not risk elimination. That framing should survive any comparison.

The WordPress surface is a list of things that can be reached from outside. An admin login sits on the public internet. Database credentials sit on disk. Plugins and themes from many authors run with the same privileges as the core. File upload paths, the REST API, and XML-RPC add more entries. The same handbook says hosts are responsible for the infrastructure, not for the application you install. Then it tells you to keep plugins updated and delete the ones you don’t use.

None of this is a defect. It comes with running an application. A system that accepts input, stores it, and lets administrators act on it must authenticate, authorize, and validate all of it.

A static site has a much shorter list. There is no login to reach, no database listening at request time, and no server-side code executing per visit. What is published is HTML, CSS, images, and fonts. There is nothing to authenticate a stranger against, because no stranger can make the site do work.

But the attack surface doesn’t vanish. It moves. A static site still has a hosting account, a domain account, and a repository. An exposed deploy token or a compromised laptop reaches the published site just as directly as an exploited plugin reaches a WordPress site. Protecting the build pipeline becomes the job that protecting the admin panel used to be.

What each path costs to keep alive

Prices vary by host and region, so compare by mechanism instead of by invoice.

WordPress asks you to operate a running system. Core, themes, and plugins update on their own schedules, and each update has to be tested against the rest of the stack. You carry a host that runs PHP and a database, plus backups, uptime, PHP version, database size, and cache invalidation. The reward is that adding a capability is usually an install, and the content model bends to whatever you need.

A static site asks you to operate a build. Dependencies update, and a build can break, but it breaks where you can see it before a visitor does. Hosting can be a CDN serving files, which is a cheaper shape than a machine running an application. The content model is fixed by the schema you write, so a new field is a code change.

The costs invert at a specific point. A site with many editors, roles, revision history, scheduled publishing, and on-site comments is asking for an application. Rebuilding that on a static pipeline means rebuilding a content management system, and most teams do it worse than the one they left.

Performance, counted in what the visitor downloads

Start by counting the requests on each side.

A WordPress page typically ships the document, theme CSS, theme JavaScript, block library CSS and JavaScript, and whatever each active plugin adds to the front end. Every plugin that ships assets adds requests, and each optimization plugin added to reduce them is another plugin to maintain.

A static page ships the document, a stylesheet, and images. Astro’s islands documentation describes the model directly. Render most of the page to static HTML, and add small islands of JavaScript only where interactivity or personalization is needed.

Core Web Vitals turns that into a published target. Google Search Central states the thresholds as Largest Contentful Paint under 2.5 seconds, Interaction to Next Paint under 200 milliseconds, and Cumulative Layout Shift under 0.1. The web.dev guide to the metrics is the source for the 75th percentile: each threshold is met when 75 percent of page loads fall under it.

What matters here is what moves each metric. LCP improves when the largest element doesn’t wait on server work. INP improves when the main thread isn’t busy hydrating a large script. CLS improves when layout space is reserved before the content arrives. Static HTML starts with less to undo.

Perception research sets different numbers. NN/g’s limits on response time put 0.1 seconds at the edge of feeling instant and 1 second as the bound that keeps a flow of thought. Ten seconds is the limit of attention. Its article on website response times reports that large images stopped being the main cause of slow pages, which matches the request count above. Progress indicators cover what to show when a wait can’t be avoided.

The two frameworks disagree on purpose. NN/g measures what a person feels, interaction by interaction, while Core Web Vitals is field data at the 75th percentile. A page can pass LCP at 2.5 seconds and still sit above the 1 second limit that preserves a train of thought (Core Web Vitals, NN/g).

The counterpoint: a well-cached WordPress site on a light theme can pass all three. Google measures your pages, not your framework, and field data decides the result.

When WordPress is still the right choice

• Many editors who should never touch code, with roles and permissions that differ per person.
• Content that differs per visitor or per session, such as membership areas, live stock, or a cart.
• A capability you can’t build yourself and a maintained plugin exists, such as payments, bookings, or a course platform.
• Comments and community living on the site rather than on a social platform.
• A team that already knows WordPress, where retraining would cost more than hosting.
• A host that handles the server, so you never touch the machine yourself.

And those cases aren’t rare. WordPress is the correct answer more often than a comparison post usually admits.

The question that decides it

Ask one thing: does the page differ per visitor at the moment of the request?

If the answer is no, the work belongs at build time, and serving files removes a layer of running code from the visitor’s path. If the answer is yes, you need an application, and WordPress is a mature one with a large ecosystem behind it.

Cost, speed, and security all follow from that answer.

The same adopt-or-build decision appears in the Material Design post, on a smaller scale.