![\"Chrome](\"/images/journal-inline-inp-subparts-debugging.webp\")
\n Interaction to Next Paint rolls every slow tap into one millisecond score. That is useful for ranking and for comparing sites, but it is a terrible debugging number on its own. Two pages can both report 280ms INP for completely different reasons — one blocked on a busy main thread before the handler even ran, the other spending most of its budget inside a synchronous React commit.
\n\nGoogle splits INP into subparts for exactly that reason. When I audit a React marketing site or a logged-in dashboard, I want to know which phase ate the budget. Fixing input delay means deferring load work. Fixing processing means shrinking handler scope. Fixing presentation delay means stopping layout thrash before the next paint. Mix them up and you ship the wrong patch.
\n\nThis post is the drill-down I reach for after the overview in Interaction to Next Paint: What INP Measures and How I Fix It. If you already have green LCP and miserable menus, start here.
\n\n// INP = input delay + processing duration + presentation delay\n// (simplified — see DevTools Interaction track for ground truth)Input delay is the gap between the user event and when your handler starts. The main thread was busy — long tasks, hydration, third-party capture listeners, a hero video decode. The click queued. Users feel this as “the button ignored me.”
\n\nProcessing duration is your handler and everything it synchronously triggers: state updates, DOM writes, chart redraws, analytics beacons fired inline. React 19 concurrent features can shrink this, but they do not remove a 400-node re-render you triggered on every filter keystroke.
\n\nPresentation delay is the time from handler completion until the browser paints the visual response. Forced layouts, synchronous font swaps, and animations that touch width/height instead of transform keep the screen frozen after your JavaScript “finished.”
\n\n\n
Open Chrome DevTools → Performance → record → click the interaction that feels sticky. The Interaction row expands into the three phases. Sort by duration. If input delay dominates, profile long tasks on load, not the click handler. If processing dominates, open the bottom-up flame chart on that event. If presentation delay dominates, look for Recalculate Style and Layout blocks immediately after your handler.
\n\nPageSpeed Insights field INP appears when CrUX has enough traffic. Lab Lighthouse still approximates with Total Blocking Time and interaction traces — useful for CI, not a substitute for field subparts on production URLs. I pair PSI field INP with lab vs field data so teams do not celebrate a 100 lab score while real users wait on input delay.
\n\nWhen traffic is thin, I use Chrome UX Report in Search Console or local RUM. For owner-facing dashboards that segment by page and device, see GA4 and Core Web Vitals Reporting Owners Actually Read.
\n\nInput delay: Split the main bundle. Defer below-fold widgets. Do not hydrate every card on the homepage before the menu works. Move Firebase, chat, and A/B snippets after first interaction or idle. Kill capture-phase listeners you did not add.
\n\nProcessing duration: Defer heavy work with requestAnimationFrame or startTransition. Virtualize lists. Batch DOM reads and writes. Never run filter logic synchronously on every input event for a 500-row table.
button.addEventListener('click', () => {\n requestAnimationFrame(() => {\n startTransition(() => setOpen(true));\n });\n});Presentation delay: Animate transform and opacity, not width. Avoid reading layout in the same turn you write it. Preload fonts with font-display: optional on marketing heroes so the first paint after a tap is not waiting on a swap.
Hydration competing with the first tap is the classic marketing-site INP failure. User lands, hero paints, they hit “Services” while React is still attaching listeners and reconciling the tree — input delay spikes. I gate non-LCP chrome until after hero paint and keep the first interaction path thin.
\n\nThird-party scripts registered in capture phase run before your bubble handler and extend input delay globally. Filter components that re-render the entire page tree on each keystroke blow processing duration. Portals and modals that measure getBoundingClientRect in a loop after open are presentation-delay traps.
On mid-tier Android over USB debugging, one recorded interaction beats arguing about whether INP “should” be fine on your M-series MacBook.
\n\nI pick the worst interaction on the URL — menu, primary CTA, checkout step — record it, and label which subpart won. That label goes in the report next to the PSI link. Fixes are ordered: input delay first if the thread is still choked at load, then processing, then presentation. Re-record until the Interaction track shows the phase under budget on the same device profile.
\n\nSend the URL and the interaction that feels sticky. I will return the subpart breakdown and a three-item fix list — usually smaller than a framework rewrite and larger than compressing one JPEG.
","tags":["inp","core-web-vitals","performance","debugging"],"views":1}