When to go headless on Adobe Commerce

Most merchants who ask me about headless are really asking a different question: why is my store slow, and why does every frontend change take three weeks? Headless can answer 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. Neither is the right default for everyone.

What headless means on Adobe Commerce

In a classic setup, Adobe Commerce renders every page in PHP: layout XML, blocks, 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: 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. RequireJS, Knockout and a heavy JavaScript payload on every page. Headless was the escape.

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 light, frontend work gets fast, and every backend feature, extension and admin setting keeps working the way the business already knows. 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 the honest comparison today is not “headless versus slow Luma”. It is “headless versus 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 experience is the product. Heavy interactivity, configurators, personalized content that a server-rendered theme would fight against.
4. You have a frontend team. In-house JavaScript engineers who will own the storefront long term, not an agency that hands it over at launch.
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:

• Your extensions are your business. 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. Your developers know Magento. Hyvä keeps them 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. Full-page cache does not protect you the way it does on a themed store. Uncached GraphQL queries with deep product data hit PHP on every request. You need query design, caching at the edge and resolver profiling from day one.

Checkout. 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.

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ä for catalog and checkout, and a separate application only for the part of the site that needs it, such as a configurator or a content hub, calling the same Commerce APIs.

What I would do

For most mid-size Adobe Commerce stores in 2026, I recommend Hyvä with solid backend performance work. 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, the headless storefronts service starts with a two-week assessment that answers the four questions above for your store, in writing.