Traditional WordPress works like this: a visitor requests a page, WordPress queries the database, PHP assembles the HTML, and the server sends it back. Every request. Every time.
Headless WordPress changes the model entirely.
How Headless WordPress Works
In a headless setup, WordPress becomes a pure content API — a data layer that stores and serves content but has no responsibility for how it is displayed.
A separate front-end application (typically Next.js) calls the WordPress REST API or GraphQL endpoint, fetches the content, and renders it.
`
Traditional WordPress:
Browser → WordPress (PHP) → Database → HTML → Browser
Headless WordPress:
Browser → CDN (pre-built HTML) ← Next.js build ← WP API ← DB
↑
Editor updates content here only
`
The key difference: with headless and static generation, pages are pre-built at deploy time and served directly from a CDN. There is no server processing on each request.
The Performance Reality
`
Performance Comparison — Same Content, Different Architecture
────────────────────────────────────────────────────────
Metric Traditional WP Headless (Next.js)
────────────────────────────────────────────────────────
TTFB 400–1,200ms 20–80ms
Fully loaded 2.5–6.0s 0.5–1.2s
PageSpeed Mobile 55–75 90–99
Server cost/req PHP + DB query £0 (CDN cache)
Concurrent users Limited by PHP Virtually unlimited
────────────────────────────────────────────────────────
`
The performance gap is not marginal. For high-traffic sites, the cost difference alone (CDN serving static files vs PHP server load) can justify the architecture switch.
What You Keep With Headless
This is the appeal. You do not throw away WordPress — you keep everything that makes it good:
- Gutenberg editor — your content team works exactly as before
- All your plugins — ACF, Yoast, WooCommerce, everything works
- Your existing content — no migration required
- User roles and permissions — unchanged
- Media library — WordPress still handles uploads
The WordPress admin becomes the content management interface. Editors never see the front-end architecture change.
What Changes (The Trade-offs)
1. Build and Deploy Time
Static generation means every page must be built before it can be served. A site with 10,000 pages can take 5–15 minutes to build.
Solutions:
- Incremental Static Regeneration (ISR) in Next.js — only rebuild changed pages
- On-demand revalidation — WordPress triggers a rebuild of only the affected page on publish
2. Real-Time Previews
Content editors accustomed to WordPress previews will find them slower — the preview has to call the Next.js preview endpoint, which is fast but adds a step.
3. WooCommerce Complexity
Headless WooCommerce requires the WooCommerce Blocks REST API or a GraphQL layer. Cart and checkout state management is non-trivial. Most e-commerce clients are better served by traditional WooCommerce unless they have a compelling performance requirement.
4. Higher Development Cost
Building headless requires Next.js (or similar) expertise in addition to WordPress knowledge. Development takes longer upfront.
`
Development Cost Comparison
────────────────────────────────────────────────────────
Approach Relative Dev Time
────────────────────────────────────────────────────────
Traditional WordPress 1x (baseline)
WordPress + optimisation 1.2x
Headless (Next.js + WP) 2x–2.8x
────────────────────────────────────────────────────────
`
When Headless Makes Sense
Choose headless when:
- Your site has high traffic and server costs are material
- Performance is a competitive differentiator (e.g. media, SaaS, fintech)
- You have multiple front-ends consuming the same content (web, app, kiosk)
- Security is paramount — no public-facing PHP reduces attack surface
- You have Next.js development capacity in house or with your agency
Stick with traditional WordPress when:
- Content editors need instant previews and zero deployment delay
- Your site is primarily WooCommerce with complex cart logic
- Budget is constrained and you need to ship quickly
- Your team has no JavaScript framework experience
- Traffic levels do not justify the added infrastructure cost
The Hybrid Option
For many businesses, Partially Headless is the pragmatic middle ground:
- Marketing pages (homepage, services, blog) → headless Next.js (full performance)
- WooCommerce store → traditional WordPress (easier, more plugin support)
- Both share the same WordPress admin
This captures most of the performance benefit for the pages that matter most to SEO and first impressions, while keeping WooCommerce on solid ground.
Our Recommended Stack
`
Orravo Headless WordPress Stack
────────────────────────────────────────────────────────
CMS: WordPress + Gutenberg + ACF Pro
API Layer: WPGraphQL (faster + typed vs REST)
Front-end: Next.js 15 (App Router, RSC)
Hosting: Vercel (front-end) + Kinsta (WordPress)
CMS preview: next-sanity preview mode adapted for WP
Search: Algolia or Typesense (not WP Search)
Forms: React Hook Form → WP REST endpoint
Image CDN: Vercel's built-in image optimisation
────────────────────────────────────────────────────────
`
This stack delivers PageSpeed Mobile scores of 92–98 consistently, while maintaining the familiar WordPress editing experience that content teams already know.