INP and long-task budget planner

Where to get the inputs

Record a trace of the interaction in the Chrome DevTools Performance panel on your test machine. Three numbers come from it:

• Work already running when the user acts. If the interaction happened while another task was running, such as a hydration chunk, a timer or a data parser, note that task's length. If nothing was running, use 0.
• Event handler work. The time spent in the event handlers for the interaction, shown under the input event in the trace.
• Style, layout and paint. The rendering work between the end of the handlers and the next frame.

If you only have field data, the attribution build of the web-vitals library reports input delay, processing duration and presentation delay for real interactions, which you can use as a starting point (source 1).

How the estimate works

The planner follows the three-part model of an interaction that web.dev uses for INP (source 2): input delay, processing duration and presentation delay. It makes four simplifying assumptions so that you can check its arithmetic:

1. All three inputs are multiplied by the device factor you pick, so 100 ms on your machine becomes 400 ms on a device four times slower.
2. Input delay is half the length of the task that was already running, as if the user acted halfway through it.
3. If you split the handler into several pieces and yield between them, only the first piece runs before the next frame. The planner assumes you update the visible UI in that first piece and move the rest after the paint.
4. Presentation delay is the rendering work you entered, scaled by the device factor.

The estimate is the sum of the three phases. It is compared with the INP thresholds: 200 ms or less is good, above 500 ms is poor, and anything between needs improvement (source 2).

The 50 ms line

A task longer than 50 ms is a long task, and while it runs the browser cannot respond to input or paint (source 3). The planner flags any piece of work that crosses that line on the chosen device and suggests how many pieces would keep each one under it. Yielding between pieces gives the browser a chance to handle input and paint. Where scheduler.yield() is available (Chromium 129 and later, Firefox 142 and later at the time of writing) it resumes your remaining work ahead of other queued tasks; elsewhere a setTimeout based fallback works, with less control over ordering (source 4).

A worked example

Suppose a filter button runs 180 ms of handler work on your laptop, a 60 ms hydration chunk was running when the user clicked, and the browser needs 40 ms to restyle and paint. On a device four times slower, the planner estimates input delay of 120 ms (half of 240), processing of 720 ms and presentation of 160 ms, a total of 1,000 ms, well into the poor range.

Split the handler into 15 pieces and the first piece costs 48 ms on that device, under the 50 ms line. The estimate drops to about 328 ms. It is still above 200 ms, which points at the remaining costs: the hydration chunk running at the time of the click and the rendering work. Both would be next on the list.

This example uses invented timings to show the arithmetic. Your numbers will differ.

What the planner cannot tell you

It cannot see your code, and it cannot know how real users interact or which devices they use. INP in the field is the 75th percentile across many visits and many interactions. Use the planner to set budgets and to sanity-check a plan before you write code, then confirm with traces and field data.

Privacy

The planner calculates in your browser. It sends nothing, stores nothing and sets no cookies.