INP Is a Money Metric, Not a Ranking Metric: What the 2025 Field Data Actually Shows

Every performance project starts with the same sentence in the brief: improve Core Web Vitals for SEO. It is the wrong reason to do the work, and it produces the wrong plan. As a ranking input, page experience is a small tiebreaker among many signals, and Google has never claimed otherwise. As a revenue input, the published evidence is considerably stronger and considerably less discussed.

This article uses two sources: the 2025 Web Almanac performance chapter, which reports Chrome UX Report field data across millions of origins, and three case studies published on web.dev by the sites that ran them. Both are public, both are checkable, and between them they answer a more useful question than “will this help us rank”.

Where the web actually stands

The Web Almanac’s July 2025 CrUX snapshot gives the baseline. 48% of sites pass all three Core Web Vitals on mobile and 56% on desktop. Per metric, the picture is far less even than the headline suggests: INP is rated good on 97% of desktop origins and 77% on mobile.

Read those two lines together and an uncomfortable conclusion follows. On desktop, INP is essentially a solved problem. If your team is running desktop interaction profiling as a priority workstream, they are working on the 3%. Meanwhile the aggregate mobile pass rate of 48% is dragged down mostly by LCP, not by INP.

So the honest framing is this. If your goal is to pass the Core Web Vitals assessment, LCP is your blocker. If your goal is to stop losing money on interactions, INP is the one that describes the experience. These are different projects and they are constantly confused with each other.

The three case studies, and what they each actually measured

The strongest available evidence for the commercial case comes from controlled tests published by the businesses themselves. Three are worth reading in full, and one of them is routinely misquoted.

The Rakuten 24 row is the one that needs the caveat, because it circulates widely as an INP result and it is not one. That test ran a 50/50 A/B split on a single landing page for a month, and the metrics it moved were CLS and FID, the vitals of the time. It is excellent evidence that Core Web Vitals work pays for itself. It is not evidence about INP specifically, and anyone presenting it as such has not read the source.

Two further limits worth stating out loud before these numbers reach a slide. All three are single-company results on specific pages in specific markets, published by the companies concerned, which is a category with obvious selection bias: nobody publishes the optimisation that moved nothing. And the ranges are enormous, from 7% to 53%, which tells you the effect size depends entirely on how bad the starting point was. The correct use of these studies is directional confirmation that the mechanism is real, not a forecast of your own uplift.

Why interaction latency converts differently from load latency

LCP and INP fail in different ways, and the commercial consequence is not the same.

A slow load is felt before commitment. The visitor has invested nothing, so they leave, and you see it as a bounce. A slow interaction is felt after commitment. The visitor has chosen a size, opened a filter, tapped add to basket. The intent is already formed, and the delay lands directly on the step that produces revenue. That is why interaction latency shows up in conversion rate rather than in sessions, and why teams that only watch traffic never see it.

It also explains the shape of the redBus result. Their fix was not a rewrite. They stopped syncing every keystroke into global state and synced on blur instead, which cut re-renders. That is a couple of days of work on one component, and it produced a 72% INP improvement and 7% more sales. The pattern generalises: INP problems are usually concentrated in two or three interactions, not spread evenly across a site.

The LCP finding almost nobody acts on

Since LCP is the gating metric for the mobile pass rate, the Almanac’s element breakdown is the most actionable number in the whole chapter. An image is the LCP element on 85.3% of desktop pages and 76.0% on mobile, and 57% of those LCP images are still JPEG.

Which means the single largest performance problem on the web is one image per page, in a format that has had better alternatives available in every major browser for years. Converting the hero image to a modern format, sizing it correctly for the viewport, giving it fetch priority and not lazy-loading it costs an afternoon and does more for the pass rate than most re-architecture proposals.

The reason it does not happen is rarely technical. It is that the image is uploaded by a marketer through a CMS at whatever size came out of the design tool, and nothing in the pipeline is responsible for it. That is a process defect, not a code defect. Our broader guide to Core Web Vitals as a competitive advantage covers the ownership question, which is usually the actual blocker.

Soft navigations: the change that affects single-page apps

There is a long-standing measurement gap in every SPA. INP has historically been measured across the entire page lifetime, so an application where a user navigates through eight views without a full page load reports one INP value covering all of them. The slow interaction on view six is averaged into the same bucket as the fast ones, and the number tells you nothing about where to look.

Chrome has been working on this through a series of origin trials, and per the Chrome documentation on measuring soft navigations, the soft-navigation and interaction-contentful-paint entry types ship unflagged from Chrome 151. The practical effect is that INP can be sliced per soft navigation, so an SPA can finally attribute a bad interaction to a specific view instead of to the application as a whole.

If you run a single-page application, the honest expectation is that your INP will look worse once you can see it properly, not better. That is what discovering a previously averaged-out problem looks like, and it is a good outcome.

How to decide whether this work is worth funding

Performance work competes for budget against features, and it usually loses because it is argued in milliseconds. Argue it in the same units as everything else on the roadmap.

The last row matters more than the rest combined. Every one of the three studies above ran a controlled comparison. If you ship a performance improvement and simply observe that revenue went up afterwards, you have measured your season, not your work.

Where the effort usually pays

• The hero image on templates that carry traffic. Modern format, correct dimensions, high fetch priority, never lazy-loaded. Highest return per hour spent, by a wide margin.
• Third-party scripts on interactive pages. Tag managers, chat widgets, consent tools and heatmaps all compete for the main thread at exactly the moment the user is tapping something.
• The two or three heaviest handlers. Filters, quantity steppers, variant pickers and search-as-you-type are where INP is lost in practice.
• Low-end devices, not your own. The mobile INP gap lives on hardware nobody in the team owns, which is why we wrote separately about site speed on low-end devices.
• Animation that runs on interaction. A transition that looks refined on a development machine can add a hundred milliseconds to the response on a mid-range phone. The trade-offs are in our piece on when microanimations help and when they hurt.

The short version

Field data for 2025 puts Core Web Vitals pass rates at 48% on mobile and 56% on desktop, with INP good on 97% of desktop origins and 77% on mobile. Desktop INP is effectively finished; mobile INP is a real but narrower problem than LCP, which is what actually gates the mobile pass rate, and which is an image in 85.3% of desktop cases and still a JPEG 57% of the time. The published business results are real and they are individual company A/B tests, not benchmarks: redBus moved INP by 72% for 7% more sales, Vodafone moved LCP by 31% for 8%, and the widely quoted Rakuten 24 figures of +33.13% conversion and +53.37% revenue per visitor came from a CLS and FID test, not an INP one.

The practical conclusion is to stop scoping this work as an SEO task with a green score as the deliverable. Measure the field data for the pages that take money, find the two or three interactions that are slow, fix the hero image while you are there, and test the change against a control. When we build online stores and landing pages, the interaction budget is a design constraint from the first template rather than an audit finding six months after launch, because retrofitting responsiveness into a finished front end is the expensive version of this project.