Responsiveness is core to user experience. One of the most frustrating issues is input lag: when clicks, taps, or keystrokes feel slow or unresponsive. That’s exactly what INP measures: the time from a user interaction to the next paint, capturing the slowest significant interaction during the entire lifecycle of a page.
Many Real User Monitoring (RUM) solutions report CSS selectors associated with poor INP scores. Keep in mind they report the event target (the element the user interacted with) rather than the specific code path causing the delay. If you missed the first chapter where we explain what a CSS selector is, you can read it here.
Let’s see this in action with an example.
In the screenshot above, a user has switched between product variants on a product page. Our goal is to use the reported CSS selector to find the element, reproduce the lag, and trace the code that makes the next paint slow.
While poor Interaction to Next Paint (INP) can significantly impact user satisfaction, identifying root causes can be tricky. Let's explore how to effectively debug these problems.
Setting up for debugging Jump to heading
Like in the LCP analysis, begin by reproducing the scenario where users experienced poor INP. Locate the CSS selector by navigating to Chrome DevTools > Elements and use the search function (Ctrl + F on Windows/Linux or Cmd + F on macOS) to find your selector. The element may be in the viewport or below the fold.
Identifying the interaction delay Jump to heading
Once you've identified the element, reproduce the interaction (click, tap, type). Watch for lag or jank. Use DevTools to confirm the delay:
Open Chrome DevTools > Performance. Click Record, perform the interaction, then stop recording. In the “Interactions” and “Main” tracks, look for long tasks, expensive style recalculations, and large paints triggered by the event target. These are your culprits.
The root cause typically stems from main-thread work that blocks painting: heavy JavaScript in event handlers, synchronous DOM updates, layout thrashing, or third‑party scripts firing on interaction. The fix is to reduce, defer, or move that work off the main thread.
Common INP culprits Jump to heading
Several common culprits typically cause slow interactions:
- Long JavaScript tasks in event handlers. Break work into smaller chunks; defer non‑critical logic until after the first paint.
- Synchronous DOM operations and layout thrashing (multiple reads/writes). Batch updates; avoid forced synchronous layouts.
- Heavy third‑party scripts attached to clicks or taps. Audit and remove or lazy‑load non‑essential handlers.
- Animations that trigger layout or large paints. Prefer transforms over layout‑changing properties for smoother updates.
See it in action Jump to heading
Let's explore how to debug Interaction to Next Paint issues by analyzing CSS selectors in a real‑world example with Shopify's Performance Reports.
Step 1: Access the INP report Jump to heading
Navigate to the “Interaction to Next Paint: Page Type” report in your Shopify admin. You'll see a breakdown similar to this:
Step 2: Analyze CSS selectors Jump to heading
If Product pages show poor INP scores, dig deeper to identify which CSS selectors are associated with slow interactions.
To identify the specific CSS selectors reporting INP values on Product pages:
- Under “Dimensions”, select “Interaction to Next Paint target” instead of “Page type”.
- Add a filter for “Page type” and set it to “Product”.
- Add a filter for “Device type” and set it to “Mobile”.
This will give you a detailed view of CSS selectors for elements reporting INP, ordered by page load frequency:
Step 3: Find the element with poor INP scores using the CSS selector Jump to heading
Load a Product page in Chrome, open DevTools, and search for the CSS selector in the Elements panel:
Next, measure the interaction in your browser: go to the Performance panel, click Record, perform the interaction on the target element (in the example, switch between variants), and stop the recording.
Step 4: Analyze common INP issues Jump to heading
The previous step will provide a trace with details on each INP sub-part:
- Input Delay
- Processing Duration
- Presentation Delay
The Chrome team has a full set of documentation featuring several articles to get you ready to debug and optimize for INP. In addition, Annie Sullivan and Michal Mocny from Chrome presented Digging into Interaction to Next Paint at the NY Web Performance meetup which is a must-watch:
Once any required changes are implemented, repeat the process to validate the improvements.
Conclusion Jump to heading
In this final chapter, we covered how to debug Interaction to Next Paint (INP) issues by using CSS selectors to locate the interaction target and trace the bottlenecks. That completes our CSS selectors journey! If you jumped in late, be sure to review Chapter 3 to master debugging Cumulative Layout Shift (CLS) and ensure your visual stability is just as solid as your interactivity.
Cover photo by Kevin Butz on Unsplash
