Insights
Headless WordPress with Next.js: when is it worth it?
I get this question regularly from agencies: our client wants a faster, more modern site, should we move off WordPress? Usually not. But there are a few situations where headless WordPress with a Next.js frontend gives a demonstrably better result than the classic theme-based model. Here's the tradeoff as I actually make it in practice.
What headless actually means
In a headless setup, WordPress remains the place where editors enter content — through the familiar admin panel, with the same ACF fields as always — but the site visitors see is no longer rendered by a WordPress theme. Instead, a standalone Next.js application fetches the content via the WordPress REST API or WPGraphQL, and renders it itself, server-side.
The CMS and the frontend become two separate applications that talk to each other via an API, instead of one fused whole.
When it's worth it
The gain is biggest for content-heavy, high-traffic sites where load time directly impacts conversion: comparison sites, marketplaces, sites with heavy organic search traffic where every 100ms matters. It's also logical when you want to show the same WordPress content across multiple platforms (website, app, internal tools), since the content is then already available as an API.
A third situation: you already have a strong Next.js team or codebase (for example an existing platform) and want to use WordPress purely as a content source, without building the entire platform inside WordPress itself.
When you're better off staying with WordPress
For most marketing sites, brochure websites and even most webshops, classic WordPress with custom ACF blocks (no page builder) is simply the more pragmatic choice. With headless you lose the built-in previews, the WYSIWYG experience for editors, and part of the plugin ecosystem (SEO plugins, form builders) that assumes a classically rendered theme.
Headless also effectively doubles the number of systems that need maintaining: a WordPress backend and a Next.js frontend, each with their own deploys, dependencies and security updates. That extra complexity needs to be earned back through speed or flexibility you actually need.
A middle ground: well-optimized classic WordPress
Before opting for headless, it's worth checking whether the speed problem is actually caused by a page builder (Elementor, WPBakery) rather than WordPress itself. Custom ACF blocks with semantic HTML and good caching often already capture 80% of headless's performance gain, without the extra system complexity.
Frequently asked questions
Good Questions
Setting expectations before we start, with a real process and honest answers.
Yes. I often start with the pages that carry the most traffic or conversion risk, and migrate the rest in phases, so editors keep using the same admin panel throughout.
That depends heavily on the number of templates and custom functionality, but expect an investment comparable to a full custom rebuild — headless isn't a small addition, it's a new frontend.
Contact
Say Hello
Got a project in mind? Tell me a bit about it and I'll get back to you within a day.