# Interaction to Next Paint (INP)

Interaction to Next Paint is the delay from a user action to the next paint on screen. It shows how fast your page feels when someone taps. This entry explains what it means for a small site, how to measure it, how to fix it, and the traps.

Updated 2026-09-13 · Source: https://porteur.ai/glossary/interaction-to-next-paint

## What INP means for a small site

INP measures responsiveness. It is the time from the moment a user interacts to the next frame that reflects that change.

As of 2026, a good INP is up to 200 ms. Poor is above 500 ms. It replaced First Input Delay in March 2024 as a Core Web Vital.

> Core Web Vitals thresholds: LCP good up to 2.5 s, CLS good up to 0.1, INP good up to 200 ms.

Why you care: slow actions lose signups and sales. If a tap on /pricing feels sluggish, users hesitate or try again. Keep it snappy and predictable.

## How to measure INP

Read field data first. PageSpeed Insights shows the 75th percentile over 28 days from the Chrome User Experience Report, per URL or origin, when there is enough traffic. That is what Google uses for assessment.

Use Lighthouse for lab checks. It runs one simulated test on a mid range phone on throttled 4G by default. Scores vary between runs. Its performance score weights Total Blocking Time 30%, LCP 25%, CLS 25%, First Contentful Paint 10% and Speed Index 10%.

Test real pages. Check /, /pricing, signup, and any page with a form or menu. Trigger real actions: open the mobile menu, add to basket, expand FAQs. Note the slowest interaction on each run.

If field data is missing, rely on lab data to find causes, then ship and wait for the next 28 day window to reflect the change. Track your own analytics events to spot slow UI too.

## Why scripts hurt INP

INP is often bad because the main thread is busy. Long JavaScript tasks block the browser from painting the result of a tap.

- Big bundles that parse and run on every page load
- Framework hydration that runs before a button can react
- Third party tags that run on interactions, like A/B tests or chat
- Work on the click handler, like heavy validation or JSON parsing
- Layout thrash, repeated reads and writes to DOM and style

Example: a click on “Start free trial” on /pricing fires three trackers and a modal. The next paint is slow. Remove two tags and load the modal code only when needed. The same click paints within the 200 ms target.

## Fixes that move INP under 200 ms

1. **Defer non critical JavaScript** Load analytics, heatmaps and chat after user interaction or with an explicit consent click. Use async or defer. Delay their init during first user actions.
2. **Split and lazy load UI code** Code split routes and components. Import the modal, date picker or editor only when opened. Keep the click handler tiny.
3. **Break up long tasks** Find long main thread tasks. Split work with requestIdleCallback or setTimeout, and yield to the event loop. Move heavy work off the main thread to a Web Worker.
4. **Reduce event work** Do only what proves the tap happened, then paint. Defer analytics and network calls. Optimise validation and formatters.
5. **Trim CSS and layout cost** Avoid forced reflow inside handlers. Batch DOM writes. Use transform and opacity for animations. Keep the first paint cheap so follow up paints are fast.
6. **Contain third parties** Load tags through a manager with strict triggers. Block any script that runs on click unless it is essential. Audit tag timing on /pricing and checkout.

A fixed page feels instant. Taps toggle states in under 200 ms, and heavy widgets appear only when needed.

## Common traps and edge cases

- Optimising load only, ignoring interactions after the page settles
- Binding many listeners on scroll or input that fire on each keystroke
- Server work mistaken for INP, when the UI could show a spinner fast
- Testing on desktop while your users are on mid range phones
- Shipping one fix and judging it before the 28 day field window updates

> Set a budget: no single interaction should block the main thread for more than 200 ms. Track it on key pages after each deploy.

## Questions

### How is INP calculated?

INP records the latency of interactions like clicks, taps and key presses during a visit, then takes the worst, or near worst, event as the page’s score. Field reports use the 75th percentile of those page loads over 28 days, per URL or origin.

### How do I improve my INP score?

Cut main thread work around interactions. Defer third party scripts, split bundles, break long tasks, and keep handlers light. Test key actions on real devices and move heavy work to a Web Worker when possible.

### What does INP mean in SEO?

INP is a Core Web Vital. Pages that meet the good threshold up to 200 ms help user experience and can support search performance. It sits with LCP and CLS in Google’s quality signals as of 2026.

### What replaced First Input Delay?

Interaction to Next Paint replaced First Input Delay in March 2024. INP measures the time to the next paint, so it captures event processing and rendering, not just the delay to start.

### What target should I set for INP?

Aim for under 200 ms at the 75th percentile in field data. If your lab runs are near 150 ms on a mid range phone, you have a buffer for real users.

### Why does Lighthouse show good INP but users still complain?

Lighthouse is one simulated run. Real users vary by device and network. Trust field data in PageSpeed Insights, and replay real actions that are slow for users.

## Read next

- [Core Web Vitals](https://porteur.ai/glossary/core-web-vitals): Core Web Vitals are Google’s three field speed and responsiveness metrics. See their thresholds, lab versus field, how to read them, and what to fix.
- [Core Web Vitals for a product site: the three numbers](https://porteur.ai/guides/core-web-vitals): The product founder’s guide to LCP, CLS and INP: what Google measures, why phones decide the pass, common causes, and how to test and fix.
- [Largest Contentful Paint (LCP)](https://porteur.ai/glossary/largest-contentful-paint): Largest Contentful Paint is when the biggest element appears. Aim under 2.5 s. See how to measure it, usual causes on small sites, and quick fixes.
- [Cumulative Layout Shift (CLS)](https://porteur.ai/glossary/cumulative-layout-shift): Cumulative Layout Shift is how much a page moves while loading. Keep CLS at or below 0.1. Here is how to measure, find causes, and fix them.
- [Lighthouse vs PageSpeed Insights: lab and field](https://porteur.ai/compare/lighthouse-vs-pagespeed-insights): Use Lighthouse for repeatable lab checks, PageSpeed Insights for real-user field data. See why scores differ and which to trust for fixes and reporting.
- [Reading a Lighthouse score on a phone](https://porteur.ai/guides/lighthouse-score): Use the mobile Lighthouse run to judge speed and UX. See what each score means, how lab and field data differ, and what to fix first.
- [First Input Delay](https://porteur.ai/glossary/first-input-delay): First Input Delay measured the wait before the browser handled a first interaction. It was retired in March 2024 and replaced by Interaction to Next Paint.

Run a free thirty second read of a URL to spot slow interactions, see likely blocking scripts, nearby rivals on your searches, and three full findings. Free check: https://porteur.ai/