If your Magento 2 Luma store scores below 40 on PageSpeed, a Hyva migration will typically move it into the 85 to 98 range and let it pass Core Web Vitals, because Hyva removes the heavy JavaScript that drags Luma down. What it will not fix is a slow server response time (TTFB). If your backend is slow, you must address that too.
That is the honest short answer, and it matters because most content on this topic sells the migration without naming its limits. A frontend rebuild is the single biggest lever for a badly-scoring Luma store, but it is not a magic wand. If you understand exactly what changes and what does not before you commit budget, you set the right expectations with your team, your CFO, and yourself.
We are the USA’s first official Hyva Gold Partner, and we have run this migration on stores that were stuck in the 20s and 30s. This article is the diagnostic we walk merchants through: why Luma scores so low, what Hyva actually repairs, what it leaves untouched, and the realistic numbers you can plan around.
Why your Luma store scores below 40
A PageSpeed score below 40 is almost never one problem. It is a stack of them, and on a Luma store the same four causes come up again and again.
Heavy JavaScript. This is the big one. Luma ships a large JavaScript payload built on RequireJS, jQuery, and Knockout. A typical Luma product page delivers somewhere in the range of 700 KB to 1.2 MB of JavaScript. The browser has to download, parse, and execute all of it before the page becomes interactive, which wrecks Total Blocking Time and Interaction to Next Paint.
Render-blocking CSS and JavaScript. Luma loads styles and scripts that block the browser from painting the page. Until they resolve, the shopper stares at a blank or half-built screen, which pushes out Largest Contentful Paint.
Unoptimized images. Large hero banners and product images, often served in older formats and at full resolution, are a common LCP killer independent of the theme.
Slow server response. The time your server takes to return the first byte (TTFB) sits underneath everything else. This one is not a theme problem, and it is the cause most teams misdiagnose. Hold that thought, because it is the crux of this article.
The Core Web Vitals metrics that PageSpeed reports (LCP, INP, and CLS) are described in full in Google’s web.dev Core Web Vitals guide. A sub-40 score usually means you are failing on at least two of the three, and the JavaScript weight is the biggest single reason why.
What a Hyva migration fixes
Hyva replaces Luma’s frontend stack wholesale. Instead of RequireJS, jQuery, and Knockout, it uses Alpine.js and Tailwind CSS. The effect on the metrics that drag a Luma store below 40 is direct and large.
The JavaScript payload drops from Luma’s 700 KB to 1.2 MB range down toward 50 to 100 KB on a comparable page, roughly a tenfold reduction in the amount of script the browser has to execute. That single change cascades into better Total Blocking Time, better INP, and a faster LCP because the main thread is no longer choked. Render-blocking is largely eliminated because Hyva ships far less CSS and defers what it can. Real-world migrations have moved stores from the 20-to-40 range up past 90 on PageSpeed, as documented in independent case studies like the Navigate Commerce Luma to Hyva migration.
Here is the realistic before-and-after picture for a store that starts below 40. Treat these as typical ranges, not guarantees, because your catalog, extensions, and hosting all move the numbers.
| Metric | Typical Luma (below 40) | Typical Hyva | What changed |
|---|---|---|---|
| PageSpeed score (mobile) | 20 to 40 | 85 to 98 | Lighter JS and CSS |
| JavaScript per page | 700 KB to 1.2 MB | 50 to 100 KB | Alpine/Tailwind replaces RequireJS/jQuery/Knockout |
| Mobile LCP | 3.5 to 5.0 s+ | 1.2 to 1.8 s | Less render-blocking, faster paint |
| Core Web Vitals | Usually failing | Usually passing | Frontend bottleneck removed |
| Total Blocking Time | High | Low | ~10x less JS execution |
If you want the deeper build-versus-patch framing behind these numbers, our practitioner comparison of Hyva vs Luma frontend performance lays out the migration cost and timeline ranges alongside the performance data.
What Hyva does not fix: TTFB and the backend
Here is the part the sales pitches skip. Hyva optimizes the frontend. It does nothing for your backend.
Time to First Byte is the delay between the browser’s request and the first byte of response from your server. It sits before any frontend work can begin, so it is a floor under your LCP. If your server takes 1.5 seconds to respond, your LCP cannot be faster than 1.5 seconds no matter how light the theme is. Hyva ships less to the browser, but it cannot make your server answer faster.
A slow Magento TTFB usually comes from the backend layer: unoptimized database queries, missing or misconfigured full-page cache and Varnish, no Redis for sessions and cache, a slow or undersized host, heavy third-party modules running on every request, or a missing content delivery network. The Cloudways guide to Magento TTFB is a solid reference for the server-side fixes, which include caching, database tuning, and better hosting.
This is why a store can migrate to Hyva, watch its lab PageSpeed score jump to the 90s, and still see disappointing field data. Lab scores test frontend efficiency under ideal conditions. Field data (the Core Web Vitals Google actually uses) reflects real users hitting a real server. If that server is slow, a fast theme papers over only part of the problem.
The practical implication: scope the backend at the same time you scope the frontend. A serious Luma to Hyva project should include a TTFB assessment. Sometimes the fix is as simple as turning on Varnish and adding Redis. Sometimes it means moving off shabby hosting. Either way, you want to know before launch, not after.
So how much improvement can you actually expect?
Put the two halves together. For a store scoring below 40, the realistic outcome of a well-executed Hyva migration is a lab PageSpeed score in the high 80s to high 90s and a genuine shot at passing Core Web Vitals in the field, provided your TTFB is reasonable or gets fixed in the same project.
If your backend is already healthy (good caching, Redis, a decent host), the frontend rebuild alone can carry you across the line. If your backend is slow, expect the migration to fix the frontend metrics fully and leave a residual TTFB problem that caps your field results until you address it separately. That is not a reason to skip Hyva. It is a reason to budget both.
For the full financial framing, including how these speed gains map to conversion and revenue, see our Hyva migration business case model for CFOs, which shows why even a partial improvement pays back quickly on a store doing meaningful volume.
Should you migrate, or optimize Luma first?
Not every store below 40 needs a full migration on day one. The honest decision comes down to how far below the line you are and why.
If your low score is driven mostly by images, a few heavy third-party scripts, and a slow server, you can claw back real points by optimizing Luma: compress and modernize images, defer or remove non-critical scripts, and fix the backend. That path is cheaper and faster, and for some merchants it is the right first move. We wrote a full guide on fixing Magento Core Web Vitals without replatforming for exactly that situation.
But if your score is low primarily because of Luma’s JavaScript weight and render-blocking, optimization hits a ceiling fast. You can spend a meaningful fraction of a migration budget on Luma tuning and still not pass Core Web Vitals, because the framework itself is the bottleneck. At that point, Hyva is the cheaper path to a durable result. The rule of thumb we use: if a Luma store is stuck in the 20s or 30s after basic optimization, the framework is the ceiling, and a rebuild is the answer.
Bemeir runs this as Hyva development inside a full Magento and Adobe Commerce practice, which matters because, as this article shows, the frontend and the backend have to be scoped together. Founded in Brooklyn in 2014, Bemeir works as an extension of the merchant’s team, and our differentiator is an unusually deep technology partner ecosystem that keeps payment, personalization, and shipping integrations intact through the rebuild. You can read more about us on the about Bemeir page.
We work across platforms too, so the recommendation to rebuild on Hyva rather than replatform is one we make on the merits. Bemeir also delivers on Shopify and Shopify Plus, BigCommerce, and Shopware, and if your real problem turns out to be the platform rather than the theme, we will tell you.
Frequently asked questions
Will Hyva alone get my Magento store to pass Core Web Vitals?
Usually yes on the frontend metrics, and yes overall if your backend is reasonably fast. Hyva removes the JavaScript and render-blocking problems that fail LCP, INP, and TBT on a Luma store. The one thing it cannot fix is a slow server response, so if your TTFB is high, you will pass in the lab but may still struggle in the field until the backend is addressed.
How much will my PageSpeed score improve after migrating to Hyva?
For a store starting below 40, the typical result is a mobile PageSpeed score in the mid-80s to high-90s. The exact figure depends on your images, remaining third-party scripts, and server response time. The tenfold reduction in JavaScript is the main driver, and it is the reason the gains are so large from such a low starting point.
Why did my score improve but my real-user data did not?
Because lab PageSpeed measures frontend efficiency, while field Core Web Vitals reflect real users hitting your actual server. The most common cause of this gap is a slow TTFB. Hyva made the theme fast, but your server is still slow to respond, which caps LCP in the field. Fix the backend (caching, Redis, hosting) to close the gap.
Do I need to fix my backend before or during the Hyva migration?
Scope both together. You do not necessarily have to complete the backend work first, but you should assess TTFB as part of the migration project so there are no surprises at launch. In many cases the backend fixes are straightforward (enabling Varnish and Redis, adding a CDN), and doing them alongside the frontend rebuild gives you the full result in one project.
Is optimizing Luma ever a better choice than migrating to Hyva?
Yes, when your low score is driven mainly by images, a handful of scripts, and backend issues rather than by Luma’s framework weight. In that case, targeted optimization is cheaper and can be enough. But when the score is low because of Luma’s core JavaScript and render-blocking, optimization hits a ceiling, and a Hyva migration becomes the more cost-effective path to a durable, passing result.
A sub-40 score is a clear signal, but the fix depends on why. Diagnose the cause before you write the check: if it is Luma’s frontend weight, Hyva is the highest-return move you can make, and if a slow backend is dragging you down too, budget for both so the score you win in the lab actually shows up for your customers.
