Paste a Web Vitals INP attribution table above, then select Triage interactions to rate each interaction against Core Web Vitals, identify its slow phase, and get a fix checklist.
About the INP interaction trace triage pad
The INP interaction trace triage pad takes a Web Vitals attribution table - one row per slow interaction with its Interaction to Next Paint and the three INP phases (input delay, processing duration, and presentation delay) - and tells you, for each interaction, whether it passes Core Web Vitals, which phase drove the slowness, and what to do about it. Interaction to Next Paint is the sum of those three phases, so the phase with the largest contribution points straight at the cause: a busy main thread, an expensive event handler, or a costly next paint.
Paste your attribution rows, select Triage interactions, and the tool rates each interaction (good at 200 ms or less, needs improvement up to 500 ms, poor above 500 ms), flags its dominant phase, and writes a plain-language suspected cause and a concrete fix action, ordered worst-first. You can download a fix-checklist CSV or copy a markdown note for a Core Web Vitals review. Everything runs in your browser. The interaction labels, selectors, and timings you paste are never uploaded or stored.
How to use
- Paste your Web Vitals INP attribution table into the box. A sample table is loaded so you can see how it works, including a checkout click dominated by presentation delay.
- Each row should have an interaction name and either an INP value or the input delay, processing, and presentation phase durations. Columns are matched flexibly by header name.
- Select Triage interactions to rate every interaction against the Core Web Vitals INP thresholds and identify the dominant phase for each.
- Review the table: each row shows the interaction, its INP, the rating, the slow phase, a suspected cause, and a fix action, ordered worst-first.
- Select Download fix checklist CSV or Copy fix checklist to take the triage into a Core Web Vitals review.
Worked examples
Checkout button click rated Poor, slow phase Presentation
An interaction with INP over 500 ms where presentation delay is the largest phase points at expensive next-paint work such as a large DOM update or layout thrashing, not the event handler.
Open menu tap slow phase Input delay
When input delay dominates, the main thread was busy when the interaction fired, so the fix is to break up long tasks and defer third-party or hydration work rather than touch the handler.
Filter checkbox change rated Good
An interaction at or under 200 ms passes the Core Web Vitals good INP threshold and is flagged monitor-only, so attention stays on the interactions that actually fail.
Frequently asked questions
- What is INP and how is it broken into phases?
- Interaction to Next Paint (INP) is a Core Web Vitals metric that measures how long it takes the page to visually respond to a user interaction. It is the sum of three phases: input delay (the time before the event handlers can start, usually because the main thread is busy), processing duration (the time the event handlers run), and presentation delay (the time to render the next frame after the handlers finish). The phase with the largest contribution tells you where the slowness lives.
- What rating thresholds does it use?
- It uses the Core Web Vitals INP thresholds: 200 ms or less is good, more than 200 ms and up to 500 ms is needs improvement, and more than 500 ms is poor. These defaults are fixed for this tool. The rating is applied to each interaction's INP value, whether you provide INP directly or the tool computes it as the sum of the three phase durations.
- What input format does it expect?
- A pasted table (CSV) where the first row is a header. It looks for an interaction column and any of an INP column and the three phase columns (input delay, processing, presentation), matching header names flexibly so inp, inp_ms, and INP (ms) are all recognized. If no INP column is present it sums the three phases. A target or selector column is optional. Values can include units like ms or s and are normalized to milliseconds.
- How does it decide the dominant phase and the fix?
- For each interaction it compares the input delay, processing, and presentation durations and picks the largest as the dominant phase. Input delay points at a busy main thread (long tasks, third-party scripts, hydration); processing points at expensive event handlers; presentation points at costly rendering of the next frame. Each dominant phase maps to a plain-language cause and a concrete fix action. If no per-phase data is provided, the row is flagged so you can capture phase attribution from the Web Vitals attribution build.
- Is my attribution data uploaded anywhere?
- No. The parsing, rating, phase bucketing, and triage all run in your browser. The interaction labels, selector or target text, URLs, and timings you paste are never sent to a server or saved. Download the fix-checklist CSV or copy the markdown note before you close the tab.
Use this again tomorrow
Save this page so it's one tap away when you need a quick result.
Ready for a quick Daily Challenge?
Play Daily Challenge on sts.games