Static hosting vs managed WordPress: when each actually makes sense

Every so often someone measures a static site, sees a 60ms response time, compares it to the 150ms their WordPress host manages, and concludes they have been robbed.

The 60ms is real. The conclusion is not, because the two numbers are not measuring the same activity. This is worth understanding properly, because it decides whether you should be shopping for a faster host or changing how your site is built.

When a request hits a static host, the response already exists. A file is read and sent. There is no application to boot, no database to query, no template to assemble.

When a request hits a WordPress host and the page is not cached, PHP starts, WordPress loads, plugins initialise, the database is queried several times, a template renders, and only then does a response begin.

Which is precisely why comparing the two on TTFB produces nonsense. Add a full-page cache to WordPress and it also serves a pre-built file, and most of the difference disappears — on the pages that can be cached.

Here is a demonstration, run from one location on one afternoon:

Site	Measured TTFB	What it runs on
A static site behind a CDN	64–74ms	Cloudflare Pages
cloudways.com	48ms	Cloudways’ own marketing stack
kinsta.com	118ms	Kinsta’s own marketing stack

By that method the static site loses to Cloudways and beats Kinsta — which tells you nothing whatsoever about either company’s hosting, because every one of those numbers is mostly a measure of how far the nearest CDN edge was from the machine doing the testing.

This is the same caveat that runs through our methodology: a figure collected at the edge describes delivery, not the server. If you want to know which bottleneck you have, the cached-versus-uncached test is the one that answers it.

Static hosting removes the server from the request path. Everything that needed the server now needs somewhere else to live.

• Forms. No PHP means no form handler. Netlify includes form handling; on Cloudflare Pages you write a Worker; or you use a third-party endpoint. All fine, all extra setup.
• Comments. A third-party service, or nothing.
• Search. No database to query. Either a client-side index for small sites, or a hosted search service.
• Accounts, carts, checkout. These fundamentally need a server. A static front end can talk to one, but you have not avoided the problem, only moved it.
• Editing. Someone non-technical updating content needs a CMS layer on top. This is the requirement that most often ends the conversation.
• A build step. Every change means a rebuild and redeploy. Usually automatic from Git, but it is a workflow, not a “log in and edit” experience.

• Documentation, marketing sites, portfolios, changelogs — content that is published rather than transacted
• A developer or agency maintains it, and Git is already part of the workflow
• Traffic is spiky and you want delivery to absorb it without a resize
• The budget is genuinely zero and the free tier comfortably covers you

• You sell things: WooCommerce, memberships, bookings, anything with a logged-in state
• Non-technical people publish content and expect an editor, not a pull request
• You depend on the plugin ecosystem — SEO, forms, CRM integrations, page builders
• You want one supplier to call when it breaks, rather than five services to reconcile

For that second category, the speed rankings compare eight managed hosts on origin response time, and the comparisons work through the trade-offs between specific pairs.

You do not have to pick a side.

Static WordPress. Plugins such as Simply Static or WP2Static generate a static copy of a WordPress site and publish it to a static host. You keep the WordPress editor; visitors get files. Dynamic features still need separate handling.

Headless WordPress. WordPress runs somewhere as a content API, and a separate front end consumes it. Powerful, and considerably more moving parts — this is a development project, not a hosting choice.

Cached WordPress, done properly. Often the honest answer. A well-configured page cache plus a CDN gets a content site most of the way to static performance without changing anything about how it is built or edited.

Two reasons, both about keeping the comparison meaningful.

They cannot run the workload the table measures. Every provider in the rankings runs PHP and a database. Cloudflare Pages, Netlify and Vercel do not. Placing them in the same list would produce a “fastest host” that cannot host most readers’ sites.

The numbers would not be comparable. As the table above shows, measuring a static site at a CDN edge and a WordPress origin without a CDN produces two figures that look like a ranking and are not one. Our table ranks on US origin TTFB precisely to keep the CDN variable out — see CDN or a faster server? for why that distinction matters so much.

Static hosting is faster because it is doing less work, not because the servers are better. If your site is content, that is a real and free advantage worth taking. If your site does anything at request time, you will rebuild that capability out of other services — and for most people running a business on WordPress, a well-cached managed host is the less expensive answer once the assembly time is counted.

Unsure which category your problem falls into? Start with is it your host or your site? — the answer is often neither the host nor the platform, but the four megabytes of images on the homepage.