Hyvä, PWA or Stay on Luma? A Magento Front-End Decision Framework With Real Costs

If you run a Magento 2 store, someone has told you your front end is the problem. They are frequently right. Luma — Magento's default theme — ships RequireJS and Knockout.js to every visitor, and on a mid-range Android phone that stack alone can cost you two seconds before a single product image appears.

But the front end is slow is a symptom, not a prescription. The three answers on the table — migrate to Hyvä, build a PWA storefront, or optimise the Luma theme you already have — differ by roughly an order of magnitude in cost and by about the same in risk. Choosing wrongly is one of the more expensive mistakes available to a Magento merchant, and the people pitching you the answer usually sell exactly one of the three.

We build all three. This is the framework we use internally before we quote anything, including the cases where we tell a client to spend nothing.

The Three Options, Honestly Described

Option 1: Optimise the Luma Theme You Already Have

The option nobody pitches, because it is the smallest invoice. Luma is slow largely because of what has been bolted onto it: third-party extensions injecting their own JavaScript, unbundled RequireJS modules, unoptimised media, a full-page cache that misses more often than anyone realises, and a Varnish configuration that was correct three years ago.

A disciplined optimisation pass — extension audit, critical CSS, deferred JavaScript, image pipeline, cache warming, database and Redis tuning — routinely takes a Luma store from a failing Core Web Vitals assessment to a passing one. Not to a 100 Lighthouse score. To a passing one, which is what actually affects rankings and conversion.

• Typical cost: £8,000–£25,000 depending on how much extension debt exists
• Typical duration: 4–8 weeks, delivered incrementally against a live store
• Risk: low — every change is reversible and nothing about the storefront's structure changes
• Ceiling: real. There is a floor to how fast Luma can get, and heavy category pages will still feel heavy

This is the work we do under page speed optimisation, and it is where we start on most engagements — including ones that later go on to a full front-end migration. Knowing which of your problems are theme problems and which are extension problems is worth doing before you spend ten times as much.

Option 2: Migrate to Hyvä

Hyvä replaces Luma's theme layer with Tailwind CSS and Alpine.js. The catalogue, pricing, cart, checkout and admin all stay exactly where they are — this is a front-end exchange, not a replatform. It typically removes the majority of the JavaScript Luma ships and produces a storefront that server-renders fast by default rather than fast after tuning.

The catch, and it is the whole catch: every extension with a storefront UI has to be reworked. Hyvä has a compatibility module ecosystem that covers the popular vendors, but the long tail — your bespoke configurator, that regional payment method, the loyalty widget from a vendor who has not updated since 2023 — is your project's real scope. We have seen the same store quoted at wildly different prices by different agencies purely because one counted the extensions and the other did not.

• Typical cost: £30,000–£90,000 for a mid-size catalogue, plus the Hyvä licence
• Typical duration: 10–20 weeks
• Risk: moderate — the storefront is rebuilt, so the whole customer journey needs re-testing
• Ceiling: high. This is the fastest a conventional Magento storefront gets.

We have done this conversion enough times to have a view on where it lands. In our Shirt Tuning Luma-to-Hyvä conversion, the catalogue, pricing and checkout logic were untouched while the front end was exchanged wholesale — that separation is precisely what makes the migration tractable. On PriceGuru we built on Hyvä from the start, which is a materially easier project than converting an established store.

Option 3: Build a PWA Storefront

A headless build: Magento becomes an API, and the storefront is a separate JavaScript application — PWA Studio, or increasingly a bespoke Next.js front end talking to GraphQL. You gain total design freedom, app-like navigation, and the ability to put a storefront in front of more than one commerce backend.

You also take on a second application to run, with its own hosting, deployment pipeline, monitoring, dependency upgrades and — critically — its own SEO surface that has to be got right by hand rather than inherited. Every piece of native Magento storefront behaviour becomes something you now own. Merchandisers who could edit a page in the admin often cannot any more.

• Typical cost: £80,000–£250,000+
• Typical duration: 5–9 months
• Risk: high — this is a new application, not a theme, and it changes how your team works
• Ceiling: the highest, and the only option that also unlocks non-Magento backends later

The Decision Framework

Work through these in order. The first honest yes is usually your answer.

1. Have You Actually Measured, or Are You Reacting to a Lighthouse Score?

A single Lighthouse run on your laptop is not a measurement. Look at the Core Web Vitals field data in Search Console — real visitors, real devices — and segment it by template. Most Magento stores we audit have a homepage that passes and category pages that fail badly, which is a targeted problem, not a whole-storefront problem.

If your field data shows LCP failing on 60% of category-page views but your product pages are fine, you have a category-page problem. That is worth diagnosing before it becomes a migration.

2. How Much of Your Slowness Is Extensions?

Disable third-party extensions on a staging clone, one group at a time, and re-measure. We regularly find a single tag manager, review widget or personalisation script accounting for more blocking time than the entire Luma framework. If that is your store, a Hyvä migration will disappoint you: you will pay for a new theme layer and then load the same offending script into it.

3. Are You Changing the Design Anyway?

If a rebrand or a full redesign is already funded, the economics change completely. Rebuilding Luma templates to match a new design costs a substantial fraction of building them in Hyvä, and you end up with the slow stack. When design work is already on the roadmap, Hyvä is usually the right answer even if performance alone would not have justified it.

4. What Does Your Extension Inventory Look Like?

Count every extension that renders something a customer sees. For each, check whether a Hyvä-compatible version exists, whether the vendor is still active, and whether you actually still use the feature. In our experience a store running fewer than about fifteen storefront-facing extensions migrates comfortably; past thirty, the compatibility work dominates the project and the estimate needs to say so.

5. Do You Genuinely Need a Separate Front End?

A PWA is justified by requirements Magento's templating cannot satisfy — a storefront serving multiple backends, an app and web experience sharing one codebase, a customer journey that is genuinely application-like rather than catalogue-like, or a roadmap that includes leaving Magento. Wanting a modern JavaScript stack is not a requirement. It is a preference, and it is an expensive one to fund from the storefront budget.

If a headless architecture is genuinely where you are heading, it is worth comparing what you would build on Magento against a purpose-built headless engine — we lay out that comparison in our platform selection work.

6. Can You Afford the Wrong Answer?

A failed Luma optimisation costs you a few weeks. A failed Hyvä migration costs you a quarter and a lot of goodwill. A failed PWA project has ended careers. Weight the options by what happens if the project goes badly, not only by what happens if it goes well.

When We Tell Clients to Stay on Luma

This is the part of the conversation the pitch decks skip, so here it is plainly. We recommend staying on Luma when:

• Field Core Web Vitals already pass and the pressure is coming from a synthetic score rather than real visitors
• The store is on a Magento version that needs upgrading first — do the platform upgrade, then re-measure, then decide
• A replatform is on the two-year roadmap — do not spend six figures on a front end you plan to retire
• The extension estate is enormous and largely bespoke, and the compatibility work would exceed the value of the speed gain
• The real bottleneck is server-side — a slow time-to-first-byte from an undersized database or a cold cache is not a theme problem, and no front end will hide it
• Trading conditions make the risk unacceptable right now — nobody should be migrating a storefront six weeks before peak season

That last one matters more than merchants expect. We have declined migration work in September more than once. The right project at the wrong time is still the wrong project.

Building the Payback Model

Whichever option you pick, the business case is the same arithmetic. You need four numbers, and you already have three of them.

1. Sessions per month on the templates you plan to change — not sitewide, just the affected templates
2. Current conversion rate on those templates, split by device, because mobile is almost always where the gap is
3. Average order value, again on those templates
4. Expected conversion uplift — this is the only estimate, and it should be conservative

On that fourth number, be sceptical of anyone quoting you a percentage without qualification. The honest position is that speed improvements correlate with conversion improvements, that the effect is larger on mobile and on slower connections, and that the size of the effect varies enormously by category and basket value. Model a conservative case and an optimistic case, and make the decision on the conservative one.

Then divide the project cost by the monthly gross-profit uplift in your conservative case. If the payback period is under twelve months, the case is strong. Twelve to twenty-four months, it is defensible if the storefront has other jobs to do — a redesign, a B2B channel, a new market. Beyond twenty-four months on the conservative case, you are buying something other than a return.

What Each Option Actually Costs to Own

Build cost is the number everyone compares. Ownership cost is the number that decides whether you regret the choice.

Luma costs you nothing extra to own, and everything to maintain: each new extension risks re-introducing the JavaScript weight you paid to remove, so performance work becomes a recurring line rather than a project.

Hyvä carries an annual licence and a modest ongoing compatibility tax — new extensions need Hyvä-compatible versions, and the pool is smaller. In exchange, performance regressions are much rarer, because there is far less machinery to regress.

A PWA costs you a second application forever: separate hosting, separate deployments, separate dependency upgrades, separate security patching, and a front-end skill set your team must retain. Budget an ongoing engineering allocation, not a maintenance retainer. This is the cost most PWA business cases omit, and it is the one that bites in year two.

A Sensible Sequence

For most Magento merchants, the correct order of operations is unglamorous:

1. Get onto a current, supported Magento version — everything downstream is easier and cheaper on 2.4.9
2. Audit and cut the extension estate; retire what nobody uses and replace what cannot be made fast
3. Do the server-side work — cache hit rates, database tuning, image pipeline, hosting profile
4. Re-measure field Core Web Vitals and see what is actually left
5. Then decide whether the remaining gap justifies a front-end migration

Merchants who follow that sequence sometimes discover the migration is unnecessary. The ones who go straight to step five sometimes discover it after they have paid for it.

If you would like a second opinion on where your store actually sits, our Magento development team will run the measurement and tell you honestly which of the three answers your data supports — including when it is none of them yet. The same discipline applies across our Magento platform work, and for retail brands it usually pays for itself in the first quarter after launch.

Get the Measurement Before the Quote

The most useful thing you can do before spending anything is find out which of your problems are theme problems. We will run that audit and give you the honest answer, even when the answer is that you do not need us. Talk to our team — we reply within a business day.