Core Web Vitals and Conversion: Fixing INP on a Real E-Commerce Site
Why interaction latency became the hard one
Loading metrics improved across the industry because they respond well to obvious fixes — image compression, CDNs, better hosting. Interaction responsiveness is harder because it is caused by JavaScript execution blocking the main thread when a user taps something, and that is a consequence of architecture rather than configuration. On e-commerce sites the failures cluster in the same places: adding to cart, applying a filter, opening a variant selector and typing in search. Those are precisely the interactions that sit closest to revenue.
Measure real users, not your laptop
Lab tools on a fast machine over office wifi will tell you everything is fine. Field data from real devices — mid-range Android phones on mobile networks, which is what a large share of shoppers in Europe and the Gulf are actually using — tells a different story. Collect real user metrics with attribution so you know which element and which script caused the slow interaction. Without attribution you are optimising blind, and teams routinely spend a sprint speeding up something that was never the bottleneck.
Third-party tags are usually the biggest single cause
A typical retail site carries analytics, tag management, a consent banner, a chat widget, a personalisation script, retargeting pixels and a review platform. Each was added by someone with a good reason and nobody owns the total. Audit what is loaded, find who uses each tag, and remove what nobody can defend — there is always something running for a campaign that ended two years ago. For what remains, defer non-essential scripts until after interaction and load them off the critical path.
Break up long tasks in your own code
Where your own JavaScript is the problem, the fix is usually to stop doing everything synchronously in the event handler. Update the visible state first, then yield to let the browser paint, then do the heavier work. Move expensive computation off the main thread where it is genuinely heavy. And check for the classic e-commerce anti-pattern where clicking add-to-cart triggers a full client-side re-render of a large product grid because cart state sits at the top of the component tree.
Hydration cost on rendered pages
Server-rendered pages that ship a large JavaScript bundle to make everything interactive can look fast and feel unresponsive, because the page is painted but not yet wired up. Reducing that means shipping less JavaScript: making static sections genuinely static, loading interactive components only where they are needed, and being disciplined about what actually requires client-side state. On a product listing page, the filters need interactivity; the product cards mostly do not.
Tie it to money so it stays funded
Performance work competes with features and loses unless someone connects it to revenue. Segment your analytics by interaction latency and compare conversion rates between the fast and slow cohorts on your own site. The gap is usually large enough to make the business case by itself, and it turns performance from an engineering preference into a number the commercial team cares about defending.
Have a project that needs this kind of thinking?
Let's talk through what you're building — free consultation, no commitment.
Get in Touch