Core Web Vitals is a bad name for a good idea. The metrics measure three things a shopper experiences directly — how long until the page looks ready, how long until it responds to a tap, and whether it moves under their finger — and Google reports them in milliseconds, which is precisely the unit least likely to get a project funded.
This is the translation. Three metrics, what each one costs you, and the Magento-specific reason it is usually failing.
Use field data, not lab data. Search Console's Core Web Vitals report shows what real visitors on real devices experienced over a rolling 28 days. A Lighthouse run on your laptop shows what one simulated visitor experienced once.
LCP: How Long Until the Page Looks Ready
Largest Contentful Paint measures when the biggest visible element — usually a hero image or a product photo — finishes rendering. Google's threshold is 2.5 seconds for a good experience, 4 seconds before it is rated poor.
In commercial terms, LCP is the metric that governs whether a visitor from a paid ad ever sees your product. Someone who tapped a Shopping ad on a phone on mobile data has a short and unsentimental attention span; a store that takes four seconds to show a product image is paying for clicks it does not convert. If you run paid acquisition, LCP is a media-efficiency metric before it is a technical one.
The Usual Magento Causes
- A slow time-to-first-byte. Full-page cache misses, an undersized database, or a Varnish configuration that stopped matching your URL structure. Nothing in the front end can hide a slow server response.
- Unoptimised catalogue imagery. Product photos uploaded at print resolution and resized in the browser. Magento's image processing helps, but it will not save you from a 4MB source file.
- Render-blocking CSS and JavaScript. Luma's default bundle blocks the first paint; so does almost every third-party script added to the head.
- Web fonts without
font-display: swap. The text is there, ready, invisible, waiting for a font file.
The order matters. Fixing images while the server takes 1.8 seconds to respond is polishing the wrong surface. Measure time-to-first-byte first; if it is above about 600ms, that is your project.
INP: How Long Until the Page Responds
Interaction to Next Paint measures the delay between a shopper tapping something and the page visibly reacting. Good is under 200 milliseconds; anything past 500ms is rated poor and feels, to a customer, like the site is broken.
INP is the metric that costs you carts rather than sessions. It is worst exactly where it hurts most: swatch selection on a configurable product, quantity changes in a mini-cart, filter clicks on a category page, and the shipping-method step in checkout. A shopper who taps a size swatch twice because nothing happened the first time has just added a duplicate line to your cart or, more often, left.
The Usual Magento Causes
- Knockout.js re-rendering on Luma. The mini-cart and checkout are the heaviest Knockout surfaces in the theme, which is why they are the slowest to respond.
- Third-party tag managers and personalisation scripts running long tasks on the main thread while the shopper is trying to use the page.
- Layered navigation that reloads the full page on every filter click instead of updating in place.
- Chat widgets and review widgets that initialise on load rather than on interaction.
INP is the metric most likely to be caused by something you bought rather than something you built. Audit the third-party scripts before you touch the theme.
CLS: Whether the Page Moves Under Their Finger
Cumulative Layout Shift measures unexpected movement — content jumping as images, banners or widgets load in late. Good is below 0.1.
CLS costs you in two ways, one obvious and one not. The obvious one is misclicks: a shopper taps Add to basket, a promotional banner loads above it, and they have tapped something else. The subtle one is trust. A page that jerks about while loading reads as amateur, and on a first visit that impression is doing quantifiable work against your conversion rate.
The Usual Magento Causes
- Images without width and height attributes, so the browser cannot reserve space before the file arrives.
- CMS blocks and promotional banners injected above the fold after first paint.
- Cookie and consent banners that push the page down instead of overlaying it.
- Third-party widgets — reviews, trust badges, chat — mounting into containers with no reserved height. This one is almost universal, and almost always trivially fixable.
CLS is the cheapest of the three metrics to fix and the one most often left failing, because it does not feel like a performance problem. It is usually a few dozen lines of CSS reserving boxes that should always have been reserved.
How to Prioritise When All Three Are Failing
They rarely fail equally, and they do not deserve equal attention. Our order:
- CLS first. Cheapest to fix, fastest to verify, and it is pure downside removal — there is no trade-off to weigh.
- LCP second, starting with time-to-first-byte and imagery. This is where acquisition spend is leaking.
- INP last, because it is the hardest and most likely to require removing something a stakeholder likes.
Segment by template before you start. Most Magento stores we audit have a homepage that passes and category pages that fail, and the work needed on each is different. Sitewide averages hide the problem you are actually paying for.
What This Looks Like in Practice
When we took on Careshop's Magento store, the presenting complaint was the usual one — the site felt slow — and the underlying causes were spread across all three metrics and the server behind them. The sequence above is not a theoretical ordering; it is the order that produced results without a storefront rebuild.
If the remaining gap after that work is still large, the question becomes a front-end one, and we have written a costed framework for choosing between Hyvä, a PWA and staying on Luma. Do not start there. Start with the measurement.
Setting an Honest Target
Chasing a perfect Lighthouse score is a poor use of an engineering budget. Google's ranking signal is a pass/fail assessment at the 75th percentile of real visits — you need the majority of real sessions to be good, on the templates that matter. That is an achievable target on Magento without rebuilding anything.
So set the goal as: category and product templates passing all three metrics in field data on mobile, sustained over a full 28-day window. That is a target an engineering team can be held to and a finance team can understand. A score out of 100 measured on a desktop is neither.
This is the work our page speed optimisation engagements are built around, and for retail catalogues it is usually the highest-return technical work available in any given year.
Frequently asked questions
Do Core Web Vitals actually affect Google rankings?
They are a confirmed ranking signal, but a comparatively light one — relevance and content quality dominate. The stronger commercial argument is conversion: the same slowness that fails the assessment is costing you sales regardless of what it does to your position.
Why does Search Console disagree with my Lighthouse score?
They measure different things. Lighthouse is a lab test on a simulated device; Search Console reports field data from real Chrome users over a rolling 28 days. Field data is the one Google uses and the one that reflects your actual customers. Expect the two to differ, and trust the field.
How long after a fix before the numbers move?
The field-data window is 28 days, so a fix deployed today will not be fully reflected for four weeks and the trend is not trustworthy until six. Resist judging the work — or reverting it — inside the first month.
Which metric should a Magento store fix first?
CLS, almost always. It is the cheapest to fix, the quickest to verify, and it usually comes down to reserving space for images and third-party widgets. It is also the metric most often left failing because it does not feel like a speed problem.
Can we pass Core Web Vitals on the default Luma theme?
Yes. It takes disciplined work — extension auditing, deferred JavaScript, an image pipeline, cache and server tuning — but a passing assessment on Luma is a realistic target for most catalogues. A theme migration raises the ceiling; it is not the entry price.
Find Out What Yours Is Costing You
We will audit your field data by template, identify which of the three metrics is doing the damage, and tell you what it would take to fix — with the extension estate accounted for rather than assumed away. Talk to our team; we reply within a business day.