October 6, 2026 · Muhammad Umar · More by Muhammad Umar
Shopify's INP Guide: Where Slow Taps Really Happen
Shopify's theme performance docs break every slow interaction into three measurable phases. Here's what each one means for a theme, and which fix belongs where.
"Poor INP" usually gets treated as a vague JavaScript problem — too many apps, too much script, make it leaner. Shopify's own theme performance documentation disagrees with that framing. It decomposes every interaction into three distinct phases, each with its own causes and its own fix, and the fix for one phase does nothing for the other two.
The metric, and the bar it sets
Interaction to Next Paint (INP) measures how responsive a page feels across an entire visit, not just on first load — it reports the worst (or near-worst) interaction a visitor experiences, assessed at the 75th percentile of that page's visits in the field. Shopify's theme docs and Google's web.dev reference state the identical thresholds: an INP of 200ms or less is good, and anything above 500ms is poor. Nothing in between is fine either — it needs improvement. A variant selector that reflows the whole product form, or a cart drawer that stutters open, is exactly the kind of interaction this metric is built to catch.
Three phases, three different problems
Shopify's guide decomposes every interaction's latency into three sequential phases:
- Input delay — the time between the tap and the browser actually starting the event handler, caused by the main thread already being busy with something else. A long task from a third-party analytics script running at the wrong moment shows up here, not in your own code.
- Processing time — running the event handlers themselves: theme JS, app JS, and any framework code the interaction triggers. A single tap can fire multiple handlers (pointerdown, mousedown, click), and each one's work counts.
- Presentation delay — style recalculation, layout, paint, and compositing after the handler finishes. Large DOM changes and forced synchronous layouts live here.
The practical value of this split is that it tells you where to look before you start changing code. Shopify names concrete theme-specific causes per phase: variant-selector reflows and cart-drawer width/height animations are presentation-delay problems, fixed by batching DOM writes with requestAnimationFrame or switching the animation to transform: translateX() so it's GPU-accelerated and doesn't touch layout. Mega menus that insert large amounts of DOM on hover are also a presentation-delay issue — toggling the visibility of already-rendered, hidden markup is far cheaper than building it on demand. Third-party scripts with synchronous click handlers, on the other hand, add input delay to every interaction on the page, regardless of what that interaction is.
Diagnosing before you optimize
The docs are explicit that a lab tool like Lighthouse cannot measure INP across a real page visit — it requires field data (CrUX or RUM). Total Blocking Time from a Lighthouse run is a useful correlated proxy, but it's measuring main-thread blocking during page load, not the post-load interactions INP is built around. It also resets per visit: a page restored from the back/forward cache gets its own separate INP value, since the browser treats it as a distinct visit.
Shopify's documented workflow follows that constraint: find the slow page and interaction in field data first, reduce total JS before debugging anything specific — audit installed apps, remove the unused ones, and check whether "removed" apps still inject code — and only then profile the exact interaction in Chrome DevTools' Performance panel. The Summary tab's breakdown of scripting, rendering, and painting time is what tells you which of the three phases is actually dominant for that interaction, which is the only way to know whether you're looking at an app problem, a handler problem, or a layout problem.