When to go headless on Adobe Commerce

Most merchants who ask me about headless want to know why the store is slow and why every frontend change takes three weeks. Headless can fix both. So can a well-built theme. The difference is cost, and who pays it for the next five years.

I have maintained a ScandiPWA headless storefront in production for a merchant with 8-figure GMV, and I work with Hyvä and PWA Studio. Both work, and neither is the right default for everyone.

What headless means on Adobe Commerce

In a classic setup, Adobe Commerce renders every page in PHP from layout XML, blocks and templates. In a headless setup, Adobe Commerce becomes the backend only. A separate application renders the storefront and talks to Commerce through GraphQL or REST.

That separate application can be:

• PWA Studio. Adobe’s React toolkit for building a storefront on Commerce GraphQL.
• ScandiPWA. A React storefront maintained by a Magento agency, also on GraphQL.
• Adobe’s Edge Delivery Services storefront. Commerce blocks and drop-in components, which Adobe now promotes for new storefronts. Check the licensing first, because the drop-ins need a Commerce license that covers them.
• A custom frontend in Next.js, Nuxt or similar, written by your team against the same APIs.

All of them move rendering out of Magento. All of them leave you with two applications to build, deploy, monitor and upgrade instead of one.

What Hyvä changed

For years the real argument for headless was that Luma, the default theme, is slow and painful to work on. It loads RequireJS, Knockout and a heavy JavaScript payload on every page, and headless was the way out.

Hyvä removed most of that argument. It replaces the Luma frontend with Alpine.js and Tailwind CSS while keeping server-side rendering inside Magento. Pages get lighter and frontend work gets faster. Backend features, extensions and admin settings keep working the way the business already knows them. Since November 2025 the Hyvä Theme itself is free and open source under OSL 3.0 and AFL 3.0; Hyvä Checkout and the enterprise products remain commercial.

So today the comparison worth making is headless against Hyvä.

When headless is worth it

I recommend a separate storefront when at least two of these are true:

1. Commerce is one of several backends. The storefront also reads from a CMS, a PIM, a booking engine or a content platform, and Magento should not be the place where they meet.
2. You need more than one frontend. A web store plus a native app, kiosks or a marketplace channel that all use the same cart and catalog APIs.
3. The storefront is highly interactive. Product configurators, heavy client-side interaction or personalized content would fight a server-rendered theme.
4. You have a frontend team. In-house JavaScript engineers who will own the storefront long term. An agency that hands it over at launch does not count.
5. The budget covers two applications. Build cost, and also the running cost of two codebases, two deploy pipelines and two sets of monitoring, every year.

Point 4 matters most. A headless storefront without a team that owns it ages badly. Framework upgrades pile up, the GraphQL schema drifts, and the store ends up frozen on old versions because nobody can afford the upgrade.

When it is not

Stay with a server-rendered theme, in practice Hyvä, when:

• You depend on many frontend extensions. Every third-party module that touches the frontend needs a headless equivalent. Payment methods, reviews, loyalty, B2B quick order: each one is a small integration project, and some vendors have no GraphQL coverage at all.
• Your team is PHP-first. Hyvä keeps Magento developers productive. A React storefront turns them into dependants of whoever writes the JavaScript.
• The goal is speed. If the brief is “faster pages and better Core Web Vitals”, Hyvä plus the backend work in my performance checklist gets you there for a fraction of the cost.
• Merchandisers rely on the admin. Page Builder, widgets, CMS blocks and layout updates work natively with a Magento theme. In a headless storefront, each of them needs explicit support or a replacement.

The costs people underestimate

Area	Hyvä theme	Headless storefront
Applications to run	One	Two, plus API caching
Third-party modules	Hyvä compatibility module, often available	Rebuilt or integrated per module
Admin content tools	Native	Partial, needs work per feature
Upgrades	Magento upgrade	Magento upgrade plus frontend framework upgrade
Skills needed	Magento, Tailwind, Alpine.js	Magento, GraphQL, React or similar, Node hosting

Three items surprise teams most often.

GraphQL performance is the first. Full-page cache does not protect GraphQL the way it protects a themed store. Uncached GraphQL queries with deep product data hit PHP on every request. Query design, caching at the edge and resolver profiling have to be part of the build from the first sprint.

Checkout is next. It is the most customized part of any store and the most expensive part to rebuild. Payment providers, tax, shipping rules and fraud checks all have to work through the API.

Then there is SEO parity. URL rewrites, canonical tags, structured data, hreflang and redirects all lived in Magento. In headless, the storefront has to reproduce every one of them, or traffic drops after launch.

A decision in four questions

When a merchant asks me whether to go headless, I ask these, in this order:

1. What problem are you solving? If the answer is speed or developer productivity, start with Hyvä and stop here.
2. Who will own the storefront in three years? No named team means no headless.
3. How many frontend-facing extensions do you run? List them. Check API support for each. This list is often the end of the discussion.
4. Do you have a channel or data source that Magento should not render? If yes, headless starts to pay for itself.

A useful middle path is a hybrid. Hyvä serves catalog and checkout. A separate application, calling the same Commerce APIs, handles only the part of the site that needs it, such as a configurator or a content hub.

What I would do

For most mid-size Adobe Commerce stores in 2026, I recommend Hyvä plus the backend fixes from my performance checklist. It delivers most of the speed of headless at much lower long-term cost. I recommend headless for merchants with several channels, several data sources and a frontend team that will stay. When that is the case, I would rather you build it properly than half-way.

If you are weighing this decision now, my storefront strategy service starts with a two-week assessment that answers the four questions above for your store, in writing.