Headless vs Monolith Magento. When Is Hyvä Enough?
21.08.2026
Headless Magento promises speed and flexibility. The field data says otherwise. An honest look at when Hyvä on a monolith is the better engineering call.
Everyone wants headless. Not everybody needs it.
TL;DR: Headless Magento decouples the frontend from the backend via the API; Hyvä is a fast monolith frontend. Headless wins when the storefront has to compose numerous systems, serve multiple frontends, or run omnichannel. It does not win on performance: most headless commerce origins fail Core Web Vitals, while most Hyvä origins pass. If the goal is simply better performance, Hyvä is the simpler and faster way to get there.
Every few months a merchant comes to us convinced they need to go headless. Usually the reasoning is the same: the store is slow, headless is modern, and the current frontend feels like a liability. All three things can be true and still not add up to "go headless."
Here is the uncomfortable part. Field data from HTTP Archive shows that most headless commerce storefronts do not pass Core Web Vitals and most Hyvä stores do. Headless can absolutely be faster than a monolith. It just usually isn't, because getting there is hard engineering that many builds never fund.
This post covers what you're actually choosing between, where each architecture genuinely wins, what headless costs beyond the build, and how to tell whether Hyvä on a monolith is enough for your store.
What you're actually choosing between
Before the trade-offs, the definitions — because the word "headless" gets applied to things that aren't.
Monolith Magento (with Hyvä
In a monolith, Magento renders the storefront itself. The frontend and backend live in one application, deployed together. Hyvä Theme is a modern replacement for Magento's default Luma theme Alpine.js and Tailwind CSS instead of Knockout and RequireJS but architecturally it is still a monolith frontend. Magento renders the page; Hyvä just makes what it renders dramatically lighter.
Hyvä is not headless. This trips people up constantly, so it's worth stating plainly: a Hyvä store is a monolith store with a fast frontend.
Headless Magento
In a headless setup, the storefront is a separate application that talks to Magento over GraphQL or REST. Magento becomes a commerce backend; the frontend is yours to build and deploy independently. In practice on Magento that usually means Alokai (formerly Vue Storefront), Magento PWA Studio, or a custom Next.js or Nuxt frontend.
Two applications, two deployments, two codebases, two caching layers.
The real question
The choice is not "old vs modern." It's whether your business needs frontend/backend decoupling badly enough to pay for the complexity it brings. For a single storefront serving a normal web audience, that answer is usually no.
"All I need is better performance"
This is the reason most merchants start looking at headless, so it deserves the most honest section in the post.
Does headless Magento improve performance?
Not automatically and the field data suggests it usually doesn't. Headless raises the performance ceiling but lowers the floor: fast headless requires server-side rendering, edge caching, disciplined hydration, and a tuned image pipeline. Without that investment, a headless build ships more JavaScript and scores worse than a well-built monolith on Hyvä.
What the field data shows
HTTP Archive tracks the share of origins passing all three Core Web Vitals at the 75th percentile, segmented by technology. Comparing Hyvä against the headless commerce frontends used on Magento, the latest HTTP Archive dataset shows:
| Technology | Origins passing Core Web Vitals |
|---|---|
| Hyvä Themes | 67% |
| Vue Storefront / Alokai | 19% |
| PWA Studio | 2% |
| ScandiPWA | 1% |
[HTTP Archive Good Core Web Vitals comparison, mobile, all geos. Alt text: "Core Web Vitals pass rates for Hyvä Themes, Vue Storefront, PWA Studio and ScandiPWA in HTTP Archive, 2026"]
Those are all real commerce frontends, measured the same way, on the same dataset. Hyvä passes at more than three times the rate of the best-performing headless option in the set.
Broaden it to every site built with React millions of origins, most of them not eCommerce, many of them well-resourced marketing sites and applications with none of a storefront's rendering complexity and the pass rate is around 46%.
Why headless is harder to make fast
None of this means headless is inherently slow. It means fast headless is engineered, and fast Hyvä is close to free.
A Hyvä store inherits Magento's mature full-page cache and ships almost no JavaScript. The performance is a property of the architecture. A headless storefront has to earn the same result: render on the server or at build time, cache rendered pages at the edge, keep hydration cost down, keep the two caching layers coherent, and build an image pipeline Magento would otherwise have handled. Every one of those is a place to get it wrong, and the pass rates above are what getting it wrong looks like at scale. On our own Varus build, server-side rendering optimisation was a distinct piece of scoped work — that is the level of investment fast headless requires.
So if the problem statement is "our store is slow," headless is an expensive and higher-risk route to an outcome Hyvä delivers more reliably. The Core Web Vitals guide for Magento stores covers the work that sits alongside a frontend change.
What headless gives you that Hyvä can't
Performance is the wrong reason to go headless. There are several right ones.
Multiple frontends from one backend. A web storefront, a native app, in-store self-service screens, a marketplace integration — all reading the same catalogue, cart, and pricing from one Magento instance. A monolith can serve APIs, but it can't give each channel an independently owned and deployed frontend.
Independence from the backend. This is the strategic one. Decouple the frontend and the commerce backend becomes replaceable: you can move off Magento without throwing away the storefront. The data layer would still need rewriting against a new platform's API, but the design system, components, routing, and everything your customers actually see survive the move. On a monolith, replatforming means rebuilding the whole store, frontend included.
Independent scaling and deployment. Frontend and backend scale on separate infrastructure and ship on separate release cycles. A frontend deploy doesn't touch the commerce backend. For teams running frequent frontend releases, this is a genuine operational win.
Freedom in the content layer. Headless makes it straightforward to pair Magento with a dedicated CMS or DXP and let editors work in a tool built for content rather than in Magento's CMS.
Extreme traffic and infrastructure control. At very high concurrency, decoupling gives you control over exactly how the storefront is rendered, cached, and distributed.
Eva.ua is our own proof that this is real. Ukraine's leading drogerie chain runs a headless PWA on Alokai handling 13,000 orders a day, 13 million monthly visitors, 130,000 SKUs, and 11,000 simultaneous users at peak — one order per second, with system load never exceeding 50% and headroom to scale five to seven times within hours. That is what headless is for.
Worth noting how they got there: Eva.ua did not start headless. We inherited a Magento store with ten-second load times, rebuilt the architecture, migrated hosting, and doubled sales on a monolith first. The headless migration came later, when national-leader scale actually demanded it.
Varus is the other reason on this list, made concrete. Ukraine's Varus grocery chain — 110 supermarkets, more than 21,900 SKUs online, over 323,000 customers a day — runs a headless PWA on Magento 2 and Vue Storefront that went live in 2022. It went headless not for speed but for the number of systems the storefront had to hold together: a PIM syncing product data every 15 minutes, SQPP pushing stock and price updates every two, a TMS driving delivery methods, time slots and polygon-based zones, roughly 5,000 promotional SKUs imported weekly, plus separate services for customer authentication and affiliate marketing. Orders grew 800% within a year and successful checkouts by 150%.
Worth noting what keeping it fast actually took: server-side rendering optimisation was its own workstream on that build, not a free consequence of going headless.
What headless costs you (that nobody puts in the pitch)
Higher build cost. Not always from scratch — the ecosystem has starting points. Alokai ships storefront starters, ScandiPWA installs as a theme, and there are ready PWA themes on the market. But a starter is a starting point, not a finished storefront: you are still building and owning a separate frontend application rather than theming one inside Magento. Routing, layered navigation, checkout, account pages, CMS rendering — things Magento handled for you — all become work to configure, extend, or rebuild against the API. How much depends entirely on how far your requirements sit from what the starter assumes.
Two codebases, two skill sets. The backend still needs Magento engineers. The frontend now needs strong Vue or React engineers who also understand commerce. Smaller teams feel this immediately.
A bigger maintenance surface. Two applications to patch, two dependency trees, two deployment pipelines, two things that can break independently, and an API contract between them that has to survive every Magento upgrade.
Longer time to market. A complex headless build can run up to a year. A Hyvä frontend rebuild is measured in months — how many depends on customisation depth and how many integrations touch the frontend.
Extension incompatibility. Magento extensions ship frontend code assuming Magento renders the page. In a headless build, most of that has to be reimplemented against the API. (Hyvä has its own version of this problem — Luma extensions break entirely on Hyvä — but the Hyvä ecosystem of compatible modules is now large, and the fix is usually a compatibility module rather than a rewrite.)
Ongoing infrastructure. Hosting, CDN, and edge rendering for a second application, indefinitely.
For grounding on how these numbers behave in a full budget, our breakdown of the true cost of a Magento / Adobe Commerce store covers the wider picture.
When Hyvä on a monolith is enough
How do I know if I need headless Magento?
Most single-storefront Magento merchants don't. If you sell through one web storefront, your performance problem is a frontend problem, and your team is Magento-centric, Hyvä on a monolith will deliver the speed you're after at a fraction of the cost and complexity of a headless rebuild — with a much higher chance of actually hitting good Core Web Vitals.
Stay on the monolith if most of this describes you:
- One storefront, or several storefronts sharing one design system
- Your channels are web and maybe a marketplace feed — no native app, no in-store screens
- The core complaint is page speed, not architecture
- Your team is Magento-centric and you don't want to hire or contract a separate frontend team
- Your content needs are met by Magento's CMS — or by Hyvä CMS, the modern editor with live preview bundled into the Hyvä Commerce suite for Magento Open Source and Mage-OS (on Adobe Commerce, Hyvä Enterprise is the equivalent tier)
- You need results this quarter, not next year
- You depend on Magento extensions you'd rather not reimplement Grasscity is the reference point here. A global multi-store operation across the Netherlands, UK, and US, serving millions of monthly visitors, with a 650,000-member community forum integrated into the store. Still a monolith. The Hyvä migration took the frontend from 200+ JS and CSS resources down to two files and page weight from roughly 1.5 MB to 0.2 MB. No headless required.
If that sounds like your store, Hyvä theme development is the shorter path — and our breakdown of Magento Open Source vs Adobe Commerce covers where the Hyvä Commerce suite sits on each platform.
When to go headless
Go headless if several of these are true:
- Multiple frontends. Native app, in-store screens, or distinctly different storefronts per market or brand — genuinely different, not just re-skinned.
- Extreme scale. Concurrency high enough that infrastructure-level rendering control is a business requirement, not an aspiration.
- Content-led commerce. Editorial is central and needs a dedicated CMS or DXP with Magento as the commerce engine.
- An existing frontend team. You already have strong Vue or React engineers, or you're funding them.
- Composable strategy. Magento is one service among several and the frontend has to compose across them.
- Frequent storefront releases. You push storefront changes live constantly — campaigns, layouts, seasonal redesigns — and today every release means deploying the whole store to production, backend included. Decoupling lets the storefront go live on its own schedule. If that's your situation, the engineering discipline matters more than the framework choice — see headless Magento development with Alokai for how we approach it. The trade-offs also rhyme on the other platform: our write-up of headless Shopify with Hydrogen and Oxygen covers the same tensions in a different ecosystem.
Still unsure? Match the tier to the need
If you already know you need headless, go headless. Migrating to Hyvä first and rebuilding headless two years later means paying for two frontend projects to arrive somewhere you could have started. The point of this post is to help you identify which case you're in — not to route everyone through the monolith.
For most merchants, though, the honest sequence runs through the Hyvä ecosystem before it reaches headless.
Hyvä Theme is free and open source, and it solves performance. For a large share of stores that is the entire answer, and nothing further is needed.
Hyvä Commerce is the tier to look at when the theme alone doesn't cover the business need. It bundles Theme, Checkout and UI together with Hyvä CMS — a modern content editor with live preview — plus a widget-based admin dashboard, an image editor and media optimisation. It covers a surprising amount of what merchants actually reach for headless to fix: better content tooling, a faster checkout, an admin their team can work in. All without a second application to maintain. Hyvä Commerce is for Magento Open Source and Mage-OS; on Adobe Commerce the equivalent tier is Hyvä Enterprise, which adds Adobe's B2B Suite, Live Search and Sensei, product recommendations, loyalty and gift cards.
Headless is the answer when the requirement is structural rather than functional — multiple frontends, independence from the backend, or a storefront composing many systems at once. No amount of frontend tooling substitutes for decoupling when that's what you actually need.
Release frequency belongs in this tier too. On a monolith, a storefront change ships through a full Magento deployment, so updating a banner carries the same process, the same build, and the same blast radius as a backend change — and a rollback rolls back everything. Headless makes storefront releases small, fast, and independently reversible, which is a genuine operational win for teams shipping to production weekly or daily. The trade-off runs the other way for anything spanning both sides: a change that touches backend and frontend together now needs coordinating across two pipelines and a versioned API contract, which is harder than shipping it as one deployment. So headless is a clear win if most of your releases are storefront-only, and an overhead if most of them aren't.
If you're on Hyvä and a genuine headless requirement appears later, the move is still open: Magento's API doesn't care which frontend consumes it, and the catalogue, pricing, promotions and integrations all carry over. But don't plan a migration you can already see coming.
A useful rule: headless should be a response to a business requirement you can name in one sentence. "We need a native app and a web store on the same catalogue" is a reason. "We want to be modern" is not.
Headless Magento is a powerful architecture for merchants who need multiple frontends, extreme scale, or a decoupled content layer. It is a poor answer to "our store is slow" but the field data shows most headless commerce storefronts fail Core Web Vitals while most Hyvä stores pass, because fast headless is engineered and fast Hyvä is close to default.
Start with the business requirement, not the architecture. If you can't name the requirement in one sentence, Hyvä on a monolith is almost certainly enough.
Not sure which side of the line you're on? Talk to our Magento team a 30-minute technical call, no pitch.
FAQ
No. Hyvä is a monolith frontend for Magento — Magento renders the pages and Hyvä replaces the default Luma theme with a much lighter Alpine.js and Tailwind CSS layer. A Hyvä store is architecturally a monolith. It is often mistaken for headless because it delivers the page speed people associate with headless builds.
Not by default. Headless raises the performance ceiling but lowers the floor. HTTP Archive field data shows 19% of Vue Storefront origins and 2% of PWA Studio origins passing Core Web Vitals, against 67% of Hyvä origins. Fast headless requires server-side rendering, edge caching, and hydration discipline — investment many builds never make.
Yes. Magento's GraphQL and REST APIs are available regardless of frontend, so catalogue, pricing, promotions, checkout logic, and backend integrations all carry over. The frontend is rebuilt, but that's the cheapest layer to replace. Starting on Hyvä does not lock you out of headless later.
Usually not. Mid-market merchants with a single storefront rarely have the multi-frontend or extreme-scale requirements that justify decoupling, and they feel the ongoing cost of two codebases most acutely. Headless becomes worth it when you need genuinely separate frontends or infrastructure-level rendering control — not when you need a faster store.
Mostly not, without work. Extensions ship frontend code that assumes Magento renders the page, so headless builds typically reimplement that functionality against the API. Hyvä has a related but smaller problem — Luma extensions break and need Hyvä-compatible versions — but the compatibility module ecosystem is now well established.