Content Marketing Glossary

  • What is Interaction to Next Paint (INP)?

What is Interaction to Next Paint (INP)?

Interaction to Next Paint (INP)

Interaction to Next Paint (INP) is a Core Web Vital that measures how quickly a page responds to user interactions - clicks, taps, key presses - by tracking the latency between the interaction and the next visual update of the page. Target is under 200 milliseconds at the 75th percentile. INP replaced First Input Delay (FID) as a Core Web Vital in March 2024, and it’s the metric most sites struggle with in 2026 because it’s affected by any heavy JavaScript work on the main thread.

How INP differs from FID

Three key differences from the metric it replaced:

All interactions, not just the first. FID measured only the first input to the page; INP measures the worst latency across all interactions during the page’s lifetime.

Full interaction cycle. FID measured only input delay (time from input to event handler start). INP measures the full cycle: input delay + processing time + presentation delay.

More sensitive to heavy JavaScript. INP catches interactions made worse by long tasks, memory pressure, or render-blocking work that FID missed.

What causes poor INP

Five common culprits:

Long JavaScript tasks blocking the main thread. Tasks taking >50ms prevent the browser from processing interactions promptly.

Large event handlers. Click or input handlers that perform heavy work synchronously.

Third-party scripts running during interaction. Analytics scripts, ad scripts, or tag managers firing on interactions add latency.

Render-heavy UI updates. Interactions that trigger large DOM updates or layout recalculations delay the next paint.

Memory-intensive apps. Sites with memory pressure (SPAs with many components, heavy state) have slower interaction responses because garbage collection runs more frequently.

How to improve INP

Seven practical optimisations:

Break up long tasks. Tasks over 50ms should be split using setTimeout, requestIdleCallback, or scheduler.yield().

Debounce heavy interactions. For typing or scroll handlers, debounce so they don’t fire on every event.

Move work off the main thread. Web Workers for compute-heavy tasks. The main thread stays responsive while workers do the work.

Audit third-party scripts. Many INP problems come from ad, analytics, or chat scripts. Measure their impact; remove or defer non-critical.

Code split by interaction. Don’t ship all JavaScript upfront. Load interaction-specific code when the interaction happens.

Optimise React/Vue/framework render cycles. Use memoisation, avoid unnecessary re-renders, batch state updates.

Show immediate feedback on interaction. Spinner or visual acknowledgment while async work completes. The interaction feels responsive even if the full result takes longer.

Measuring INP

Three measurement approaches:

Chrome DevTools Performance panel. Run interactions; inspect the main-thread timeline for long tasks during response.

PageSpeed Insights / Lighthouse. Field INP score from CrUX data plus diagnostic recommendations.

Real User Monitoring. Per-interaction INP data from actual users.

INP pain points in 2026

Three common scenarios:

E-commerce sites with heavy personalisation. Product pages doing real-time personalisation on interaction suffer INP issues.

Dashboards with live data. SaaS dashboards that update on interaction struggle when the underlying state management is heavy.

Content sites with large ad stacks. Ad scripts running on scroll and click interactions contribute disproportionately to INP failures.

Penfriend’s relationship to INP

Penfriend-produced pages are static HTML with no JavaScript interaction requirements, so INP on a Penfriend article is driven almost entirely by the site’s overall JavaScript bundle and third-party scripts. The content itself doesn’t contribute to INP problems. For content-programme-heavy sites, the performance story is that the content doesn’t compound the JavaScript problems that the platform’s interactive features may introduce.

Related terms