Fixing INP — the Core Web Vital that fails on cheap phones

Load speed gets all the attention. Interaction speed is where Indian sites actually fail, because the metric measures what happens after the page is up — the tap on “add to cart”, the filter, the accordion — and it measures it on the device the user is holding.

That device is frequently a mid-range Android phone with a fraction of the processing power of the machine your site was built on. Interaction to Next Paint is unforgiving about that gap.

This is the technical companion to why your D2C store is bleeding conversions. That post covers what to fix; this one covers how.

What INP measures

The delay between a user interaction and the next visual update on screen. Every tap, click and key press is measured, and the reported score is roughly the worst of them across the visit, at the 75th percentile of your real users.

Three parts make up the delay:

Input delay — the main thread was already busy, so your handler could not start. Processing time — your handler running. Presentation delay — the browser rendering the result.

Most failures are the first and second. Something else was hogging the thread, or your handler did too much.

Finding the guilty interaction

Do not guess. Measure in this order.

1. Get field data. The Chrome UX report or a real-user monitoring script tells you the actual score and — more usefully — which element is responsible. A single button is often responsible for most of a bad score.

2. Throttle your own device. In the performance panel, set CPU throttling to 4x or 6x slowdown. Your desktop now behaves roughly like a budget Android phone. Interactions that felt instant will suddenly feel awful, which is the point.

3. Record the interaction. Start a performance recording, perform the tap, stop. Look for long tasks — anything over 50 milliseconds — and read what is inside them. The answer is usually visible within two minutes.

The five common causes and their fixes

1. Third-party tags eating the main thread

Analytics, chat widgets, heat maps, pixels, review embeds. Each one loads script that competes with your interface for the same thread.

Fix: audit what is actually installed — there is almost always a tag nobody remembers adding. Load whatever survives after interaction rather than on page load. Defer the chat widget until the user scrolls or shows intent. A live chat bubble that costs you checkout completions is a bad trade.

2. A state update that re-renders everything

Tapping a filter updates a value at the top of your component tree, and the whole page recalculates. On a fast laptop, 30 milliseconds. On a budget phone, 400.

Fix: keep state local to the part of the interface that needs it. Split large lists into virtualised windows. Memoise expensive derived values. In practice, the single biggest win is moving state down the tree rather than up.

3. Doing work synchronously inside the handler

Sorting a thousand items, parsing a large payload, formatting dates for an entire table — all inside the click handler, before anything is painted.

Fix: paint first, work second. Update the visible state immediately, then perform the heavy work after yielding to the browser. Users tolerate a spinner far better than a dead button.

4. Animating the wrong properties

Animating width, height, top or left forces layout on every frame. On constrained hardware that is a guaranteed stutter.

Fix: animate transform and opacity only. Both can be handled off the main thread. This is a mechanical change with an outsized payoff.

5. Hydration on a content-heavy page

A framework attaching interactivity to every component on load, before the user has touched anything. The page looks ready and is not.

Fix: ship less JavaScript. Static HTML for content, interactive components only where interaction happens. This is architectural rather than a tweak, but it is the reason we build content sites the way we do — and it is the same choice that keeps pages readable to AI crawlers, as covered in getting cited by AI search.

A one-day plan

Morning: pull field data, identify the two worst interactions, audit third-party tags and remove or defer everything not essential.

Afternoon: fix the worst handler — paint first, defer heavy work — and move any animation onto transform and opacity.

Before you leave: deploy, then wait. Field data updates over days, not minutes. Do not judge the fix on a lab score.

Most sites we audit go from poor to good on the two worst interactions alone. The long tail matters less than founders expect.

Set a budget so it stays fixed

Performance work decays. Someone adds a tag, a dependency grows, a new feature ships with a heavy component.

Three defences: a size budget checked on every build, a monthly look at field data, and a rule that any new third-party script must be justified by someone willing to own it. That last rule kills more bloat than any technical measure.

The commercial argument

Interaction responsiveness is not an engineering vanity metric. Dead-feeling taps are abandoned carts, double-submitted forms and support tickets that say “your site is not working” when it is merely slow.

On a store doing meaningful volume, a few percentage points of checkout completion is usually worth more than the entire engineering budget that produced it.

Want the audit run against your live field data, with the fixes shipped? That is a one-week sprint.