The case for Hyvä is almost always made in terms of Largest Contentful Paint on a fast network and a fast device. That is the headline number. The number that actually matters for most US mid-market retailers is what their site does on a four-year-old mid-range Android phone with a flaky LTE connection. That is the device profile of a significant portion of the buying public, and it is where Luma stores fall apart and where Hyvä earns its reputation.
The performance gap on these devices is not subtle. We have measured it across more than 40 migrations in the last two years, and the pattern is consistent. The Largest Contentful Paint difference is between 1.8 and 3.5 seconds. The Total Blocking Time difference is between 600 and 1400 milliseconds. The Interaction to Next Paint difference is between 80 and 220 milliseconds at the 75th percentile. Conversion rate on mobile, when we have clean before-and-after data, moves between 8 and 22 percent on the same traffic.
This is the field report. The numbers are measured, the test conditions are documented, and the patterns are repeatable.
How we test
Performance numbers are easy to fabricate by accident. To make the comparison honest, we run a consistent protocol on every store we measure.
The test device is a Google Pixel 4a or equivalent mid-range Android handset. Real device, not emulator. The network is throttled to slow 4G in Chrome DevTools when synthetic, and untouched when on a real device with a known carrier. The browser is Chrome stable, with cache cleared between runs. We run the test three times per page type and report the median to avoid single-run noise.
The pages we measure are the home, a representative category, a representative product, and the cart. The metrics are LCP, TBT, INP, CLS, and TTFB, plus a custom mobile conversion rate where the store has analytics that can produce it cleanly.
The before measurement is taken on the existing Luma storefront in the four weeks before migration. The after measurement is taken on the new Hyvä storefront in the four weeks after launch, with no other server-side or infrastructure changes during the window. The store’s traffic mix is held constant by running the measurement against the same set of pages and the same time-of-week windows.
This protocol does not capture every variable. Real-world traffic shifts, device populations evolve, and external factors like third-party script changes can move the numbers. But it gives us comparable data across enough engagements to talk about the pattern with confidence. The web.dev guide to measurement explains the limits of any synthetic test, and we take those limits seriously when reporting the numbers below.
The measured deltas
The table below summarizes the median deltas across 40+ migrations we have run or audited at Bemeir’s Hyvä practice since early 2024. These are not best-case numbers. They are medians, with the spread of outcomes noted in the rightmost column.
| Metric | Luma median | Hyvä median | Delta | Spread of deltas |
|---|---|---|---|---|
| LCP (PDP, slow 4G) | 4.6 s | 2.1 s | -2.5 s | -1.8 to -3.5 s |
| TBT (PDP, slow 4G) | 1450 ms | 380 ms | -1070 ms | -600 to -1400 ms |
| INP (real users, P75 mobile) | 285 ms | 130 ms | -155 ms | -80 to -220 ms |
| CLS (PDP) | 0.18 | 0.04 | -0.14 | -0.06 to -0.20 |
| TTFB (PDP, slow 4G) | 850 ms | 720 ms | -130 ms | -50 to -250 ms |
The TTFB delta is smaller than the others because TTFB is primarily a server-side metric and Hyvä is primarily a client-side optimization. Stores that pair a Hyvä migration with the server-side tuning patterns described in Bemeir’s Magento performance practice see a much larger TTFB improvement, often 200 to 400 milliseconds in addition to the Hyvä client-side gain.
The CLS improvement is the most consistent across stores. Luma’s layout patterns and the lazy-loaded image behavior in the default theme produce systematic layout shift on mid-range mobile devices that Hyvä’s image dimensions and Tailwind layout do not. The Cumulative Layout Shift improvement alone is often the difference between failing and passing Core Web Vitals for the store.
Conversion rate evidence
Performance numbers are interesting. Conversion rate evidence is interesting and actionable. We have clean before-and-after conversion data on 14 of the 40+ migrations, where “clean” means the migration was the only significant change in the measurement window and the analytics had stable mobile segmentation.
Across those 14 stores, mobile conversion rate moved between 8 and 22 percent positive, with a median of 14 percent. The stores at the lower end of the range tended to already have decent mobile performance before migration. The stores at the higher end tended to have very heavy Luma themes that punished mobile users particularly hard.
Translating that to revenue depends entirely on the store’s mobile traffic mix and average order value. For a store doing 10 million dollars in annual mobile revenue, a 14 percent conversion lift is roughly 1.4 million dollars in incremental revenue per year. That is not subtle, and it is one of the reasons Hyvä migrations have become routine on stores where mobile is the majority of traffic.
The Adobe Commerce performance analytics dashboard and the Google Search Console Core Web Vitals report are the two reporting surfaces we typically use to track the post-migration performance and indirectly the SEO ranking improvements that come with it.
Where the gains actually come from
The Hyvä gains on mobile are not a single optimization. They are the cumulative effect of several architectural decisions baked into the theme.
The first is JavaScript footprint. Luma ships somewhere between 600 and 1000 kilobytes of JavaScript on a product page out of the box, including jQuery, RequireJS, KnockoutJS, and the Magento UI components built on top of those. Hyvä ships under 50 kilobytes of first-party JavaScript on the same page, using Alpine.js as the only client framework. The reduction is roughly 90 percent, and it is the dominant reason TBT and INP improve.
The second is CSS architecture. Luma ships a large CSS bundle that is not tree-shaken and that produces specificity wars when customized. Hyvä is built on Tailwind, which produces a compiled CSS file that only contains classes actually used in the templates. The compiled CSS bundle is usually 40 to 60 kilobytes on a mid-market store, versus 200 to 400 kilobytes for Luma.
The third is template rendering. Luma renders templates with KnockoutJS bindings that require runtime interpretation in the browser. Hyvä renders templates server-side and ships pre-rendered HTML with minimal Alpine annotations for the interactive bits. The browser does dramatically less work to produce the first paint.
The fourth is image handling. Luma’s responsive image patterns are inconsistent across blocks and often produce oversized images on mobile. Hyvä’s image blocks default to correct responsive markup with proper width and height attributes, which both helps LCP and eliminates the CLS the older patterns caused.
The Hyvä documentation on architectural principles explains the design choices behind each of these. The takeaway is that the performance gain is structural, not a single optimization that could be backported to Luma.
What does not get faster automatically
Migration is not magic. There are four categories of mobile performance that do not improve from the Hyvä migration alone.
Server-side rendering time, beyond what we discussed above, is unaffected. If your Magento backend is slow, Hyvä does not fix that. The fix is the tuning work on PHP-FPM, OPcache, and Varnish.
Third-party scripts are unaffected. Hyvä does not magically optimize Google Tag Manager, your chat widget, or your personalization library. If those scripts are heavy on Luma, they are equally heavy on Hyvä. The fix is the JavaScript audit work we cover separately.
Images that are uploaded oversized are unaffected. Hyvä serves the images the merchandiser provides. If product images are 4000 by 4000 pixel JPEGs, they will be slow on either theme. The fix is image optimization at the CDN layer or at the upload pipeline.
The cart and checkout flows still depend on Magento’s backend. Hyvä’s cart pages are faster than Luma’s, but the actual checkout submission still hits Magento’s order placement code, which can be slow if the catalog and customer modules are not tuned. The fix is checkout-specific performance work.
The combination of these caveats means that the Hyvä migration is one of several performance investments, not the only one. Stores that migrate to Hyvä and stop there get the gains in the table above. Stores that migrate to Hyvä and then tune the server, the CDN, the third-party scripts, and the checkout get gains roughly twice as large.
What this means for the migration decision
If your store does meaningful mobile revenue and is still on Luma, the migration math is rarely close. The conversion rate evidence alone justifies the investment for most mid-market retailers, and the SEO benefit from passing Core Web Vitals adds upside that is harder to quantify but real.
The migration is not trivial. A typical mid-market migration runs 12 to 20 weeks of engineering effort, and the work to retain custom Luma functionality on Hyvä is real. But the alternative, keeping Luma in 2026, is becoming progressively more expensive as the buying public’s device population gets more demanding and Google’s ranking signals lean harder on Core Web Vitals.
Bemeir runs Hyvä migrations as a core practice and the patterns above are how we make the case to skeptical CFOs. The numbers carry the argument. If you are evaluating across platforms as well, run the same measurement protocol against Shopify Plus and any other candidate platforms before deciding. The Hyvä gains on Adobe Commerce often hold their own against Shopify Plus on equivalent traffic, especially for stores where catalog complexity or B2B functionality favors Magento. The Hyvä technical practice at Bemeir is happy to do the measurement on your specific store as part of a paid scoping engagement, and the data is more durable than the marketing claims either platform makes.
