A few months ago, a regional e-commerce company reached out with a problem we hear constantly... their WordPress site was slow, their mobile conversion rate was tanking, and they were pretty sure the two things were connected.
They were right. Their product pages took over 5 seconds to load on mobile. Every second of delay was costing them real revenue. We migrated them to a headless CMS with a Next.js frontend, and eight weeks later their pages loaded in under 2.5 seconds. Conversions went up 18%.
Here's exactly what we did.
This client sold specialty outdoor gear through a catalog of about 800 products spread across 2,000 pages... product listings, category pages, a blog, and a handful of landing pages for seasonal campaigns. Their WordPress instance had been running for six years and had accumulated the usual cruft.
The numbers told the story:
We see this pattern constantly. The site starts fast, plugins accumulate, custom code gets layered on by multiple agencies, and eventually the WordPress instance is doing so much work per request that no amount of caching can save it.
Google's own research shows that as page load time increases from 1 to 5 seconds, the probability of bounce increases by 90%. For an e-commerce site, that's money walking out the door.
We always start with the honest question: can we fix this without a migration?
Sometimes the answer is yes. Better hosting, a proper CDN, plugin cleanup, and image optimization can buy you significant gains on WordPress. We've done that for clients and saved them the cost of a full rebuild.
This wasn't one of those cases. Three things pushed us toward headless:
We moved them to a decoupled architecture with three clean layers:
| Layer | Before | After |
|---|---|---|
| CMS | WordPress + WooCommerce + 38 plugins | Headless CMS with structured product content models |
| Frontend | Monolithic PHP theme (1.2MB JS bundle) | Next.js with SSG, ISR, and per-route code splitting |
| Hosting | Shared hosting, no CDN | Edge deployment with global CDN |
| Images | Full-size JPEGs, no lazy loading | Automatic WebP/AVIF, responsive srcsets, blur-up placeholders |
| Commerce | WooCommerce (tightly coupled) | Headless commerce API layer (decoupled cart and checkout) |
We built an automated migration pipeline that pulled content from the WordPress REST API, transformed it into structured content types, and imported it into the new CMS. Our AI-assisted transformation handled the messy parts... shortcodes, custom HTML blocks, WooCommerce product metadata, and variant configurations.
Out of 2,000 pages, 142 (about 7%) got flagged for manual review. Most of these were product pages with complex variant tables or legacy shortcodes that didn't map cleanly to structured fields. The manual review pass took two days.
The entire content migration... export, transform, import, review... took five days.
The performance gains came from a handful of deliberate architectural choices:
font-display: swap. New total: 52KB.One piece that's unique to e-commerce migrations: you can't just decouple the CMS and call it done. Cart, checkout, and inventory management all need to work through APIs.
We built a thin API layer that handles cart operations, inventory checks, and checkout... all client-side. The product catalog is static HTML on a CDN, but add-to-cart and checkout are dynamic API calls. This gives you the best of both worlds: instant page loads for browsing, real-time accuracy for purchasing.
We measured everything two weeks after launch, once traffic patterns stabilized and CDN caches were warm:
| Metric | Before | After | Change |
|---|---|---|---|
| Mobile page load | 5.3s | 2.4s | -55% |
| Desktop page load | 3.6s | 1.4s | -61% |
| Largest Contentful Paint | 4.9s | 1.9s | -61% |
| Time to First Byte | 1.8s | 0.065s | -96% |
| PageSpeed score (mobile) | 29 | 94 | +224% |
| JavaScript payload | 1.2MB | 180KB | -85% |
| Average page weight | 3.8MB | 1.1MB | -71% |
| Mobile bounce rate | 62% | 44% | -29% |
| Mobile conversion rate | 1.8% | 2.1% | +18% |
The TTFB improvement is the one that matters most architecturally. Going from 1.8 seconds to 65 milliseconds means the page is already built and sitting on an edge server near the user. No database queries, no PHP rendering, no plugin chain... just HTML served from a CDN.
The conversion rate improvement is the one that matters most to the business. That 18% lift translates directly to revenue. Cloudflare's research on performance and conversion rates consistently shows that faster sites convert better; our results tracked with their benchmarks almost exactly.
Performance is the headline, but the editorial experience improvement is what made the client's day-to-day life better:
I'd be lying if I said everything went perfectly. A few things bit us:
Total project timeline: 8 weeks. Honest estimate if we'd scoped the integrations correctly from the start: 7 weeks.
This migration made sense because the client had real performance problems that were costing them money, a content team that was fighting their tools, and enough traffic that the conversion rate improvement would pay for the project within months.
But headless isn't always the answer. If your WordPress site loads in under 3 seconds, your content team is happy, and your plugin stack is manageable... you probably don't need a migration. Better hosting, a CDN, and some image optimization might get you 80% of the performance benefit at 20% of the cost.
The question isn't "is headless better?" It's "is headless better enough to justify the investment for your specific situation?"
If you're not sure, we'll do a quick performance audit and give you an honest recommendation. Sometimes that recommendation is "stay on WordPress and fix these three things." We'd rather tell you that upfront than sell you a migration you don't need.
Get in touch and we'll take a look at your setup.