How to Use This INP Audit Checklist
INP (Interaction to Next Paint) measures the time from a user gesture—click, tap, or keypress—to the next frame the browser paints in response. Google's 'good' threshold is 200ms or under; anything above 500ms is 'poor.' For ecommerce stores, slow INP kills conversion: add-to-cart buttons that feel frozen, filter interactions that lag, and checkout forms that stutter all create abandonment before the purchase completes.
Run through each of the 12 items below using Chrome DevTools, the Performance panel, PageSpeed Insights, or the Chrome User Experience Report (CrUX). Each item has a clear pass/fail line. Address failures in order of frequency—items your highest-traffic pages trigger most often cause the most real-world INP damage.
Items 1–4: JavaScript Execution Checks
**Item 1 — Long Tasks on Interaction.** Open DevTools Performance panel, record a click on your add-to-cart button, and inspect the main thread. Pass: no single task exceeds 50ms during the interaction. Fail: any task exceeds 50ms, blocking the browser from painting a response frame.
**Item 2 — Third-Party Script Execution Time.** In the Performance panel, filter tasks by domain. Pass: third-party scripts (chat widgets, analytics, review tools) consume less than 20% of total main-thread time during a recorded interaction. Fail: third-party scripts dominate the blocking time.
**Item 3 — Event Handler Duration.** Attach a performance.measure() wrapper around your primary click handlers and log duration to the console during a dev session. Pass: each event handler completes in under 30ms. Fail: any handler exceeds 30ms before yielding.
**Item 4 — Synchronous XHR or Fetch Inside Handlers.** Search your codebase for synchronous XMLHttpRequest calls or fetch calls that are awaited inside a click handler without yielding to the browser first. Pass: zero synchronous network calls inside event handlers. Fail: any synchronous call exists inside a handler triggered by user input.
Items 5–7: Rendering and Layout Checks
**Item 5 — Forced Layout / Reflow After Input.** In the Performance panel, look for the purple 'Layout' blocks immediately following an interaction. Pass: no layout recalculation triggered by your event handler exceeds 10ms. Fail: layout takes more than 10ms, indicating a read-then-write DOM pattern that forces synchronous reflow.
**Item 6 — Paint Size After Interaction.** After clicking a product filter or opening a modal, check the 'Paint' records in the Performance panel. Pass: the painted area is scoped to the changed component. Fail: the entire viewport or a large off-screen region repaints, indicating missing CSS containment or excessive DOM invalidation.
**Item 7 — CSS Containment on Interactive Components.** Inspect the CSS applied to high-interaction elements (dropdowns, carousels, quantity selectors) for the contain property. Pass: interactive components use contain: content or contain: layout paint. Fail: no containment declared on any interactive component, allowing style changes to cascade unnecessarily.
Items 8–10: Input Delay and Scheduling Checks
**Item 8 — Main Thread Availability at Page Load.** Record a full page load in the Performance panel, then click your primary CTA within the first three seconds. Pass: the input delay portion of INP (time from click to handler start) is under 50ms. Fail: input delay exceeds 50ms because the main thread is busy executing large parse-and-evaluate tasks from JavaScript bundles loading at startup.
**Item 9 — Scroll-Linked Interaction Handlers.** Locate any event listeners bound to scroll that also trigger DOM updates on the same frame. Pass: scroll handlers are passive (addEventListener('scroll', fn, { passive: true })) and do not synchronously mutate the DOM. Fail: any scroll handler is non-passive or mutates layout-affecting properties synchronously.
**Item 10 — Debounce or Throttle on High-Frequency Inputs.** Check search-as-you-type inputs, quantity steppers, and range sliders. Pass: every high-frequency input handler is debounced (300ms or less) or throttled using requestAnimationFrame. Fail: raw input or keyup events trigger full re-renders or API calls on every keystroke with no throttle.
Items 11–12: Field Data and Device Coverage Checks
**Item 11 — CrUX INP Distribution Across Device Types.** Open PageSpeed Insights or the CrUX Dashboard for your domain and compare INP percentiles on mobile versus desktop. Pass: the 75th-percentile INP is under 200ms on both device categories. Fail: mobile INP exceeds 200ms even if desktop passes—mobile accounts for the majority of ecommerce traffic and receives a separate Core Web Vitals assessment.
**Item 12 — INP Tied to Specific Page Templates.** Use Search Console's Core Web Vitals report to identify which URL groups (product detail pages, category pages, cart) have poor INP scores. Pass: all major page templates score 'good' in the field data report. Fail: one or more template groups show 'needs improvement' or 'poor,' meaning real users on those pages experience slow interactions—not just synthetic test artifacts.
Prioritizing Fixes After the Audit
After completing all 12 checks, sort failures by two factors: the traffic volume of affected pages and the INP contribution of the specific failure. A long task on the product detail page template affects far more users than the same issue on a low-traffic static page. Fix high-traffic, high-severity failures first.
The most reliable fix sequence is: break long tasks using scheduler.yield() or setTimeout(0) to return control to the browser, eliminate synchronous layout reads inside handlers, apply CSS containment, then defer or async-load third-party scripts that inflate input delay. Re-measure with field data (CrUX) after deploying fixes—lab tools like Lighthouse do not fully replicate real-user INP because they cannot simulate the interaction patterns of actual visitors.