Guides

Magento Core Web Vitals: How We Get Stores to 90+ and Keep Them There

October 9, 2026 - Alexandru-Manuel Carabus

Core Web Vitals is both a Google ranking signal and one of the clearest conversion levers you have. Here is what the three metrics actually measure, why Magento stores fail them by default, how we get a store past 90 on PageSpeed, and what it takes to keep it there.

Core Web Vitals is one of the few technical metrics that pays you back twice. Google uses it as a ranking signal, so a store that passes ranks better than an identical store that fails. And because the same three metrics measure how fast and stable the page feels to a real shopper, passing them lifts conversion at the same time. Speed is the rare SEO investment that also shows up in your checkout numbers. Here is what the metrics actually measure, why Magento stores tend to fail them out of the box, and how we get a store past 90 and keep it there.

The three metrics, in plain terms

There are three, and each measures a different kind of pain. Largest Contentful Paint (LCP) measures loading: how long until the biggest thing on screen, usually your hero image or product photo, has actually rendered. Google wants that under 2.5 seconds. Interaction to Next Paint (INP), which replaced First Input Delay in 2024, measures responsiveness: when a shopper taps a button, how long until the page visibly reacts. Good is under 200 milliseconds. Cumulative Layout Shift (CLS) measures stability: how much the page jumps around as it loads, the thing that makes you tap the wrong button. Good is under 0.1. Pass all three on real-world data and you are in the green.

Why Magento fails Core Web Vitals by default

It is not that Magento is a slow platform. It is that the default frontend and the typical extension pile-up are slow. Magento's legacy Luma theme ships a heavy JavaScript stack (jQuery, RequireJS, Knockout) that browsers have to download, parse, and execute before the page feels ready. Add large uncompressed images that become your LCP element, render-blocking CSS, and web fonts that arrive late, and you fail LCP before a single extension is installed.

Then come the extensions. Every extension tends to add its own JavaScript and CSS, and a store running thirty or forty of them is loading thirty or forty sets of assets, most of them on every page. On top of that sits the marketing layer: Google Tag Manager, ad pixels, a chat widget, a cookie banner, a reviews script. Each one runs JavaScript on the main thread, and the main thread is exactly what INP measures. This is why a store can have a decent-looking Lighthouse score in the lab and still fail INP for real users: the tags only fire under real interaction.

How we get a store past 90

The single biggest lever is the frontend, and on Magento that means Hyva. Replacing the Luma theme with Hyva (built on Tailwind and Alpine.js, shipping a fraction of the JavaScript) is the largest Core Web Vitals jump available on the platform, because it deletes the root cause rather than optimizing around it. We wrote about why a Hyva store can still be slow when the rest of the stack is neglected in Your Hyva Store Is Still Slow, and about the frontend itself in Hyva Is Now Fully Open Source. If you are still on Luma, this is where the real gains are.

The next lever is images, because your LCP element is almost always an image. That means serving next-generation formats (WebP or AVIF), sizing images correctly for the device instead of shipping a 3000-pixel hero to a phone, lazy-loading everything below the fold, and giving the one above-the-fold LCP image a priority hint so the browser fetches it first. Done properly, image discipline alone can pull a second or more off LCP.

The backend still has to hold up underneath all of that. A fast frontend on a slow server-response time (TTFB) still fails LCP, so full-page caching with Varnish, Redis for sessions and cache, a tuned database, and a CDN in front are not optional. And the marketing tags need governance: defer what can be deferred, load third-party scripts after interaction, and remove the ones nobody can name a reason for. That last step is unglamorous and routinely worth 50 or more INP milliseconds.

One discipline underpins all of it: measure real users, not just the lab. Google ranks on field data (the Chrome User Experience Report, gathered from actual visitors), while Lighthouse in your browser is a diagnostic, not the score that counts. Chasing a perfect 100 in the lab while your field INP sits in the red is the most common way teams waste a performance budget. Fix what field data says is broken, in the order it says it is broken.

What keeping them there actually takes

Core Web Vitals is not a one-time project you finish and forget. Every new extension, every added marketing tag, every large image an editor uploads without thinking can quietly regress it, and by the time it shows up in rankings you have lost weeks. Holding the line takes a performance budget (a hard ceiling on page weight and script count that new work has to fit inside), ongoing field-data monitoring, and the same maintenance discipline that keeps the rest of the store healthy. We laid that cadence out in The Complete Magento Maintenance Guide. Speed you do not maintain is speed you are about to lose.

What this looks like in practice

The clearest example we can share is Vitacom. On the storefront we rebuilt, the Google PageSpeed score went from 12 to 100. That is not a typical starting point and we are not going to pretend 100 is the guaranteed outcome for every store, but it is real and it came from exactly the sequence above: the Hyva frontend did most of the heavy lifting, disciplined images and tag governance did the next slice, and a properly cached backend kept response times down so the frontend gains actually landed for real users.

For most stores the honest target is not a lab-perfect 100, it is field data in the green across all three metrics: LCP under 2.5 seconds, INP under 200 milliseconds, CLS under 0.1, measured on real visitors. That is what Google rewards in rankings and what your shoppers feel at checkout. Landing solidly in the 90s with green field data beats a fragile 100 that regresses the next time someone installs an extension.

Where to start

Start by pulling your own numbers: run your key templates (home, category, product, checkout) through PageSpeed Insights and read the field-data section, not just the lab score. If LCP and INP are in the red and you are still on the Luma frontend, you already know where the first gain is. If you want a second read on which fix returns the most for your specific store, book a free strategy call with LIQUIDLAB and bring your PageSpeed results. We will tell you what is worth doing first, and what is not worth doing at all.