Frontend

INP: performance after the page has loaded

Find long tasks and keep interactions responsive throughout the life of a page.

José Higinio SosaPublished on January 18, 20264 min read

INPCore Web VitalsPerformance

The central idea

Identify input delay, processing and presentation work. Handler duration alone does not explain perceived responsiveness.

Interaction to Next Paint measures interaction latency during a visit. A good target is 200 milliseconds or less at the 75th percentile for mobile and desktop.

An interaction includes input delay, handler execution and presentation delay. Measuring one function can miss queued work or an expensive render.

Anatomy of a 180 ms interaction

Interaction timeline

50 ms

83 ms

47 ms

01
Input delay
Previous main-thread work
02
Processing
Handlers and state updates
03
Presentation
Render, layout and next paint

Conceptual example: users perceive input delay, processing and presentation together, not just the handler.

Common improvements include breaking long tasks, reducing client JavaScript, avoiding layout thrashing, rendering fewer nodes and showing immediate visual feedback.

Lab data helps reproduce problems, while field INP reveals real hardware and usage. Instrument critical routes with enough context to identify the interaction.

Diagnose the correct phase

High input delay points to work already occupying the main thread. High processing suggests expensive handlers or calculations. High presentation delay often relates to rendering, styles or too many nodes. Splitting phases prevents optimizing a small function while the real block happens before or after it.

Connect field data with context

Segment the 75th percentile by route and device class. Investigation benefits from interaction type, element, version and duration while protecting privacy and cardinality. Slow real sessions matter more than a smooth demo on the developer machine.

Free the main thread

Breaking tasks lets the browser accept input between blocks. Reducing client JavaScript, virtualizing long lists, avoiding broad renders and moving non-urgent work after visual feedback usually produces more impact than micro-optimizing one operation. Validate each change on representative hardware.

Set interaction budgets

Critical journeys need goals per interaction and regression alerts. A filterable table, search and checkout have different profiles. Release instrumentation connects bundle, component and data changes to deterioration before a monthly average hides it.

Teaching case

A slow filter with a fast function

A table filter runs quickly, but the click waits behind unrelated main-thread work. Updating results then renders many rows and triggers style and layout work. Timing only the filter misses the actual bottlenecks.

Record the interaction and separate all three phases. Reduce visible rendering work when presentation dominates. Consider a worker for expensive calculations that do not need the DOM, accounting for communication costs. A worker does not fix excessive layout.

Setting a loading state immediately before a long synchronous calculation can still prevent feedback from painting. Yield opportunities matter. INP ends at the next paint; measure useful task completion separately so an earlier frame does not hide slower results.

Choices and their tradeoffs

Situations, choices and limitations
Situation	Choice	Tradeoff
Delay before the handler	Reduce or split preceding tasks.	A faster handler cannot clear an existing queue.
Heavy computation	Evaluate chunks or a worker.	Account for transfer and coordination.
Expensive presentation	Reduce nodes and layout work.	Preserve understandable, accessible feedback.

Scroll the table to compare all three columns.

Put it into practice

Build a repeatable comparison

Use the same device, data and journey.
Identify the dominant phase and change one factor.
Check field p75 separately for mobile and desktop when enough data exists.

What to verify: Responsiveness improves on representative hardware without making task completion slower.

Loading does not end at first paint

INP forces teams to care for the entire life of a page. A site may load quickly and feel slow afterward; the goal is to keep the main thread available and produce understandable visual feedback during every important interaction.