If you run a Magento store you’ve heard the word Hyvä by now. From your developer, from another agency, or floating around in a LinkedIn comment thread where somebody is very confident about something.
Most explanations go too technical too fast or stay so vague they tell you nothing. So this is my attempt at an honest middle ground. I’ve been building on Magento for years and working with Hyvä since it started getting serious traction, and I’ve watched it change what we can promise clients on a timeline. If you want it built properly, that’s our Hyvä work and our Adobe Commerce development.
First, the problem it solves
Magento is a powerful platform. For mid-market and enterprise ecommerce there’s still nothing that matches it for flexibility and control.
But the frontend, the part your customers actually see, has always been the weak point. Traditional Magento runs on a system called Luma. Luma is slow.
Not slow in a vague, hard-to-measure way. Slow in a very specific one.
A standard Magento store on Luma loads somewhere between 1.5MB and 2MB of JavaScript and CSS before your customer can interact with the page. That means load times of 4, 5, 6 seconds on mobile. Sometimes worse. Most mobile users abandon a page that takes more than 3 seconds, so you can do that maths yourself. If you’re buying traffic, every slow page is money you’ve already spent and won’t get back.
Luma also makes development slow and expensive. Lots of interconnected files, lots of dependencies, lots of chances for something to conflict when you touch it. A checkout customisation that should take a week takes a month, purely because of how the thing is put together.
That’s what Hyvä was built to fix.
So what is it?
Hyvä is a replacement frontend for Magento and Adobe Commerce. It keeps everything that makes Magento powerful, the product management, the order processing, the admin, and replaces the layer that renders what customers see.
It’s built on Alpine.js and Tailwind CSS, if you’re technical. If you’re not, ignore that sentence and look at what it does to the page weight.
Instead of loading 200+ files totalling nearly 2MB, a Hyvä storefront loads two files totalling around 0.2MB. Roughly 1% of the weight.
The result is load times under 2 seconds on mobile rather than over 5. PageSpeed scores in the 90s rather than the 40s. Core Web Vitals that pass rather than fail.
What it does to development
This is the part I find genuinely interesting, and it’s the part nobody sells you on.
Because Hyvä strips out the complexity that made Magento development slow, projects take significantly less time to build and test. A rebuild that took 18 weeks on a traditional frontend often lands in 6 to 8 weeks on Hyvä. That isn’t corners being cut. It’s the same work with less friction in the way.
The cost follows. Checkout customisations that were £30k to £40k on a standard build often come in at £10k to £20k on Hyvä. We haven’t dropped our rates. The hours are genuinely fewer.
Same logic on maintenance. Changes that used to need careful handling and a lot of regression testing can be made faster and with less risk, which keeps your retainer down and means we can turn things around quickly when you need something changed on a Thursday.
Is it right for every Magento store?
No.
If your store is small, your traffic is low and you’re not planning much ongoing development, a full Hyvä rebuild probably isn’t where your money should go right now. There are cheaper ways to claw back performance incrementally, and I’d rather tell you that than sell you a project.
But if you’re growing, if performance is dragging your conversion rate, if development feels slow and expensive, or if you’re planning a redesign anyway, Hyvä should be on the table.
The stores that benefit most are the ones doing real volume, where a second or two off load time turns straight into revenue, and the ones with an active roadmap, where the efficiency gains compound month after month.
What the numbers look like
I’m sceptical of before and after stats that are too clean, so I’ll be specific about what we’ve actually seen.
Mobile load times drop from the 4 to 7 second range down to 1 to 2 seconds after a rebuild. Mobile PageSpeed scores, which are notoriously hard to shift on Magento, regularly clear 90 post-launch.
One store we rebuilt went from around £25k a month to over £1m in the months after launch. That wasn’t purely the frontend, other things changed at the same time, and I’m not going to pretend otherwise. But the performance gains were a big part of it.
The development time savings are the consistent bit. Across the Hyvä projects we’ve delivered, build time comes in roughly 40% to 50% shorter than the same project would have been on Luma. You can see what that looks like on real stores in our work.
A few things worth knowing first
Hyvä isn’t a plugin or an upgrade you apply to your existing theme. It’s a rebuild of your storefront. Any custom frontend work you have now gets redone in the Hyvä framework.
Some Magento extensions still aren’t fully compatible, though the community has grown a lot and that gap keeps closing. Part of a proper Hyvä project is auditing what you’re running and either finding a compatible alternative or building it.
And the pricing has changed, which trips people up. Hyvä Themes, the core framework, is now free. The licence fees kick in for Hyvä Checkout or Hyvä Commerce, which are separate products. Plenty of stores get everything they need from the free Themes layer. Others find Checkout pays for itself in how much it tidies up the purchase flow. Work out which parts of the stack you actually need before you budget for all of them.
If the frontend isn’t your only concern, it’s worth reading what Magento 2 really costs to run alongside this.
What’s your take on Hyvä?
If you’re on Magento and performance is on your radar, I’m happy to talk through whether Hyvä makes sense for your specific setup. It’s not always the right call, but when it is, the difference is significant. You can also find out more about our Hyvä service.