INP Radar demo

A slow interaction has two possible causes. Either the interaction itself does a lot of main-thread work, or the main thread is already blocked by background work when the user clicks, so the click has to wait. This page reproduces both. Open the INP Radar side panel on this tab and watch the radar, the heartbeat trace and the event log.

1. Background work: a recurring timer

A setInterval callback blocks the main thread for the block length, once per interval. Each run is one long task. Nobody has to interact: the radar wedge grows and the heartbeat trace spikes on every run, at a regular rhythm.

Run the recurring timer Block length (ms) Interval (ms)

The bar fills up to the next block. It stops moving while the page is blocked, because nothing on the page can render until the long task ends.

To find this work in a Chrome DevTools Performance trace, record across a spike. The long task shows up as a timer firing.

2. An expensive interaction

This click handler runs 250 ms of synchronous work before it updates the page. The main thread was idle when you clicked, so input delay is low, but the interaction is still slow: almost all of it is processing time.

Turn the recurring timer off first, so a block can't add input delay to this click. On a real page, wait until the radar shows the main thread is idle, then record a trace and interact, to measure the interaction's own cost.

3. A cheap interaction, idle and blocked

This click handler only updates a counter. Click it while the page is idle and the interaction is fast. Click it while the recurring timer is blocking the main thread and the click waits for the long task to finish. That wait is input delay, and it makes a cheap interaction slow.

To land a click inside a block, click when the bar in section 1 is full, or set the block length to 1000 ms to make the block easier to hit.