Magento slow on mobile? Here's why Hyvä fixes it

Magento on mobile is slow. That's not subjective. The typical default Magento Luma store scores between 30 and 55 on mobile Lighthouse Performance — well below Google's "good" threshold of 90 and far below what conversion needs.

The reasons are specific and well-understood. The fix is also specific: replace the frontend rendering layer. That's exactly what Hyvä does. This post is the technical "why it's slow" + "what Hyvä changes."

Why default Magento is slow on mobile, in five layers

1. The JavaScript payload

Default Magento ships several megabytes of JavaScript per page. The biggest contributors:

• Knockout.js (~25KB gzipped, plus dozens of view models)
• RequireJS (~20KB gzipped, plus deferred-loading overhead)
• Magento UI Components — heavy reactive system layered on top of Knockout
• jQuery (~30KB gzipped, still used across Luma templates)
• All the per-page UI Components for cart, mini-cart, address selector, etc. — these load on every page whether you use them or not

Even after gzipping, the JS payload typically lands at 2–4MB across PDP, PLP, cart, and checkout. On a mid-range Android with a slow 4G connection, the JavaScript parse time alone (forget download — just parsing the JS) can be 3–6 seconds.

2. The render-blocking pattern

RequireJS is an asynchronous-module-loading system. In practice on Magento, the bootstrapping sequence is:

1. Browser parses HTML
2. Browser sees Magento RequireJS bootstrap script
3. RequireJS fires off requests for the dependency tree
4. Each dependency loads other dependencies
5. Eventually the page becomes interactive

The result: First Contentful Paint is okay, but Time to Interactive is terrible because the page can't respond to clicks until the RequireJS dependency tree resolves.

3. Knockout's view-model overhead

Every interactive element on a Luma page — mini-cart icon, address dropdown, configurable product variant selector — has a Knockout view model attached. On page load, every view model has to initialise and bind to its DOM target.

This is fine on desktop. On mobile, the cumulative parse + bind time for dozens of view models adds 1–3 seconds to Time to Interactive even on a clean page.

4. Template-rendered HTML weight

Magento Luma templates produce heavy HTML — many wrapping divs, deeply nested DOM, extensive class names. A typical PDP weighs 200–400KB of HTML before any product images load. On 4G this isn't catastrophic; on a flaky mobile connection it's painful.

5. The third-party-tag amplifier

This is the dirty secret. Even a well-optimised Luma site falls apart when the marketing team adds:

• Google Tag Manager loading 8–15 third-party tags
• Hotjar / Microsoft Clarity for session recording
• Yotpo / Trustpilot for reviews
• Klaviyo / Bloomreach for marketing automation
• Chat widgets (Intercom, Zendesk, etc.)

Each of these adds JS payload + render-blocking + main-thread work. On Luma, the cumulative drag from third-party tags is often worse than the Magento-shipped JavaScript itself.

Hyvä doesn't magically fix third-party tags — but Hyvä's lighter baseline gives you more headroom before the third-party drag pushes performance below thresholds.

What Hyvä changes, layer by layer

1. JavaScript payload: ~5x reduction

Hyvä replaces Knockout + RequireJS + UI Components with Alpine.js. Alpine is ~15KB gzipped. Total JS payload on a typical Hyvä page lands at 400–700KB — a 5x reduction from default Magento.

The reduction isn't just smaller bundle size. Alpine doesn't have RequireJS's dependency-tree bootstrapping problem — it parses HTML attributes inline. Time to Interactive collapses from "after RequireJS resolves" to "after browser parses HTML."

2. Render pattern: server-rendered, not JS-bound

Hyvä leans heavily on server-rendered HTML. Most page content is in the HTML response, not added by JavaScript after page load. Alpine reactivity is for interactivity (clicks, hover states, dropdowns) — not for rendering the initial content.

On mobile, this means First Contentful Paint and Largest Contentful Paint both happen dramatically faster because they don't wait for JavaScript to populate the DOM.

3. Knockout view models: gone

There are no Knockout view models. There are Alpine components, but they're a tenth the size of equivalent Knockout view models and don't have the bootstrap overhead. The mini-cart icon updates because Alpine fires on a custom event; not because a Knockout subscription fires after a requirejs dependency resolves.

4. Template HTML: cleaner, lighter

Hyvä templates use Tailwind utility classes instead of LESS-BEM class names. This results in slightly more readable class strings in the HTML but dramatically fewer wrapping divs because Tailwind composes layouts inline rather than relying on nested wrapper components. Typical Hyvä HTML is 30–50% lighter than equivalent Luma HTML for the same visual output.

5. Third-party tags: more headroom

Hyvä doesn't change how third-party tags work, but the lighter Magento baseline means you have more performance budget for third-party drag before crossing the Lighthouse 90 threshold. In practice: a Luma site at Lighthouse 55 might drop to 35 when marketing adds three GTM tags. A Hyvä site at Lighthouse 92 might drop to 85 with the same tags — still in green territory.

Typical performance numbers

For a same-store Luma → Hyvä comparison:

Metric	Luma typical	Hyvä typical
Mobile Lighthouse Performance	30–55	80–92
Largest Contentful Paint (LCP)	4.0–7.0 s	1.5–2.5 s
Interaction to Next Paint (INP)	400–900 ms	100–300 ms
Cumulative Layout Shift (CLS)	0.15–0.40	0.00–0.10
Total Blocking Time (TBT)	1500–4000 ms	100–400 ms
JavaScript payload (per page, gzipped)	2.0–4.0 MB	400–700 KB
Time to Interactive (TTI)	6–12 s	2–4 s

These are typical ranges across the Hyvä migrations we've measured. Your numbers will depend on extension count, third-party tag count, and prior Magento config quality.

What Hyvä doesn't fix

Honesty matters. Hyvä is a frontend swap. It doesn't help with:

• Slow Magento backend response (TTFB). If your Magento server is undersized or unindexed, the server response time stays the same after Hyvä. Hyvä is faster in the browser, not faster on the server.
• Large product images. If you're serving 2MB hero images, Hyvä won't compress them. Image optimisation is separate.
• Heavy third-party tag drag. Hyvä gives you more budget but doesn't eliminate the drag.
• Slow database queries on PDP. Slow PDP rendering on the server side stays slow.
• Search relevance issues. Magento's default search is what it is; Hyvä uses the same search backend.

These need separate fixes. The pitch for Hyvä is the JS-payload + render-pattern wins, which are the biggest mobile-specific bottlenecks for most Magento stores.

Beyond Hyvä — the next 10 points of Lighthouse

After Hyvä gets you from 40 to 88, the next 4–7 points to push into 90+ usually come from:

1. Critical CSS inlining — server-render the above-the-fold CSS so first paint doesn't wait for the CSS file
2. Font optimisation — font-display: swap, font preload for critical fonts, fewer font weights
3. Image priority hints — fetchpriority="high" on the LCP image, proper srcset for responsive images
4. Third-party tag audit — defer non-critical tags via GTM, move analytics server-side via Stape
5. JavaScript code splitting — lazy-load anything below the fold

This is standard performance tuning that applies to any modern site. Hyvä makes it possible to hit the targets; doesn't do it automatically.

What about Hyvä Checkout?

The checkout page on default Magento is the single worst-performing surface — multi-step flow with heavy Knockout JS and zero parallelism. Mobile Lighthouse on Magento default checkout often scores in the 20s.

Hyvä Checkout (a separate product from Hyvä Theme) rebuilds the checkout as a one-page Alpine.js flow. Mobile Lighthouse on Hyvä Checkout typically scores 88–95. Mobile checkout completion rate lifts 8–15% across implementations.

If your mobile checkout is your conversion bottleneck, Hyvä Checkout is the single highest-ROI Hyvä investment.

The bottom line

Magento's mobile performance problem is well-understood: JavaScript payload + render-blocking pattern + Knockout overhead. Hyvä addresses each of those by replacing the frontend layer with a fundamentally lighter stack.

Migration costs £12k–£35k and takes 6–10 weeks. Mobile Lighthouse improvement is typically +35 points. Mobile checkout completion lift (with Hyvä Checkout) is typically +8–15%.

For a Magento store doing £1M+ in annual revenue with mobile-heavy traffic, the migration pays back in 6–9 months on conversion + SEO lift alone.

Next steps

• See the Hyvä migration service page
• Read Why your Magento Lighthouse score is stuck at 40 for the perf-tuning checklist
• Read Magento Core Web Vitals failing? Here's the fix for the CWV-specific guide
• Book a scoping call for a fixed-price quote