What Is Interaction to Next Paint (INP)?
Interaction to Next Paint (INP) is a Core Web Vital metric that measures the latency between a user's discrete interaction (click, tap, or keyboard input) and the moment the browser visually updates the screen in response — capturing the worst-case interaction delay observed during an entire page session. It replaced First Input Delay (FID) as an official Core Web Vital in March 2024. A 'good' INP score is 200 milliseconds or less, 'needs improvement' falls between 200–500ms, and anything above 500ms is considered poor.
What Is Interaction to Next Paint (INP)?
Interaction to Next Paint (INP) is a Core Web Vital metric that measures the latency between a user's discrete interaction (click, tap, or keyboard input) and the moment the browser visually updates the screen in response — capturing the worst-case interaction delay observed during an entire page session. It replaced First Input Delay (FID) as an official Core Web Vital in March 2024. A 'good' INP score is 200 milliseconds or less, 'needs improvement' falls between 200–500ms, and anything above 500ms is considered poor.
How Interaction to Next Paint (INP) Works
INP is measured by the browser's Event Timing API, which records the full lifecycle of an interaction: the input delay (time between the event being triggered and the event handler starting), the processing time (time the main thread spends running event handlers), and the presentation delay (time between the last frame being painted and it becoming visible on screen). The metric captures every qualifying interaction during a page visit and reports the highest observed latency — or, for pages with many interactions, the 98th percentile value — as the final INP score. This contrasts with FID, which only measured the input delay of the first interaction and ignored how long event handlers actually took to run. The root cause of high INP is almost always long tasks blocking the browser's main thread. JavaScript is single-threaded, so when a task runs longer than 50ms (the threshold defined in the RAIL model), it prevents the browser from responding to user input or rendering a new frame. Heavy event handlers, synchronous DOM manipulation, unoptimized React re-renders, or large bundles executing during interaction are common culprits. Tools like Chrome DevTools' Performance panel and the Long Animation Frames (LoAF) API (available in Chrome 116+) let you identify which scripts are causing these long tasks. The browser paints a new frame only after the current task and any associated microtasks complete, then layout and paint are calculated. If your click handler triggers a reflow by reading and writing layout properties in alternating sequence (forced synchronous layout), the browser must recalculate layout mid-task, dramatically increasing presentation delay. This is why techniques like batching DOM reads before writes — using requestAnimationFrame or scheduling updates via scheduler.postTask() — are so impactful for INP. INP is measured in real-user environments via the Chrome User Experience Report (CrUX) dataset, which Google uses to determine search ranking signals. Lab tools like Lighthouse can approximate INP using Total Blocking Time (TBT) as a proxy, but actual INP scores require field data from real users collected via the web-vitals JavaScript library or through tools like PageSpeed Insights, which surface CrUX data for your URL.
Best Practices for Interaction to Next Paint (INP)
Break up long JavaScript tasks by yielding back to the main thread using setTimeout(fn, 0), scheduler.postTask(), or the newer scheduler.yield() API (Chrome 129+), which lets the browser handle pending input events between task chunks. Minimize event handler work by deferring non-critical processing — for example, after a button click triggers a form submission, immediately update the UI (provide visual feedback) and defer analytics, logging, or secondary network calls using queueMicrotask() or postMessage(). Avoid forced synchronous layouts by separating DOM reads (e.g., getBoundingClientRect()) from DOM writes within the same event handler; libraries like FastDOM can enforce this discipline automatically. Profile interaction traces using Chrome DevTools' 'Interactions' track or the LoAF API (window.PerformanceObserver with type 'long-animation-frame') to identify exactly which scripts, third-party tags, or framework lifecycle hooks are blocking paint after a user gesture. For React or Vue applications, use startTransition() (React 18+) to mark non-urgent state updates so the framework can prioritize rendering the direct interaction response before processing secondary updates.
Interaction to Next Paint (INP) & Canvas Builder
Canvas Builder's AI-generated HTML uses Bootstrap 5 as its foundation, which means interactive components like modals, accordions, and navigation menus are implemented with Bootstrap's optimized, event-delegation-based JavaScript rather than bespoke, potentially bloated custom scripts — keeping event handler processing time minimal and directly supporting low INP scores. The clean semantic markup Canvas Builder produces avoids deeply nested DOM trees that cause expensive reflow and layout recalculation during interactions, which is a primary driver of high presentation delay in INP measurements. Because Canvas Builder outputs static, framework-free HTML files, there is no virtual DOM reconciliation overhead on interaction — clicks and keyboard events trigger browser-native responses immediately, giving developers an INP-friendly baseline before they write a single line of custom code.
Try Canvas Builder →