Can Hyvä improve Core Web Vitals on a Magento 2 store? Yes, and usually by a margin that surprises people the first time they see it. I'm Kishan Savaliya, an Adobe-Certified Magento 2 + Hyvä developer (cert September 2021). I have shipped Luma→Hyvä migrations for stores on Magento 2.4.4 — 2.4.9, and the Core Web Vitals shift is the single most repeatable win in the Magento ecosystem right now.

Can Hyvä improve Core Web Vitals? Short answer

Yes. On the same Magento backend, the same product catalog, and the same hosting tier, swapping Luma for Hyvä moves Largest Contentful Paint (LCP), Interaction to Next Paint (INP), and Cumulative Layout Shift (CLS) into the "Good" CrUX band on mobile in the vast majority of cases. The cause is architectural: Luma ships ~2MB of JS that has to parse, compile, and execute before the page becomes interactive. Hyvä ships under 100KB of JS for the same page, because it replaced Knockout.js + RequireJS + jQuery with Alpine.js and Tailwind.

That single architectural swap collapses the three biggest culprits behind poor mobile Core Web Vitals: main-thread work, parse-time, and execution-time of legacy JS bundles.

Why Luma is structurally slow at Core Web Vitals

Default Magento Luma is not slow because of bad engineering — it is slow because the architecture was designed in 2014 for desktop performance budgets. The frontend ships:

• RequireJS with hundreds of asynchronous module fetches on first paint.
• Knockout.js for customer-data binding (cart, mini-cart, wishlist) plus the full jQuery + jQuery UI stack.
• ~2MB of uncompressed JS, ~600–900KB gzipped, on most catalog/PDP pages.
• Heavy LESS compiled into 200–400KB of CSS per scope, much of it unused on any given page.

On a mid-range Android phone on a throttled 3G profile (the Lighthouse default for mobile), Luma routinely posts mobile LCP between 5 and 10 seconds, INP between 400 and 800 milliseconds, and a Total Blocking Time over 3 seconds. Those are not numbers you can minify or cache your way out of.

LCP on Hyvä — what to expect

LCP on Hyvä typically lands between 1.5 and 3 seconds on mobile, on the same hardware, same backend, same images. Why? Three reasons:

• No render-blocking RequireJS chain. Alpine.js is a 15KB module that does not block the critical render path.
• Tailwind purged to ~20KB of CSS per page, inlined for the critical fold.
• Native lazy-loading for below-the-fold images, plus correctly sized srcset attributes baked into the catalog templates.

If LCP on Hyvä is still above 3s after migration, the bottleneck is almost always TTFB (slow PHP / unwarmed FPC), an oversized hero image, or a render-blocking third-party tag injected before the LCP element. None of those are Hyvä's fault, but all of them are fixable in a tune-up sprint. See my LCP / INP / CLS recipe for the exact checklist.

INP on Hyvä — the biggest improvement

Interaction to Next Paint is where Hyvä shines hardest. Luma's INP problem is structural: every tap on the mini-cart, every "add to cart" button, every filter on a layered-navigation page goes through Knockout's customer-data UI component, which queues against jQuery's event loop. On a mid-range Android, that interaction can easily take 400–800ms to paint a response.

Hyvä replaces this with Alpine.js, which is a 15KB reactive framework that runs directly on the DOM. The same mini-cart interaction on Hyvä is typically 80–200ms. That is the difference between an INP rating of "Poor" and "Good" in the Chrome User Experience Report.

CLS on Hyvä — basically solved

Cumulative Layout Shift on Luma is usually caused by three things: lazy-loaded product images without reserved aspect ratios, customer-data sections that paint into the header after first paint, and font swaps from late-loaded Google Fonts. Luma stores I audit typically post CLS between 0.15 and 0.35 on mobile catalog pages.

Hyvä reserves image space with explicit aspect ratios on every product card, ships fonts with font-display: swap from the start, and binds customer-data with Alpine without re-layout. Typical CLS post-migration: under 0.05, often 0.00 on PLP and PDP. CLS is the metric that requires the least manual tuning after migration.

What still hurts Core Web Vitals even on Hyvä

Hyvä is the frontend. It is not a magic wand. After a clean migration I still see CWV problems caused by:

• TTFB above 600ms — slow PHP-FPM, missing Redis cache, or unwarmed FPC. Hyvä does not change your backend.
• Google Tag Manager + multiple tags firing on first paint. GTM commonly adds 1–2 seconds of main-thread work.
• Live chat widgets (Intercom, Tawk.to, Drift) loaded synchronously — these inject 50–150KB of JS each.
• Oversized hero images — a 3MB PNG hero kills LCP no matter what theme is rendering it.
• Microsoft Clarity, Hotjar, or session-replay scripts loaded on first paint. Defer them.
• Embedded YouTube/Vimeo iframes on the homepage hero — use a thumbnail-first lazy-load pattern instead.

Every one of those is fixable, and most of them get cleaned up during a Core Web Vitals tune-up sprint after the Hyvä migration lands.

How I (Kishan Savaliya) tune Core Web Vitals on Hyvä stores

My standard Hyvä CWV tune-up checklist, after the migration is live:

1. Run Lighthouse mobile (throttled 4G) for the homepage, a category page, and a PDP. Capture a baseline.
2. Audit third-party tags. Defer everything that isn't required for LCP. GTM, Clarity, chat widgets all go behind requestIdleCallback or a 3-second timer.
3. Inspect the LCP element. If it is an image, confirm fetchpriority="high" and a properly sized srcset. If it is text, confirm font-display: swap.
4. Convert remaining JPEG/PNG product images to WebP via Magento's image processor.
5. Confirm Redis FPC + Redis session, and a warm-cache hit rate above 90% on the homepage.
6. Verify CrUX field data after 28 days. Lighthouse is a synthetic lab — CrUX is what Google ranks on.

The full ladder is in my Luma → Hyvä migration playbook. If you want the synthetic-vs-field-data deep dive, the TTFB optimization case study walks through the backend half of the same problem.

Frequently asked questions

Will Hyvä alone get me into the "Good" CrUX band?

On most stores, yes — for LCP and CLS within 28 days of launch, and for INP almost immediately. The exception is stores with severe TTFB problems (above 1s) or heavy third-party tag stacks. Those need a separate sprint.

How quickly do Core Web Vitals improvements show up in CrUX?

CrUX uses a 28-day rolling window. You will see real-user field data shift within 14 days of launch and stabilise by day 28. Synthetic lab tools (Lighthouse, PageSpeed Insights) show the improvement instantly.

Does Hyvä help desktop Core Web Vitals or only mobile?

Both, but the desktop delta is smaller. Luma desktop LCP is often already 2–3s; Hyvä trims it to 0.8–1.5s. Mobile is where the dramatic 5–10s → 1.5–3s shift happens, because mobile is CPU-bound, not bandwidth-bound.

Can I keep my third-party extensions when I migrate to Hyvä?

Backend-only extensions (shipping, payment, ERP sync) port over with zero changes. Frontend extensions with Knockout/RequireJS templates need a Hyvä-compatible variant, a Hyvä compatibility module, or a fallback layer. Check the Hyvä compatibility checker before migration.

Does Hyvä work with Magento 2.4.9?

Yes — Hyvä supports Magento 2.4.4 — 2.4.9 and PHP 8.1 — 8.4. The Hyvä team ships compatibility updates within days of each new Magento release.

How does Hyvä affect INP specifically?

INP measures the latency of the slowest interaction during a page view. Luma's slowest interaction is almost always the mini-cart update (Knockout customer-data round-trip), which on a mid-range Android takes 400–800ms. Hyvä's Alpine.js-driven mini-cart updates in 80–200ms. That single change usually moves a store from "Poor" to "Good" on INP.

What CLS issues survive a Hyvä migration?

Almost none, but watch for: late-injected GTM banners (cookie consent), customer-data sections in custom-built header components, and any third-party widget that injects DOM after first paint. All three are fixable with explicit space reservations.

Will Hyvä help my SEO rankings directly?

Indirectly. Core Web Vitals is a confirmed Google ranking signal. Going from "Poor" to "Good" on mobile CWV won't 10x your rankings overnight, but it removes a tiebreaker penalty and usually surfaces a 5–15% organic uplift over 60–90 days. Combined with the technical SEO win from Magento vs Shopify on schema and hreflang, the compounding effect is real.

Can I A/B test Hyvä against Luma before committing?

Yes. Hyvä installs in a sibling theme slot, so you can route a percentage of traffic to it via Cloudflare Workers or a load balancer. Most migrations I run start with a 10% canary for two weeks before the full cutover.

How much does a Hyvä migration cost in dev hours?

A clean Luma→Hyvä migration on a standard catalog (50–500 SKUs, 5–10 custom modules, standard checkout) runs roughly ~80h @ $25/hr. Stores with heavy frontend customisations or a checkout extension stack can go to 120–160h. Fixed-fee sprint starts at $2,499.

Where do I see real CrUX data for a store after migration?

Google PageSpeed Insights pulls the same CrUX field data Search Console uses. Search Console → Experience → Core Web Vitals also charts the 28-day trend. CrUX BigQuery dataset is the deepest source.