Manually diagnose slow interactions in the lab

Bringing slow interactions into the lab

Once you have field data pointing to which interactions are slow for real users, the next step is reproducing those problems locally in a controlled environment. Manual testing in the lab is where you can trace an interaction and uncover exactly why it's slow.

No field data? Use load-time signals first

Field data is the ideal starting point for finding the interactions that need work. If you don't have any, there are other routes to identify likely candidates.

Total Blocking Time (TBT) is a lab metric that tracks main-thread responsiveness during load and correlates strongly with INP. If Lighthouse reports a high TBT for a page, that's a good warning that the page won't respond quickly while it loads.

For interactions after load, think about your key user flows. If you run an ecommerce site, the sequence of adding items to a cart and checking out is the kind of flow users will repeat most, so interactions in that flow deserve scrutiny even without field measurement. The goal stays the same: reproduce the trouble in the lab, then identify it.

Reproducing slow interactions

The DevTools performance tooling gives you a couple of ways to track interactions, each suited to a different stage of diagnosis.

Scan with live metrics

The Performance panel opens to a live metrics view that's useful for a first pass when you don't know which interactions are the problem ones. As you interact with the page, the feed logs diagnostic data for each interaction and flags the slowest INP one. You can expand logged interactions to see their phase breakdowns.

This view is enough to locate problem interactions and gives a rough idea of which segment is long, but you'll want a full trace for the deeper diagnosis you need to navigate production code and find the root cause.

Record a trace

The Chrome performance profiler is the recommended tool for diagnosing slow interactions. To capture one:

1. Open the page you want to test.
2. Open DevTools and switch to the Performance panel.
3. Start a recording with the Record button in the top-left.
4. Perform the interaction(s) you want to investigate.
5. Stop the recording.

When the trace loads, look first at the activity summary along the top. Red bars highlight long tasks, letting you quickly zoom into the areas that will need the most attention.

You can drag to select a region and focus there. The profiler's breadcrumbs feature can help narrow the timeline further so unrelated activity is hidden.

Once the trace is focused on the interaction in question, the Interactions track sits above the main thread track. That alignment shows what work happened on the main thread for the duration of the interaction.

For details on which piece dominated, hover over an interaction entry. The striped region of the visual highlights any time beyond 200 milliseconds, the upper bound of a "good" INP threshold. The pieces are:

1. Input delay, shown as the left whisker.
2. Processing duration, the solid block between the whiskers.
3. Presentation delay, the right whisker.

From the phase breakdown, you can follow the work on the main thread track to the specific function calls or tasks causing the slowdown, and move from a known-slow interaction to a concrete fix.

Breaking down interaction latency in the profiler

An interaction is composed of three phases: input delay, processing duration, and presentation delay. Which phase contributes the most to a slow interaction determines the optimization strategy you should pursue.

Isolating long input delays

The input delay is the time from when the operating system registers a user action until the browser begins running that interaction's first event handler. It's shown in the performance profiler's interactions track as the left whisker of the interaction; hovering over the interaction reveals the exact duration.

Input delay can never be zero, but its length is partly within your control. The primary suspect is main-thread work that blocks event callbacks from executing when they should.

In the trace above, a task originating from a third-party script is running when the user attempts to interact. This extends the input delay and, consequently, the interaction's overall latency.

Spotting long processing durations

The processing duration is the time event callbacks take to complete after the input delay ends. When these callbacks run too long, the browser can't present the next frame quickly. The solid portion of the interaction in the interactions track represents this duration.

To find expensive callbacks in a trace, follow these steps:

1. Check whether the task running the callbacks is a long task. Use CPU throttling in the performance panel or remote debugging on a low- to mid-tier Android device to reveal long tasks reliably in a lab setting.
2. If it's a long task, look within the call stack for event handler entries—such as those named Event: click—that display a red triangle in their upper-right corner.

Two strategies can help shorten processing durations:

1. Minimize the work itself. Review whether every step in an expensive callback is essential. Remove unneeded code outright or defer it. Frameworks can help here: React's memoization, for instance, skips re-rendering a component when its props haven't changed.
2. Yield to the main thread. Breaking a long task into smaller ones—whether manually or through something like React's transitions feature—lets the renderer paint UI updates made earlier in the callback before the remaining work runs.

When rendering is the bottleneck: presentation delays

Poor INP can also stem from expensive rendering work triggered by even minimal event-callback code. The presentation delay is the time the browser takes to paint visual updates reflecting the interaction's result.

Rendering typically involves style recalculations, layout, paint, and compositing. In the flame chart these appear as purple and green blocks. The interaction's right whisker in the interactions track shows the total presentation delay.

Presentation delays are often the hardest to diagnose and fix. Common culprits include:

• Large DOM sizes. Rendering cost tends to scale with the page's DOM size, which affects interactivity accordingly.
• Forced reflows. Mutating styles in JavaScript and then immediately querying style values forces the browser to run layout out of order—before finishing the current work—so it can return the updated values.
• Heavy requestAnimationFrame callbacks. These run in the event loop's rendering phase and must finish before the next frame presents. Don't use them for work unrelated to UI changes.
• Expensive ResizeObserver callbacks. These run before rendering and can delay the next frame. Defer any logic in them that isn't needed for the upcoming frame.

If the slow interaction won't reproduce

When field data flags a slow interaction but you can't reproduce it in the lab, your testing hardware and connection are a likely reason. A fast device on a fast network masks what your users experience. Three options are worth trying:

1. If you have a physical Android device, remote debugging lets you drive it from Chrome DevTools on your host machine. Mobile hardware is often slower than laptops or desktops, making the issue easier to reproduce.
2. Without a physical device, enable CPU throttling in Chrome DevTools to simulate a slower processor.
3. Don't wait for the page to fully load before interacting. The main thread is busiest during startup, so use network throttling and interact with the page as soon as it first paints—matching what a user on a slower connection actually experiences.

Tracing INP is an iterative cycle

Diagnosing high interaction latency takes a methodical approach, but pinning down the root cause brings you halfway to a fix. The workflow is simple to state and harder to practice:

• Use field data to find slow interactions.
• Test those interactions in the lab to confirm whether they reproduce.
• Determine whether the issue is long input delay, expensive callbacks, or costly rendering.
• Repeat the cycle.

The final step matters most. Improving INP—like any performance work—is cyclical; once you fix one slow interaction, test again, then move on to the next until the data shows improvement.