Magento Core Web Vitals: How Hyva Actually Fixes Them

Magento 2's Core Web Vitals problem is one of the most predictable failure modes in ecommerce. The default Luma frontend ships around 1.5 to 2.5 MB of JavaScript to the storefront before any third-party tracking runs. On a mid-tier mobile device on a 4G connection, that JS bundle alone can push LCP past 4 seconds and INP into the high hundreds of milliseconds. INP became the third Core Web Vital (replacing FID) on 12 March 2024, and Luma stores were hit hard by the metric change.

This guide is about what genuinely fixes the problem. We've audited dozens of Magento stores and shipped Core Web Vitals improvements across most of them. The list below is what actually works, in rough order of impact.

Why default Magento fails the test

The specific causes are well-known to anyone who's spent time inside a Luma codebase:

• RequireJS. Magento ships every JS module in your storefront as an AMD-loaded RequireJS file. The browser has to fetch, parse, and resolve a dependency tree of dozens to hundreds of files. This is the single biggest cause of slow Time to Interactive.
• Knockout.js. Luma's JS framework. Knockout was modern in 2015 and is now slow by modern standards on cart, mini-cart, and checkout interactions. INP suffers here.
• jQuery and jQuery UI. Still shipped, still parsed, still adding kilobytes to every page.
• Magento's bundling. The default JS bundler produces output that's both larger and more fragmented than you'd want. Static content deploy doesn't fix this on its own.
• Layout XML JavaScript loading. Layout XML pulls in JS modules per page, often more than the page actually needs.

None of these are fixed by squeezing image sizes, switching CDNs, or tuning your cache. They're frontend architecture problems and they need a frontend architecture answer.

Intervention 1: Hyva, the frontend

The biggest single lever, and the one that brings everything else into reach. Hyva ditches RequireJS, Knockout, and jQuery, replacing the entire frontend with Tailwind CSS and Alpine.js. Total JavaScript on a typical Hyva homepage is 50 to 200 KB, versus 1.5 to 2.5 MB on Luma. That's an order of magnitude reduction.

Measured impact, averaged across UK stores we've worked on:

• Mobile Lighthouse score: from 25-45 to 85-95
• LCP: from 3.5-6s to 1.4-2.4s
• INP: from 250-500ms to 80-200ms
• Total JavaScript: down 80 to 90%

Hyva alone gets most stores from failing CWV to passing CWV. The remaining wins below close the gap to comfortably-passing.

The cost and how to plan the migration is covered in detail in the Hyva cost guide and the migration guide.

Intervention 2: image strategy

Magento's default image handling is unhelpful. PDPs and category pages typically ship full-resolution images regardless of the device viewport. Until you fix this, your LCP element on a mobile PDP is your hero product image, and it's larger than it needs to be by a factor of three or four.

The realistic fix is:

• Convert your image strategy to WebP (or AVIF if your audience supports it). Magento 2 doesn't accept WebP uploads in the admin out of the box, so you need a community module (Magefan, MagestyApps, or Yireo Webp2 are the common picks) to handle the conversion pipeline. Historic JPEGs and PNGs need bulk converting too.
• Serve responsive images via picture with multiple sources at different breakpoints. Hyva does this by default in the standard theme. Luma needs custom work.
• Use an image CDN (Cloudflare Images, ImageKit, Cloudinary, or a self-hosted service like Imgproxy) to do on-the-fly resizing instead of generating cached files for every size.
• Preload the LCP image. link rel="preload" as="image" for the above-the-fold hero. Massive impact, easy win.
• Lazy-load everything below the fold. Native loading="lazy" works fine.

Done properly, this typically gets you another 0.4 to 1.0 second off mobile LCP.

Intervention 3: hosting and Varnish

If your hosting is wrong, no amount of frontend optimisation will fix it. The signs:

• Time to First Byte over 800ms consistently
• Sustained CPU usage above 70% on the app server during peak
• Database queries showing up in your Magento profiler that take more than 100ms each
• No Varnish, or Varnish caching ratios under 80%

What good looks like for a UK mid-market Magento store:

• Dedicated hosting (not shared) with sized headroom for Black Friday
• Varnish in front of Magento with a tuned config and ESI for dynamic blocks
• PHP 8.2 or 8.3 with OPcache properly sized
• MySQL 8.0+ with sensible InnoDB buffer pool
• Redis for cache and session storage, not file-system
• A real CDN for static assets (Cloudflare, Fastly, CloudFront)

Done properly, hosting alone moves TTFB from 700-1500ms to under 200ms, which feeds directly into LCP.

Intervention 4: third-party scripts

The dark matter of ecommerce performance. Stores accumulate tags over years: GA4, GTM, Meta pixel, TikTok pixel, Pinterest, reviews vendors, email capture, chat widgets, AB testing, affiliate tracking, heatmap recorders. By the time you measure, the storefront is loading 40+ third-party scripts and each one is doing some work on every page.

The honest reality is that most of these are forgotten about by marketing, defended on the grounds of "we need it for attribution," and never actually audited. Pick a quarter, run the audit, and turn off everything that can't justify its existence to the bottom line.

Specifically:

• Move everything possible into Google Tag Manager, then audit GTM for actually-unused tags.
• Defer all non-essential scripts until interaction or page idle.
• Server-side tag your most critical events (purchases, signups). Reduces client-side load and improves attribution accuracy.
• Kill chat widgets you're not actively staffing.
• Kill the heatmap recorder unless someone is actually looking at the recordings this quarter.

This is the intervention that's almost free and routinely cuts another 200 to 400ms off LCP and 50 to 150ms off INP.

What doesn't help as much as you'd think

Things merchants spend money on that don't move the needle:

• "Critical CSS" tooling. Helps Luma a small amount, but most modern browsers handle CSS prioritisation well. The 50ms you'll save isn't worth the maintenance overhead.
• Brotli over Gzip. Real but small. Worth enabling, not worth obsessing over.
• HTTP/3. Mostly already on if you're behind Cloudflare or Fastly. Not a meaningful lever on its own.
• Switching CDNs. Unless your current CDN is genuinely broken, the differences between them are within margin of error for Core Web Vitals.

None of these are wrong to do. They're just not what's holding your score down.

The realistic target

For a typical UK mid-market Magento 2 + Hyva store with the four interventions applied:

• Mobile Lighthouse: 85 to 95
• LCP: 1.2 to 2.0 seconds
• INP: 80 to 150 milliseconds
• CLS: under 0.05

You're past Core Web Vitals comfortably and into "no longer the slowest part of your customer experience" territory. Anything beyond that is squeezing diminishing returns, and the budget is usually better spent on conversion testing, content, or product than on shaving more milliseconds.