Both camps are right about different things, and the question that decides it isn't speed. It's who edits the site and how often. This site makes a useful test case: it ran as a static Astro build until early September 2026 and runs on WordPress now, so the numbers below come from measuring one real site, not from a benchmark on somebody else's setup.
The short answer
A static site serves a file that already exists. WordPress builds the page on request unless a cache stands in front of PHP. With a full-page cache, a WordPress page on this site leaves the server in 8 to 20 ms, against 300 to 500 ms uncached. Speed matters less than who has to publish, and how often.
What a request costs on each side
A static site serves a file that already exists. The HTML was built once, at deploy time, and the web server hands it over with no PHP, no database and nothing to wait for. WordPress does the opposite by default: PHP starts, MariaDB or MySQL gets queried, the theme stitches the page together, and only then does a byte leave the server.
Caching closes most of that gap, and we can put numbers on it. On this site's own server, an uncached page takes 300 to 500 ms before the first byte leaves. With nginx's FastCGI cache in front of PHP, the same page is served from disk in 8 to 20 ms. A cached WordPress page is a file served by nginx too, just one that PHP produced the first time somebody asked for it.
The cache has limits worth knowing before you lean on it. It's bypassed for logged-in users, for POST requests, for anything with a query string and for the admin and API paths, because those responses can differ per visitor. The first visit after a flush also pays the full 300 to 500 ms, and a crawler that walks hundreds of pages right after a purge pays it hundreds of times. A static site doesn't have that failure mode, and that's a real advantage, not a rounding error.
What a fast server doesn't fix
Time to first byte is only the start of a page load. When this site was audited on 7 October 2026, the server was quick and the pages still weren't, because the theme and its page builder shipped a lot of CSS and JavaScript on every page, along with several plugins nobody used. Lighthouse on mobile scored 62 to 67, with total blocking time between 360 and 570 ms.
Four changes did most of the work: dropping the page builder's front-end scripts and styles from pages that don't use it, switching off six unused plugins, serving WebP images to browsers that accept them, and hosting the one web font on the site itself instead of loading it from Google. The image library went from 730 MB to 133 MB, and one typical image went from 169 KB to 27 KB. Pages came out 25 to 35 percent lighter. Re-tested the same evening, mobile scores ran from 75 on a hub page to 94 on the home page, total blocking time from 60 to 350 ms, and every desktop run scored 100.
It isn't finished. Largest Contentful Paint on Lighthouse's throttled mobile profile is still 2.7 to 3.8 seconds, held back mostly by the theme's render-blocking stylesheet and scripts. A lean static page would likely have a head start there, and a heavy static page wouldn't: what you ship matters more than where it's built.
Security, upkeep and who does the editing
WordPress is core, theme and plugins running on your server next to a database, and each of them needs patching. That's the real security cost. It isn't that WordPress is careless, it's that the surface is large and the chore never ends. A static site has no database and no server-side code to exploit, so a whole class of attacks has nothing to grab. You still harden the host and the build pipeline.
The cost on the other side is editing. With a plain static site, publishing means changing files and running a build, which suits a developer far more than someone fixing a typo before lunch. A headless CMS gives writers a proper editor while the output stays static, but it adds back some of the moving parts you went static to avoid. If several non-technical people publish every week, plan around that mismatch before any benchmark.
So the rule is short. Go static when content changes on a schedule and whoever keeps the site running is comfortable with a build step. Choose WordPress when people who don't write code need to publish often, or when you depend on a plugin for a shop or memberships. Either way, put a full-page cache in front of WordPress and check what it's doing: the HTTP headers checker shows the cache headers your server sends back.
Frequently asked questions
Is a static site always faster than WordPress?
At the server, a file that already exists is the floor, and nothing beats it. Behind a full-page cache, though, WordPress on this site answers in 8 to 20 ms, and that gap is small next to what a heavy theme, extra scripts and unoptimised images add. A bloated static page loses to a lean cached WordPress page.
Is WordPress insecure?
Not on its own. It has a far bigger attack surface: the core and the theme are code running on your server, and so is every plugin, and all of it needs patching. A static site has no database and no server-side code to exploit. You can secure WordPress well, but it's ongoing work.
Can non-technical people edit a static site?
Only with help. Editing means changing files and running a build, which suits a developer more than a marketing team that wants to fix a typo at 5pm. A headless CMS gives writers a proper editor that still outputs static pages, but it adds back some of the complexity you left WordPress to escape.
What breaks a WordPress page cache?
Logged-in sessions, POST requests, URLs with a query string, and the admin and API paths are skipped by design. A flush after a plugin or theme update empties it too, so the next visits are slow until it refills. Look at the response headers of a normal page to see whether you're getting a hit or a miss.
Updated 7 October 2026. This article was rewritten around measurements taken on this site. An earlier version quoted GTmetrix reports that can't be reproduced, so they were removed.
