Headless Commerce: When It Makes Sense, and When It's an Expensive Mistake

"Should we go headless?" is now a standard question in e-commerce replatforming conversations, usually asked after reading a case study about a brand that tripled its speed score. The honest answer, for most stores, is no — and for some, it is the best decision they will make this decade. The difference is not taste. It is a handful of measurable facts about your business.

What headless actually means

In a conventional store, the platform does everything: Shopify or WooCommerce stores the products, runs the cart and checkout, and renders the pages visitors see through a theme. In a headless architecture, the platform keeps the first two jobs and gives up the third. A separate front-end application — typically built with Next.js, Remix, Nuxt or Hydrogen — fetches products and prices through APIs and renders the storefront itself, hosted wherever you like.

That split is the whole story. Everything good about headless comes from owning the rendering layer. Everything bad about it comes from owning the rendering layer.

What you gain

• Total control over the front end. No theme constraints, no Liquid, no app-injected scripts you cannot remove. If you can build it in a web framework, you can ship it.
• Performance ceiling. With server rendering, edge caching and a disciplined bundle, headless storefronts can be extremely fast — sub-second product pages are achievable.
• One front end, many back ends. Commerce from Shopify, content from a headless CMS, reviews from a third service, search from another — composed in one experience.
• Multi-channel from one codebase. The same components can serve web, a native app shell, kiosks or embedded storefronts.
• Independence from platform release cycles. You are not waiting for a theme update or an app vendor to fix your layout.

What you give up

• Everything the theme layer did for free. Discount display logic, cart drawers, product option handling, localisation, currency switching, accessibility defaults, structured data — each has to be rebuilt and maintained.
• Most apps. A large share of the Shopify and WooCommerce app ecosystems work by injecting into the theme. Headless, they either offer an API you integrate yourself or they do not work at all.
• Simplicity of operation. Two codebases, two deployment pipelines, two places a bug can live. Marketing cannot change a landing page in the theme editor any more; it goes through engineering, or through a CMS you also now maintain.
• Checkout, sometimes. On Shopify, checkout stays on Shopify's domain unless you are on Plus and build extensions. The hand-off between your front end and their checkout is a common source of friction and lost analytics.
• Money. Builds cost several times an equivalent theme project. Running costs include front-end hosting, a team who can maintain a modern JavaScript application, and the drift between platform and front end that never quite stops.

The performance myth

The case for headless is usually made with speed, so it is worth being precise. Headless raises the ceiling on performance; it does not raise the floor. A poorly built headless storefront that ships a 900 KB JavaScript bundle and hydrates the entire page before responding to a tap will fail Interaction to Next Paint just as badly as an app-bloated theme — we have measured both. Meanwhile a Shopify 2.0 theme with a lean app stack, correctly sized images and deferred third-party scripts passes Core Web Vitals comfortably on a mid-range phone.

If speed is the problem, the first question is not "headless or not?" but "what is actually slow?" Most stores get to "good" through optimisation of the store they have for a fraction of a replatform. The maths on what speed is worth is in our article on speed and conversion rate.

The decision framework

Headless makes sense when several of these are true. One is rarely enough.

1. Revenue justifies an engineering team. As a rough threshold, stores under a few million a year in online revenue struggle to fund the build and the ongoing maintenance. Above that, the front end becomes a product with its own roadmap, and the economics change.
2. Content is as important as catalogue. Editorial commerce, brands with heavy storytelling, publishers who sell — where a headless CMS and a commerce engine genuinely need to be composed on the same page.
3. You have hit the theme's ceiling. Not "the theme is a bit slow" but specific, revenue-relevant experiences the platform's rendering layer cannot deliver — configurators, complex B2B pricing displays, real-time inventory across channels.
4. Multiple channels share the storefront. Web plus app plus in-store plus marketplace embeds, where one component library across all of them saves more than it costs.
5. You already have — or will hire — the team. Front-end engineers who ship and maintain a production JavaScript application, with on-call for when the API changes. A freelancer and a Fiverr budget is not that team.
6. International complexity. Many markets, currencies, languages and tax regimes where the platform's native handling is not sufficient and a custom layer earns its keep.

If none of those apply and the motivation is a speed score or a competitor's case study, headless is an expensive way to rebuild features you already had.

The middle paths

The choice is not binary.

• A properly built theme. Shopify 2.0 or a WooCommerce block theme, app stack audited to the essentials, images through a real pipeline, third parties deferred. Most stores should be here.
• Hybrid. Keep the theme for the catalogue and checkout; build specific high-value pages — the homepage, a configurator, a campaign landing page — as separate fast front ends. You get the ceiling where it matters without rebuilding the cart.
• Shopify Hydrogen on Oxygen. Headless with a framework and hosting designed for it, which removes some (not all) of the operational burden. Still an engineering product.

If you do go headless

• Write the performance budget into the project before choosing a framework, and test on a throttled mid-range device from the first sprint. The architecture will not save you from a heavy bundle.
• Inventory every app and theme feature you currently use, and decide explicitly which are rebuilt, replaced or dropped. The surprises live here.
• Plan the checkout hand-off and its analytics before launch, not after the first month of missing conversion data.
• Budget for the second year, not just the build. A headless storefront is never finished.
• Protect your rankings through the migration as you would in any redesign: URL parity, redirects, content parity, structured data carried over.

Headless is a decision about who owns the storefront's rendering layer. Own it when the business needs what only ownership can deliver and can fund the team to keep it. Otherwise, buy the best theme you can and spend the difference on the things that actually move revenue.

We build both — themes engineered to pass Core Web Vitals and headless front ends where the framework above says they are justified — and we say which one you need before quoting either. That is what the e-commerce service page describes, and the advice is the same on a call.