The Short Answer

For almost every UK Magento 2 store under heavy active development, Hyva is the right call. It's roughly twice as fast on real Core Web Vitals, a third quicker to develop new features in, and the modern frontend ecosystem has moved decisively over to it. Stay on Luma only if your store is in maintenance mode, your customisations are heavy and stable, or you're already replatforming off Magento within 12 months.

Luma is Magento's default frontend theme. It's been the standard since Magento 2 launched in 2015. It's based on Knockout.js, RequireJS, and Less, all of which were modern at the time and are now firmly in the "still works but nobody starts a new project with this" category.

Hyva is the alternative, founded in 2020 with its first public release in February 2021. It's built on Tailwind CSS and Alpine.js, and strips out Knockout, RequireJS, jQuery and the LayoutXML-driven JavaScript loading that makes Luma so slow. Hyva 1.4 in late 2025 added support for Tailwind 4. The Theme itself went fully open source under OSL 3.0 / AFL 3.0 at the same time.

The comparison below is for merchants who already run Magento 2 and are deciding whether to re-theme. If you're choosing between Magento and a different platform entirely, read Magento 2 vs Shopify Plus instead.

Performance: where the gap is brutal

Real-world numbers from UK Magento stores we've audited:

Metric Luma (typical) Hyva (typical)
Mobile Lighthouse score25 to 4585 to 95
LCP (Largest Contentful Paint)3.5 to 6 seconds1.4 to 2.4 seconds
INP (Interaction to Next Paint)250 to 500ms80 to 200ms
JavaScript shipped to homepage1.2 to 2.4 MB50 to 200 KB
Time to Interactive5 to 10 seconds1.5 to 3 seconds

Hyva doesn't ship Knockout, RequireJS, or jQuery on the storefront. That alone is the bulk of the Luma payload. The default Hyva theme passes Core Web Vitals on a basic catalogue page out of the box, which Luma cannot do at any budget without aggressive customisation.

The conversion impact varies, but typical numbers we've seen across UK ecommerce stores post-Hyva are a 5 to 15% conversion lift on mobile traffic, with the biggest gains on stores that had the slowest Luma performance to begin with.

Development speed: less obvious, equally large

This is the angle that doesn't get talked about enough. For a mid-sized agency or in-house team building features on a Magento 2 store, Hyva is significantly faster to work in:

  • Tailwind beats the Magento Less / styles-l.less inheritance chain for almost any frontend change. Junior developers ship faster, code reviews are quicker, and component reuse is easier.
  • Alpine.js covers 90% of the interactive frontend work Luma uses Knockout for, with maybe a quarter of the code.
  • No RequireJS, no LayoutXML JavaScript loading. If you've ever tried to debug a "why doesn't this JS run" issue in Luma, you know the time sink.
  • No "Magento way" lock-in. Frontend developers from non-Magento backgrounds can be productive on Hyva in days, not weeks.

For agencies, this is the second reason Hyva has eaten the market. The first is performance. The second is that recruitment is easier because you're hiring frontend developers, not "Magento 2 frontend specialists" — a much smaller and more expensive talent pool.

Module compatibility: Luma still wins on day one

The honest case for Luma is module compatibility. Every Magento 2 extension on the market works with Luma. Many of them don't yet have Hyva support out of the box.

Hyva addresses this with the Hyva Compatibility Module Tracker (gitlab.hyva.io), a catalogue of compatibility modules, community contributions, and vendor-shipped Hyva-native versions. The tracker covers most of the big extensions (Amasty, Mageplaza, Mirasvit, Aheadworks) for their popular modules. For the long tail of niche extensions, you're on your own.

In practice, on a typical UK Hyva migration:

  • 60 to 80% of installed modules need no action
  • 10 to 25% are covered by Hyva Module Library connectors
  • 5 to 15% need a Hyva-native rewrite or replacement
  • A handful turn out to be unused and get removed

If your store runs on a heavily niche extension stack you've collected over years, do the module audit before you commit. Some merchants find that two or three load-bearing extensions are Hyva-incompatible and decide it's cheaper to wait for the vendor to release Hyva support.

Build cost: Hyva costs money up front

Staying on Luma costs zero. Re-theming to Hyva is a £25,000 to £60,000 project for a typical UK mid-market store. We've broken this down in detail in the Hyva cost guide.

The payback case for Hyva is conversion uplift plus reduced development cost on future features. Both are real, but both take 6 to 18 months to recoup the build cost. If your store is small enough that £35,000 of conversion uplift in a year isn't realistic, the maths is against Hyva.

When Luma is still the right call

Be honest about your situation. Luma is fine when:

  • You're in maintenance mode. The store works, the team isn't actively shipping features, and you're not chasing growth. Don't spend £35,000 to improve a frontend you're not iterating on.
  • You're replatforming within 12 months. If Shopify Plus or a different platform is in the roadmap, don't pay for a Hyva re-theme you're going to throw away.
  • Your module stack is heavily Luma-locked. If three or more business-critical extensions are Hyva-incompatible and aren't likely to get there soon, you're rebuilding too much.
  • You're a B2B store with logged-in desktop users. Core Web Vitals on logged-in pages doesn't help SEO. If your conversion funnel doesn't depend on public, mobile, anonymous traffic, the Hyva case is weaker.

When Hyva is obviously right

And when it isn't a close call:

  • You're spending on paid traffic and your mobile bounce rate is high.
  • Your team complains about how slow it is to ship frontend changes on Magento.
  • You're under active commercial pressure on page speed (Google Ads quality scores, organic rankings, conversion benchmarking).
  • You're between front-end developer hires and can't find Luma talent at a reasonable price.
  • You plan to be on Magento for the next three to five years.

What about staying on Luma but tuning it?

You can squeeze Luma. Critical CSS, aggressive image lazy-loading, removing unused modules, varnish tuning, switching to a faster host. Done well, you can get a Luma store from Lighthouse 25 to Lighthouse 60 or even 70 on a good run. That still doesn't pass Core Web Vitals, but it's a meaningful improvement.

The honest version is that aggressive Luma optimisation usually costs £8,000 to £20,000 of consulting work and gets you a fraction of the result Hyva does, with no benefit to development speed afterwards. It's a worthwhile project if the constraints above mean Hyva isn't on the table. It's not a substitute when Hyva is.

The decision in one paragraph

If you'll be on Magento for the next two years or more, your store does decent traffic, and your team is actively building features, re-theme to Hyva. If any of those three are uncertain, look at the cheaper Luma optimisation path first. The right answer is rarely "do nothing" — Luma will keep getting slower relative to the ecosystem around it, and the gap will keep widening.