Interaction to Next Paint (INP)

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.

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.

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.

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.

1. 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. 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. 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. 4

   Reduce event work

   Do only what proves the tap happened, then paint. Defer analytics and network calls. Optimise validation and formatters.

5. 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. 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.

• 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