Interaction to Next Paint (INP): What It Is and How to Improve It

By the LaunchLen Web Solutions Team · Kitchener, Ontario · Last updated: October 24, 2026

Interaction to Next Paint (INP) is Google’s measure of how quickly a web page responds when someone clicks, taps or presses a key. If a visitor taps “Add to cart” and nothing seems to happen for a moment, that delay is what INP captures.

INP is one of Google’s Core Web Vitals, alongside loading speed and visual stability. This guide explains what INP measures, how to check it, what commonly causes slow interactions and practical fixes for WordPress sites and JavaScript apps.

Interaction to Next Paint in plain English

Every time a visitor interacts with a page, the browser has to do some work and then paint the next frame on screen to show the result: a menu opening, a filter applying, a form showing an error. According to web.dev, INP observes the latency of all click, tap and keyboard interactions during a visit and reports the longest one, ignoring outliers.

Each interaction is made up of:

• Input delay: the wait before the page can start handling the interaction, for example because the browser is busy with other work.
• Processing time: how long the code that responds to the interaction takes to run.
• Presentation delay: the time from that code finishing to the browser painting the next frame.

Scrolling, hovering and zooming aren’t counted.

What’s a good score? web.dev says good INP values are 200 milliseconds or less, and poor values are greater than 500 milliseconds, measured at the 75th percentile of page loads and split across mobile and desktop. Check the current guidance before setting targets, as definitions can be updated.

INP vs FID. INP is the successor to First Input Delay (FID). FID only measured the input delay of the first interaction on a page; INP looks at all interactions, from input delay through to the next paint.

How INP is measured (field vs lab data)

Field data comes from real visitors. web.dev recommends starting here, because it reflects real devices and real behaviour. Common sources include:

• PageSpeed Insights, which shows Chrome User Experience Report (CrUX) data when a site has enough real-user data.
• The Core Web Vitals report in Google Search Console.
• A real user monitoring (RUM) tool, which can show which interaction was slow and on which page. CrUX can show that a problem exists, but not what caused it.

Lab data comes from testing tools in a controlled setting. Lab tests can only measure the interactions performed during the test, and some lab tools don’t report INP at all because they only measure page load. web.dev suggests Total Blocking Time as a reasonable proxy in those cases, but not a substitute.

A practical approach: use field data to find which pages are slow, then reproduce the interaction in the lab, for example in the Chrome DevTools Performance panel, while following common user flows and interacting with the page while it loads.

Common causes of slow interactions

Many INP problems come back to the browser’s main thread being busy when the visitor acts. Common causes include:

• Long tasks during page load, when the browser is still parsing and running scripts.
• Heavy event handlers that do too much work before updating the screen.
• Third-party scripts such as chat widgets, tag managers, ad scripts and tracking pixels.
• Large, deeply nested page structures that make each screen update expensive to render.
• Rendering lots of HTML with JavaScript in response to a click.
• Layout thrashing, where code changes styles and then immediately reads layout values, forcing extra work.

Fixes for WordPress and page builders

On WordPress, slow interactions can trace back to what plugins and themes load on every page.

• Audit plugins and scripts. Remove what you don’t use, and load scripts only on the pages that need them.
• Delay or trim third-party tools. Chat widgets and marketing tags can be loaded after the main content, or only on key pages. Our guide to AI-powered web development covers adding AI features without heavy scripts.
• Simplify page-builder layouts. Fewer nested sections and widgets mean a smaller page structure to update. Some builders offer performance settings that reduce extra markup or unused assets; names and defaults vary by version, so check the builder’s help docs. Our Elementor speed optimization guide goes into more detail.
• Go easy on effects. Sliders, animated counters and heavy mega menus add work on interaction.
• Test after each change, on a real mid-range phone as well as a desktop.

Caching helps loading speed, but it won’t fix slow interactions on its own; the work happening in the browser still needs attention.

Fixes for React and JavaScript apps

JavaScript-heavy sites and single-page apps give developers more control, and more ways to block the main thread.

• Break up long tasks. web.dev advises doing as little work as possible in event handlers and yielding to the main thread, so the browser can paint sooner.
• Update the screen first, defer the rest. Show the visual result of the click right away, then run saving, logging or analytics in a later task.
• Mark non-urgent updates. In React, useTransition lets you render part of the UI in the background so typing and clicks stay responsive. Check the React docs for your version, as these APIs have evolved.
• Avoid unnecessary re-renders of large parts of the page when only a small piece changes.
• Keep the DOM lean and consider the CSS content-visibility property for long off-screen content.
• Prefer server rendering over building large amounts of HTML in the browser after an interaction.

Here’s an illustrative example: a product listing filters results as the visitor types, and each keystroke re-renders the whole list. Updating the search box immediately and rendering the filtered list as a non-urgent update can keep typing smooth.

FAQ

Does INP affect SEO?

INP is one of Google’s Core Web Vitals. Google says good Core Web Vitals, along with other page experience aspects, align with what its core ranking systems seek to reward. It’s one factor among many, so helpful content still matters, but a responsive page is better for visitors either way.

Why does PageSpeed Insights show no INP data?

Field INP data only appears when there’s enough real-user data in CrUX. A page can also have no INP if visitors only scrolled or never interacted. In that case, test key interactions in the lab.

Is fixing INP a one-time job?

No. web.dev describes improving INP as an iterative process: new features, plugins and scripts can introduce new slow interactions, so it’s worth rechecking after changes.

Let’s work together on your project

Want to know why your site feels slow to respond? We’re LaunchLen Web Solutions Inc., based in Kitchener, serving Waterloo Region and businesses across Ontario. We work with WordPress and can work with React and Node, and our SEO services page explains how we approach search and site health. When we take on performance work, we can agree the scope, deliverables and reporting with you first. Book a free consultation to get started.