This could honestly have been a one-line post: in 2026, to speed up your Magento store, migrate to Hyvä Theme. The catch: only ~67% of Hyvä stores pass Core Web Vitals. The rest fail on implementation, not the theme.
This could be a very short article
If you want to speed up a traditional Magento store in 2026, migrate to Hyvä Theme. 😁
The real answer is more nuanced, but the direction is clear. Luma — Magento’s default frontend since 2017 — was built around RequireJS, Knockout, and jQuery. Each module can bring its own CSS and JavaScript. Over time, the storefront becomes heavy before the merchant even adds tracking scripts, personalization tools, product recommendation widgets, payment modules, search tools, and marketing tags.
You can optimize Luma. You can reduce JavaScript, tune bundling, improve caching, compress images, and remove unused extensions. All of that helps.
But you are still optimizing an old frontend architecture.
Hyvä replaces that frontend stack with a much lighter approach: Tailwind CSS, Alpine.js, no RequireJS, no Knockout, and a cleaner development model. In our Grasscity migration, page weight dropped from around 1.5MB on Luma to roughly 0.2MB on Hyvä, and Core Web Vitals improved across the board. We published the full Luma vs Hyvä benchmark and a step-by-step Luma-to-Hyvä migration guide separately.
That is why a lot of Magento speed optimization advice from 2020 feels outdated now. Lazy loading, critical CSS, JavaScript bundling, and server tuning are still useful. But for a Luma store, they are usually not the highest-impact decision anymore.
In 2026, the first performance question is often not:
“How do we make this Luma store faster?”
It is:
“Why are we still investing in Luma optimization instead of moving to Hyvä?”
But you can screw up even blazing fast out-of-the box Hyva Theme. And with 7000+ live Hyva stores, Magento Performance Optimization in 2026 is much wider topic.
Why some Hyvä stores are still slow
According to HTTP Archive's tech report, around 67% of Hyvä stores pass Core Web Vitals — much higher than the average Magento store, but it also means roughly a third don't. The cause is almost never the theme itself.
It's implementation. We've audited stores running Hyvä that were slower than well-tuned Luma builds. The most striking example: a Hyvä storefront still loading legacy Luma dependencies, because the migration was never properly finished. The theme had been swapped in but the rest of the project had been left half-done. Hyvä is fast when it's built properly. It is not magic, and it doesn't recover from a bad build by itself.
It is usually one of these things:
- the migration was not finished properly
- legacy Luma dependencies are still loaded
- images are too large
- third-party modules add unnecessary JavaScript or CSS
- Alpine.js is used carelessly
- Google Tag Manager is overloaded
- fonts are mismanaged
- checkout still uses the old Magento stack
- Varnish or Full Page Cache is misconfigured
- backend response time is too slow
The practical takeaway: hire a team that has actually done this before. Not "knows Magento" — has shipped Hyvä, in production, more than once. The difference between a Hyvä site that passes CWV and one that doesn't is almost always the team that built it.
The patterns we see most often, when an existing Hyvä build isn't passing:
1. Unoptimized images and assets
The single most common cause of failed LCP on Hyvä stores. Large, uncompressed hero banners and product images uploaded at print resolution. Magento's default image handling serves whatever the merchandiser uploaded, in whatever format. This is the problem Hyvä Commerce's Media Optimisation feature solves at the source — more on that below.
2. Excessive or poorly written Alpine.js
Alpine is great when used correctly. Initializing thirty Alpine components on a category page, each with its own reactive state, will pull responsiveness metrics down. Hyvä's own performance docs recommend two specific fixes here: avoid huge Alpine components on catalog and CMS pages (refactor to vanilla JavaScript or minimize DOM manipulation), and use the x-defer plugin to defer initialization of components below the fold. Both are quick wins for stores that are close to passing.
3. Third-party Magento modules not optimized for Hyvä
Hyvä-compatible doesn't mean Hyvä-optimized. Plenty of third-party modules ship a Hyvä compatibility layer that technically works but introduces unnecessary bloat — extra JS bundles, heavy DOM, inline styles. The audit we run on every Hyvä project lists every active extension, flags the ones that are dragging performance, and identifies whether they need replacement, fixing, or removal. This work isn't optional on a serious commerce site.
4. Marketing scripts and tag managers
A merchant installs Google Tag Manager, hands the keys to the marketing team, and a year later there are eighteen tags firing on every page — analytics duplicates, retargeting pixels for platforms the brand stopped advertising on, heatmap tools nobody is reading, A/B test scripts left over from finished experiments. Each tag ships its own JavaScript, and many load fourth-party scripts on top.
The fix isn't technical — it's governance. Someone needs to own the GTM container, audit it quarterly, and remove what isn't earning its keep. This is theme-independent, but it shows up most painfully on Hyvä because the gap between what the theme delivers and what the live page actually does becomes obvious.
5. Slow backend (TTFB)
Hyvä is a frontend layer. Hyvä's own docs make the point clearly: once a page is cached in Varnish, only frontend optimization can influence the score, but for uncached pages backend performance still matters — slow SQL queries, an under-provisioned Elasticsearch, badly written observers, PHP-FPM running out of workers under load. A typical TTFB target for a cached page is around 200ms. If yours is 600–800ms on cache hits, the work is at the infrastructure and code level, not the theme.
6. Mismanaged fonts
Multiple weights of multiple fonts, loaded from multiple sources, with no font-display: swap and no preload. Combined font weight that exceeds the entire Hyvä bundle. Add a Google Fonts and Adobe Fonts call on the same page and you've added render-blocking work that your CSS never had to do.
7. Insufficient caching
Full Page Cache misconfigured, Varnish in front of the wrong things, or Varnish missing entirely. Hyvä's docs are direct on this: a fast cached response can be delivered in 200ms, and the difference between a cached and uncached page is measured in seconds. If your Varnish hit rate is 40%, your perceived speed is "Magento on cache miss" most of the time, regardless of theme.
And one more: Speculation Rules
Less an issue, more an opportunity most Hyvä stores haven't yet picked up. Since release 1.4.0, Hyvä includes a stable implementation of the Speculation Rules API, which lets the browser prefetch or prerender pages in the background before the user clicks. Near-instant navigation, supported in Chromium-based browsers (Chrome, Edge), which covers most of the traffic. Hyvä's documentation on configuration is the place to start.
What Hyvä does not solve
Hyvä removes the biggest frontend bottleneck in a traditional Magento storefront, but it does not solve every performance problem automatically.
Hyvä does not fix:
- slow product queries
- inefficient custom modules
- poor Varnish configuration
- low cache hit rate
- overloaded hosting
- excessive GTM scripts
- oversized content images
- render-blocking third-party tools
- complex checkout logic
- slow ERP, PIM, search, or inventory integrations
- poor development practices
- unfinished migration work
This is why Hyvä migration and Magento performance audit are not competing options.
For Luma stores, Hyvä usually solves the frontend architecture problem.
A performance audit identifies everything else that still affects real-world speed.
Hyvä Commerce Media Optimisation: fixing the image problem at the source
If you're already on Hyvä and your LCP is still poor, the cause is almost certainly your images. Hyvä Commerce 1.2 — released in March 2026 — addresses this directly.
The Media Optimisation feature scans all storefront HTML for images and converts them on the fly:
- Automatic WebP and AVIF conversion, with file size reductions averaging 35% (WebP) and 50% (AVIF), and automatic fallback to the original format for older browsers
- Three admin-configurable resize dimensions, so the browser can pick the right size for the viewport — mobile users stop downloading desktop-scale images
- Comprehensive coverage across Page Builder blocks, CMS pages, category images, Hyvä CMS content, and the media gallery
- CDN-friendly by design The relevant detail for performance: it's automatic. Once configured, the team uploads images normally and the storefront serves them optimized. For the LCP failures we see most often — large hero images, oversized banners, product imagery uploaded at print resolution — this single feature usually moves the metric across the threshold without anyone touching code.
Hyvä Commerce is a paid layer on top of the free Hyvä Theme (€3,000/year, with a refund pathway if you've already paid for Hyvä Theme or Checkout licences separately).
Speculation Rules: the next performance opportunity
Hyvä includes support for the Speculation Rules API, which allows the browser to prefetch or prerender pages before the user clicks. For shoppers, this can make navigation feel almost instant.
This is especially useful for:
- category-to-product navigation
- product-to-product browsing
- menu navigation
- frequently visited landing pages
- high-intent user journeys
It will not replace proper optimization. It will not fix slow backend responses, oversized images, or broken caching.
But once the basics are right, Speculation Rules can improve perceived speed.
Slow Checkout
One common mistake is migrating the storefront to Hyvä while leaving the default Magento checkout untouched.
The default Magento checkout still uses RequireJS and Knockout. For many stores, it becomes the slowest part of the buying journey.
There are several possible routes:
- Hyvä Checkout — a commercial checkout product built for the Hyvä ecosystem. Current pricing is €1,000 one-time + €250/year support from the second year.
- Hyvä React Checkout — a separate open-source checkout solution based on React. It is not the free version of Hyvä Checkout; it is a different product with a different architecture.
- Third-party one-step checkouts — solutions from vendors such as Amasty or Mageplaza. They may be easier to install, but should still be tested for performance, compatibility, and maintainability.
- Custom checkout work — sometimes needed when the store has complex payment, shipping, B2B, tax, or ERP-related checkout logic.
The important point is not that every Hyvä store must use Hyvä Checkout.
The point is: do not leave the default Magento checkout slow by accident.
When a Magento performance audit makes sense
If your Magento store is still on Luma, a performance audit should usually answer one strategic question:
What needs to be fixed before, during, or after a Hyvä migration?
The goal should not be to produce a long list of micro-optimizations for Luma. In many cases, that is not the best use of budget anymore.
Instead, a useful audit should help define:
- whether Hyvä migration is the right next step
- which extensions may complicate migration
- whether the backend is already a bottleneck
- whether checkout needs separate attention
- which scripts and third-party tools slow down the store
- whether hosting and caching are configured properly
- which performance problems Hyvä will solve
- which problems will remain after migration
If your store is already on Hyvä and still slow, a performance audit becomes even more important. At that point, the frontend architecture is no longer the obvious explanation. The issue is usually implementation quality, third-party scripts, backend performance, images, checkout, or caching.
Eltrino runs Magento performance audits as fixed-scope engagements covering the frontend, backend, infrastructure, third-party modules, and tracking scripts. The deliverable is a prioritized fix list, not a generic 60-page report.
FAQ
No. Hosting, caching, image optimization, extension cleanup, backend tuning, and checkout optimization all still matter.
But for Magento stores still running Luma, Hyvä is usually the highest-impact performance move because it changes the frontend architecture instead of trying to optimize around it.
Yes. Hyvä is fast by design, but implementation still matters. A Hyvä store can be slow because of oversized images, unfinished migration work, poorly optimized third-party modules, excessive Alpine.js, unmanaged GTM scripts, slow backend response times, mismanaged fonts, poor caching, or a default Magento checkout.
The most common reasons are large images, third-party scripts, slow backend responses, poor cache configuration, heavy fonts, excessive JavaScript, and modules that are technically Hyvä-compatible but not truly optimized.
Hyvä improves the baseline, but it does not remove the need for performance governance.
Not always, but you should review your checkout.
If the storefront runs on Hyvä and the checkout still uses the default Magento stack, your highest-converting page may also be your slowest. Hyvä Checkout, Hyvä React Checkout, third-party one-step checkouts, or custom checkout work can all be valid options depending on the project.
Start with Google PageSpeed Insights, WebPageTest, and Chrome DevTools Performance recordings. Test the homepage, category page, product page, cart, and checkout.
Look for scripts that block rendering, execute for too long, load on pages where they are not needed, or appear across multiple key templates.