A lot of Magento merchants got the same unpleasant surprise. Their store had comfortably passed Core Web Vitals for years. Then, without anyone touching the site, Search Console started reporting failures on mobile. The store had not got slower. The measurement had got honest.
What changed
INP is now the stable responsiveness metric in Core Web Vitals, and it succeeded FID. That sounds like a technical detail and it is not.
FID measured only the delay before the browser began handling your first interaction. If the browser was busy, that delay was recorded, and then measurement stopped. Whatever happened afterwards, however long the page took to actually respond, was invisible.
INP measures the full interaction, and it does so across the whole visit. From the tap to the moment the screen visibly updates. Not just the first one, but effectively the worst one a visitor experiences.
For a static content site the two metrics give similar answers. For a store where people tap filters, swatches and add-to-cart buttons, they give completely different ones.
Why Magento storefronts struggle with it
The default Luma theme leans on a substantial JavaScript stack. Knockout for data binding, RequireJS for module loading, jQuery underneath, plus whatever each extension adds. When a visitor taps a filter on a category page, a chain of that machinery has to run before anything visibly changes.
On a desktop with a fast processor that chain completes quickly enough that nobody notices. On a mid range Android phone, which is what a large share of your traffic actually uses, the same chain takes noticeably longer. INP measures the phone, not the desktop.
The measurement trap
This is where most people get stuck. A Lighthouse or PageSpeed score is a lab test: one simulated device, one connection profile, one moment. Search Console reports field data: what your actual visitors experienced over the past 28 days, across every device and network they happened to be on.
A green lab score and a failing field report are not a contradiction. They are answering different questions. The field report is the one Google uses for ranking, and it is also the one that reflects what your customers lived through.
So when the two disagree, do not go looking for a way to make the lab score match. Go looking for the visitors the lab test does not represent, because that gap is usually where the interesting problem is hiding.
What actually moves INP on Magento
- Find the slow interactions, do not guess them. Field data tells you which page types fail. Profiling in the browser tells you which specific interaction is responsible and what it is waiting on.
- Break up long tasks. A single block of JavaScript that runs for hundreds of milliseconds blocks everything. Splitting it lets the browser respond in between.
- Move third-party tags off the main thread. Marketing tags are a frequent and underestimated cause. Server-side tagging takes that work off the visitor device entirely.
- Reconsider the theme, but only if the measurement says so. If the JavaScript payload itself is the ceiling, a lighter frontend is the structural answer. That is a real project, so make sure it is the right one first.
What good looks like
The passing threshold is 200 milliseconds at the 75th percentile, meaning three quarters of interactions must complete within that. Luma stores frequently sit well above it on mobile category pages. Getting under it is usually achievable without a rebuild, though the last stretch is the expensive part.
One more thing worth knowing: the field report uses a rolling 28 day window. After you fix something, give it a month before you judge the result in Search Console. Measure directly in the meantime so you are not waiting blind.