A mid-market publisher came to us with a familiar problem: their WordPress site was slow, and it was costing them money. Pages took 4-6 seconds to load on mobile. Bounce rates were climbing. Their editorial team was fighting a bloated admin panel with 47 plugins, and every update felt like defusing a bomb.

Six weeks later, their site loaded in under 2 seconds. Here's what we did and why it worked.

The Starting Point

The client ran a content-heavy site — roughly 1,200 published pages across news articles, evergreen guides, landing pages, and a product catalog. Their WordPress instance had been running for eight years, accumulating technical debt the way old houses accumulate coats of paint.

The symptoms were obvious:

• Average page load: 4.8 seconds on mobile (3G throttled), 3.1 seconds on desktop
• Largest Contentful Paint (LCP): 5.2s — well outside Google's "good" threshold of 2.5s
• 47 active plugins, several conflicting with each other
• Monolithic PHP theme that had been patched by three different agencies over the years
• No CDN — every request hit the origin server in Virginia
• Unoptimized images — full-resolution PNGs served to mobile devices

Their Google PageSpeed score hovered around 35 on mobile. Core Web Vitals were failing across the board. They were watching competitors with faster sites climb past them in search rankings.

Why Headless — and Why Not Just Fix WordPress

The first question we always ask: does this actually need a migration, or can we fix what's there?

We spent two days auditing the existing setup. The conclusion: patching WordPress would buy them incremental gains, but the architecture itself was the bottleneck. Every page request triggered a full server-side render through a chain of PHP templates, database queries, and plugin hooks. Caching helped, but cache invalidation was unreliable — editors would publish a change and wait 20 minutes to see it live.

The case for going headless came down to three things:

1. Static generation for content pages. 90% of their pages changed less than once a week. Serving pre-built HTML from a CDN edge node is fundamentally faster than rendering PHP on every request.
2. Editorial flexibility. Their content team needed structured content — reusable blocks, flexible layouts, real-time preview. WordPress's block editor was close but kept breaking when plugins updated.
3. Image pipeline. A headless setup let us implement automatic image optimization with responsive srcsets, WebP conversion, and lazy loading — things that are possible in WordPress but painful to retrofit reliably.

The Architecture We Built

We moved them to a three-layer stack:

Layer	Before	After
CMS	WordPress (monolithic)	Headless CMS with structured content models
Frontend	PHP theme (server-rendered)	Next.js with static generation + ISR
Hosting	Single VPS, no CDN	Edge-deployed with global CDN
Images	Unoptimized uploads	Automatic WebP, responsive srcsets, lazy loading

Content Migration

We exported all 1,200 pages from WordPress using the REST API and WP-CLI. Our AI-assisted migration pipeline handled the content transformation — mapping WordPress blocks and custom fields to structured content types in the new CMS. The pipeline flagged 68 pages (about 5.7%) that needed manual review, mostly due to complex shortcode usage or custom HTML that didn't map cleanly to structured blocks.

Total migration time: 4 days, including the manual review pass.

Frontend Build

The Next.js frontend used static site generation (SSG) for all content pages, with incremental static regeneration (ISR) so editors could publish changes and see them live within 60 seconds — without triggering a full rebuild.

Key performance decisions:

• Component-level code splitting — only ship the JavaScript needed for each page
• Image component with built-in optimization — automatic format negotiation, responsive sizes, blur-up placeholders
• Font subsetting — reduced custom font payload from 340KB to 45KB
• Zero render-blocking CSS — critical CSS inlined, everything else deferred

Infrastructure

Pages deploy to edge nodes worldwide. A reader in Tokyo gets served from Tokyo. A reader in London gets served from London. The old setup routed every request through a single server in Virginia regardless of where the reader was.

The Results

We measured performance two weeks after launch, once traffic patterns had normalized:

Metric	Before	After	Change
Mobile page load	4.8s	1.9s	-60%
Desktop page load	3.1s	1.2s	-61%
Largest Contentful Paint	5.2s	1.8s	-65%
PageSpeed score (mobile)	35	92	+163%
Time to First Byte	1.4s	0.08s	-94%
Bounce rate	58%	41%	-29%

The Time to First Byte improvement tells the real story. Going from 1.4 seconds to 80 milliseconds means the server response is essentially instant — the page is already built and sitting on a CDN edge node waiting to be served.

What the Editorial Team Got

Performance wasn't the only win. The content team's workflow improved significantly:

• Real-time preview — editors see exactly how their content will look on the live site while they're writing, not after they publish
• Structured content — no more wrestling with the WordPress block editor for complex layouts. Content types have defined fields, validation, and relationships
• No more plugin anxiety — the old WordPress setup required coordinating plugin updates across 47 dependencies. The new CMS has zero plugins to manage
• Faster publishing — changes go live in under 60 seconds via ISR, compared to the old 20-minute cache invalidation cycle

What We'd Do Differently

No project is perfect. A few things we'd adjust next time:

• Start the redirect map earlier. We underestimated how many WordPress URLs had been indexed by Google. Building the redirect map should have started in week one, not week three.
• More editorial training upfront. We scheduled training sessions after launch. Should have done them before. The content team's first week on the new system was rougher than it needed to be.
• Test with real analytics data. We optimized for average pages, but their top 20 landing pages had unique layouts that needed extra attention. Prioritizing by traffic would have been smarter.

Is This Right for You?

A headless migration makes sense when your content is relatively structured, your WordPress instance is fighting you on performance or editorial experience, and you have the budget for a proper rebuild — not just a reskin.

It does not make sense if WordPress is working fine for your team, your performance issues can be solved with better hosting and a CDN, or your site is small enough that the migration overhead exceeds the benefit.

If you're on the fence, we're happy to do a quick audit and give you an honest recommendation — even if that recommendation is "stay on WordPress."

Get in touch and we'll take a look.