WordPress’s editor is still the best publishing experience out there. Its frontend — running plugins and themes on every request — is the part that gets slow, breaks, and needs constant patching. Here’s the headless setup we build instead: same editor, fast JavaScript frontend.
WordPress powers a huge share of the web for a good reason: nothing else makes publishing as easy for non-technical teams. The block editor, revision history, media library and role management represent two decades of hard-won product work. We are not interested in taking that away from anybody.
The problem is not the editor. It is what happens on every single request to the public site.
What actually makes WordPress slow
A conventional WordPress page load boots PHP, loads the active theme, initialises every active plugin, runs a series of database queries, applies dozens of filters, and assembles HTML — per request, per visitor. Caching plugins hide this, until a logged-in user, a cart, or a personalised element punches through the cache.
Add the typical plugin stack — a page builder, an SEO plugin, forms, analytics, a slider, a security scanner — and you are shipping several hundred kilobytes of CSS and JavaScript that no visitor asked for.
The headless split
Headless WordPress keeps WordPress as the content management system and replaces the public frontend with a separate application that reads content over the REST or GraphQL API and renders it as static or edge-rendered pages.
- Editors keep the exact interface they already know. Nothing changes in their workflow.
- The public site ships only the CSS and JavaScript you wrote, typically an order of magnitude less.
- Plugin vulnerabilities stop being publicly reachable, because the WordPress instance is not the public surface.
- Rebuilds happen on publish, so visitors are never waiting on PHP.
What we build
For content-heavy marketing sites we use Astro, which ships zero JavaScript by default and lets us add interactivity only where it earns its weight. For applications with genuinely dynamic per-user views we use Next.js. Content stays in WordPress; a webhook on publish triggers an incremental rebuild; the frontend deploys to a CDN edge.
Typical field results across our migrations: Largest Contentful Paint from roughly 4–6 seconds down to 1–1.7 seconds, total JavaScript from 400–900KB down to under 60KB, and Core Web Vitals moving from failing to passing on real-user data rather than lab scores.
When not to do this
Headless is not free. You are running two systems, your build pipeline becomes production infrastructure, and previewing drafts requires deliberate engineering. If your site is small, your traffic is modest and a good cache is holding, a well-built conventional theme is the cheaper correct answer. We say so regularly, and it costs us work.
The case for headless gets strong when you have thousands of pages, a content team publishing daily, real performance requirements tied to revenue, or a plugin stack that has become a security liability.