28 Aug 2026 · 4 min read
Luma vs PWA vs Hyva: a Magento frontend decision matrix
A side-by-side decision matrix for the three common Magento 2 storefront paths — default Luma, a headless PWA, and Hyva — across cost, effort, performance, and team fit.
Decision brief first, then the engineering view. Part 2 of the Hyva series.
Decision brief: three roads, one backend
Magento 2 gives you three realistic storefront shapes. They share the same PHP backend, the same catalog, the same admin — they differ only in what renders the page in the browser:
- Luma (default): the bundled theme, Knockout + RequireJS + Less.
- Headless PWA: a separate JavaScript application (often PWA Studio or a custom React/Vue app) talking to Magento over GraphQL.
- Hyva: a slim Tailwind + Alpine theme that replaces Luma's frontend in place.
The instinct is "newer is better." It usually is not. Each path has a cost profile and a fit. The matrix below makes the trade-offs explicit.
The matrix
| Dimension | Luma (default) | Headless PWA | Hyva |
|---|---|---|---|
| Upfront cost | Low (already there) | High (new app + infra) | Medium (license + theme rebuild) |
| Ongoing maintenance | Medium (heavy JS, hard to debug) | High (two codebases to keep in sync) | Low (one theme, small JS) |
| Time-to-interactive | Poor on catalog pages | Excellent (app-shell caching) | Excellent (tiny JS) |
| SEO control | Good | Good (needs care with SSR) | Good |
| Module compatibility | Native (built for it) | Variable (GraphQL coverage) | Needs compat templates |
| Team skill required | PHP + Knockout/Less | Frontend-heavy (React/Node) | PHP + Tailwind/Alpine |
| Migration risk | None (status quo) | High (rebuild UX) | Medium (rebuild theme) |
| Best for | Legacy stores, low-traffic | Greenfield, app-like UX | Performance-focused Luma stores |
Reading the matrix
Luma wins on inertia, loses on speed. If the storefront is not a conversion or ranking bottleneck, staying on Luma is rational. The mistake is staying on Luma while expecting modern Core Web Vitals without a frontend change — caching and CDNs help, but they do not remove the JavaScript weight.
PWA wins on app-like experience, loses on cost and coupling. A headless storefront is the right call when the business wants a native-app feel, a shared cart across web and mobile, or a heavily customized journey that the theme layer fights you on. It is the wrong call when the goal is simply "make the catalog faster" — you pay for two codebases to get there.
Hyva sits in the sweet spot for most Luma stores. It removes the JavaScript weight (the actual cause of slow catalog pages) without introducing a second application. You keep one deploy, one team skill set, and your existing modules. The cost is a theme rebuild, which is bounded and predictable.
A note on compatibility risk
The one dimension where Hyva lags Luma is module compatibility. A Luma storefront renders any module that ships a .phtml template. Hyva needs a Hyva-specific template for interactive modules. Many popular extensions already ship a Hyva compatibility package; some do not, and you write the template yourself. Budget for this — it is the main source of schedule risk, and the migration checklist post covers how to inventory it.
Try before you commit
Before signing off on any of the three, stand up a throwaway copy of the store and measure it. The cheapest way to do that locally is Govard: a single govard env up gives you a working Magento with the storefront running, so you can benchmark Luma as-is, then prototype a Hyva child theme against the same catalog. Decide on numbers, not on demos.
Engineering view: what actually changes
Under the hood the three paths diverge at the rendering boundary:
- Luma renders server-side from layout XML + PHTML, then hydrates a Knockout layer in the browser. The server does most of the work; the client does repetitive binding and polling.
- PWA moves rendering to the client. Magento becomes a headless service behind GraphQL; the browser app owns the DOM. You gain caching and interactivity, and you take on deploy coordination between two stacks.
- Hyva keeps server-side rendering but deletes the client framework. Layout XML + PHTML still produce the HTML; the difference is the template uses Tailwind classes and a small Alpine script instead of Knockout bindings. The network payload shrinks because there is almost nothing left to hydrate.
That last point is why Hyva's performance gains show up on the pages that matter most — category and product — where Luma's Knockout graph is heaviest and where organic traffic lands.
The next post covers the mirror image of this one: the cases where Hyva is not the answer, so the decision is balanced rather than a sales pitch.
Next in this series: When not to choose Hyva —
/blog/magento2-hyva-when-not-to