INP for React Apps: Profiling and Eliminating Long Tasks

INP (Interaction to Next Paint) measures how quickly your UI responds after a user interacts. If a click, tap, or keypress is followed by a noticeable delay, you’ll feel it — and so will your users.

INP is now the key responsiveness metric in Core Web Vitals, and it’s one of the most common issues on React apps that ship too much JavaScript.

What INP actually measures (in plain terms)

When a user interacts, the browser has to:

1. run your event handler,
2. run any state updates and rendering work,
3. paint the next frame.

INP captures the time from interaction to the next paint for the worst interactions users experience (within a page view).

Targets (baseline)

• Good: ≤ 200ms
• Needs improvement: 200–500ms
• Poor: > 500ms

The main causes of bad INP in React apps

In most apps, INP is bad because of one or more of these:

• Long tasks (main thread blocked for >50ms)
• Render storms (too many components re-rendering)
• Heavy work inside event handlers (sync parsing, sorting, filtering)
• Third-party scripts (analytics, chat widgets, tag managers)
• Too much JS shipped (hydration costs + runtime overhead)

You don’t “optimize INP” by tweaking one thing — you reduce main-thread work and make updates cheaper.

Step 0: Confirm you really have an INP problem

Start with field data:

• Search Console’s Core Web Vitals report (pattern-level)
• RUM if you have it (best)

Then use lab tools to reproduce:

• Chrome DevTools Performance recording
• React DevTools Profiler

Step 1: Find long tasks (your #1 enemy)

If the main thread is blocked, the browser can’t paint.

How to spot them

In a Performance recording:

• Look for long yellow blocks (scripting).
• Zoom into interactions and check what runs right after the input event.

If you see repeated long tasks, you’ve found your INP root cause.

Step 2: Make event handlers “light”

Event handlers should ideally:

• update state,
• schedule work,
• and return quickly.

Common anti-patterns

• Doing expensive filtering/sorting synchronously on click
• Parsing large JSON payloads during input
• Building huge arrays/objects during a scroll/typing event

Fix patterns

• Precompute when possible (outside the interaction)
• Debounce expensive work triggered by typing
• Chunk big work into smaller pieces

Step 3: Reduce React re-render costs

Many INP problems are simply “too much renders happen per interaction”.

What I check first

• Are we passing new objects/functions every render?
• Are lists re-rendering on every keystroke?
• Is global state causing whole pages to update?

Fix patterns that consistently help

• Memoize hot components (only where it matters)
• Use stable props (avoid {} and () => {} inline for hot paths)
• Split state: keep “typing state” local, not global
• Virtualize big lists/grids

The goal isn’t to “memo everything”. The goal is to stop re-rendering 200 components when the user clicks one button.

Step 4: Reduce hydration + client JS on content pages

If your page is mostly content (blog posts), you usually don’t need much JS.

Best lever

Avoid turning layout/typography into client components.

Ship interaction only where needed (search box, filters, forms), and keep everything else server-rendered.

Step 5: Defer third-party scripts (they often dominate INP)

Third-party scripts can easily:

• add long tasks,
• create layout thrash,
• or block the main thread during interaction.

Practical strategy

• Defer until after first interaction or idle
• Load only on routes that need it
• Remove anything you don’t use weekly

Most teams keep scripts forever. INP improves fast when you treat scripts like dependencies with a cost.

Step 6: Use a repeatable INP “playbook”

This is my default workflow:

1. Identify a bad interaction (field data or user report).
2. Reproduce in DevTools.
3. Find the longest task after the input event.
4. Reduce work in the handler.
5. Reduce re-renders triggered by that state update.
6. Re-test and confirm the long task is gone.

Quick checklist

• Event handlers return quickly
• Expensive work is deferred/chunked
• Large lists are virtualized
• Hot components are memoized appropriately
• Client JS is minimized on content routes
• Third-party scripts are deferred/audited