Magento Core Web Vitals: How to Pass LCP, INP and CLS
Magento Core Web Vitals: how to pass LCP, INP and CLS
A Magento store passes Core Web Vitals when, for real Chrome users at the 75th percentile, Largest Contentful Paint lands under 2.5 seconds, Interaction to Next Paint under 200 milliseconds and Cumulative Layout Shift under 0.1. Default Magento on the Luma theme rarely passes all three without deliberate work — the fixes below, applied in the order given, are how you get there.
These are the same fixes engineered into the AgenticEcom Suite storefront, but every one of them applies to an ordinary Magento 2 store.
The three metrics and what counts as a pass
| Metric | What it measures | Pass threshold | Where Magento usually fails it |
|---|---|---|---|
| LCP (Largest Contentful Paint) | How quickly the main content — usually a hero or product image — appears | Under 2.5s | Slow server response before anything starts, then a large unoptimised image |
| INP (Interaction to Next Paint) | How quickly the page responds to taps, clicks and keypresses | Under 200ms | Heavy RequireJS bundles and third-party scripts occupying the main thread |
| CLS (Cumulative Layout Shift) | How much the layout jumps while loading | Under 0.1 | Images without dimensions, late-loading banners and reviews blocks |
Two details matter. First, Google assesses field data — what real visitors experienced over the previous 28 days — not the lab score you see when you run a test. Second, the pass mark is the 75th percentile: three quarters of your visitors must clear each threshold, on mobile and desktop judged separately.
Check your real numbers before changing anything
Open PageSpeed Insights and look at the top section, "Discover what your real users are experiencing" — that is the field data Google actually uses. Google Search Console's Core Web Vitals report shows the same data grouped by URL pattern, which tells you whether the problem is the homepage, category pages or product pages. If your store is too small to have field data, the lab diagnostics below the fold are still the right map of what to fix; they are simply not the ranking input themselves.
The fixes, in priority order
- Make the server answer quickly. Nothing downstream can rescue a slow first byte. Confirm the store runs in production mode (
bin/magento deploy:mode:show, and if not,bin/magento deploy:mode:set production). Switch full-page caching to Varnish under Stores → Configuration → Advanced → System → Full Page Cache, move cache and sessions to Redis (configured inapp/etc/env.phpviabin/magento setup:config:set), and make sure cron is actually running — a stalled indexer forces expensive live queries on every page. - Fix the images. The LCP element on most Magento pages is an image. Serve modern formats (WebP or AVIF), size images to what the layout actually displays, and give every image explicit width and height attributes so the browser reserves space. The practical routes are covered in Magento 2 WebP images.
- Cut render-blocking CSS and JavaScript. Enable minification — in developer mode the switches live under Stores → Configuration → Advanced → Developer, and in production you set them directly:
bin/magento config:set dev/js/minify_files 1andbin/magento config:set dev/css/minify_files 1, followed bybin/magento cache:flush. Leave Magento's built-in JavaScript bundling off unless you have measured a benefit; it produces one very large file that typically delays first paint on HTTP/2. Then audit third-party scripts — tag managers, chat widgets and trackers are the usual INP offenders. - Stop the layout shifting. Reserve space for anything that arrives late: image dimensions, fixed-height slots for promo banners and review widgets, and
font-display: swapwith a fallback font sized close to the web font. CLS is usually the easiest of the three to bring under 0.1, because every shift is visible and traceable in the PageSpeed Insights diagnostics. - Lazy-load below the fold — and only below the fold. Native
loading="lazy"on off-screen images cuts the initial payload. Never lazy-load the LCP image itself; that is one of the most common self-inflicted LCP regressions on Magento stores. - Change the architecture when tuning stops paying. Steps 1–5 will move a Luma store a long way, but the theme still ships a large JavaScript layer that caps how far you can go. A headless front end such as the AgenticEcom Astro storefront serves pre-rendered HTML with very little JavaScript from a CDN edge, which addresses LCP, INP and CLS at the structural level rather than metric by metric. What that stack looks like in practice is set out in Magento on a Cloudflare edge stack.
What passing actually looks like
A live client store on this stack — over 1,000 products on Magento Open Source with an Astro front end — passes all three Core Web Vitals in Google's field data, measured July 2026. That is the standard worth aiming at, because Core Web Vitals feed three things at once: Google rankings, conversion rate, and how cleanly your store can be read by automated shoppers. If your scores are a long way off, start with the diagnosis in why your Magento store is slow before spending on fixes.
And if you would rather not spend months tuning a theme, the Astro storefront is the packaged version of everything above — a front end where passing Core Web Vitals is the default state, not a project.
FAQ
What are good Core Web Vitals scores for a Magento store?
The pass thresholds are the same for every site: LCP under 2.5 seconds, INP under 200 milliseconds and CLS under 0.1, measured at the 75th percentile of real users. Default Magento with the Luma theme usually needs caching, image and JavaScript work to reach them.
Does Google use my lab score or my field data?
Field data. The ranking input is what real Chrome users experienced over the previous 28 days, shown at the top of PageSpeed Insights and in Search Console's Core Web Vitals report. The lab score is a diagnostic tool for finding problems, not the number Google judges you on.
Why is my Magento store failing Core Web Vitals?
Almost always some combination of slow server response, oversized images, render-blocking CSS and JavaScript from the theme, and late-loading content that shifts the layout. Fixing caching and images first gives the largest gains; changing to a headless front end removes most of the remaining ceiling.
Can a Magento store genuinely pass all three Core Web Vitals?
Yes. A live client store on this stack passes LCP, INP and CLS in Google's field data on a catalogue of over 1,000 products (measured July 2026), using a headless Astro front end that serves pre-rendered HTML from the edge. A well-tuned traditional theme can pass too; it simply takes more ongoing effort to keep it there.
