Improve INP: Make Your Website Respond Faster to Taps

Interaction to Next Paint, or INP, measures how long it takes for a page to visibly respond after a visitor interacts with it. It became a Core Web Vital in March 2024, replacing First Input Delay. Google's thresholds are 200 milliseconds or less for good, and more than 500 milliseconds for poor.

If your page loads quickly but menus open slowly, buttons seem to ignore the first tap, or a filter list freezes for a moment, INP is the metric describing that problem.

What INP actually measures

Every time someone clicks, taps or presses a key, the browser has to run any event handlers, then update the screen. INP measures the time from the input until the next frame is painted. It has three parts:

• Input delay: the time the interaction waits because the browser is busy with something else.
• Processing time: how long your event handlers take to run.
• Presentation delay: the time the browser takes to calculate layout and paint the result.

A page's INP is a high-percentile interaction across the whole visit, not an average, so one consistently slow control can fail the page.

Why the main thread is the bottleneck

Browsers run most JavaScript, style calculation and layout on a single main thread. While that thread is busy with a long task, usually defined as work taking longer than 50 milliseconds, it cannot respond to input. So the real cause of poor INP is almost always too much work happening on the main thread, too often.

How to find the slow interaction

1. Open the page in Chrome and use the Performance panel in DevTools. Record while you perform the slow action, such as opening the menu.
2. Look for long tasks, shown with red markers, around the moment of the interaction.
3. Expand the task to see which scripts are responsible. Third-party scripts, tag managers and page builders often appear here.
4. If your site has enough traffic, check the INP report in Search Console to see which page groups are failing in the field.

Lab tools cannot predict every interaction, since INP depends on what real visitors do, so test the actions people really perform: menus, search boxes, add-to-basket buttons, accordions and forms.

Common causes and fixes

Too much JavaScript

Every script has to be downloaded, parsed and executed. Remove plugins and widgets you do not use, replace heavy libraries with lighter alternatives, and load scripts only on the pages that need them. Our article on reducing JavaScript goes deeper.

Third-party scripts

Chat widgets, social feeds, heat maps and advertising tags run on your visitors' main thread. Load them after the page is interactive where possible, delay non-essential ones until the first user action, and review them regularly. If you cannot name what a script is for, it is a candidate for removal.

Long event handlers

If a click triggers a large amount of work, break it into smaller pieces and let the browser paint in between. Give visual feedback first, such as a button state change or a spinner, then do the heavy work afterwards. Developers can yield to the main thread between chunks of work, using techniques such as scheduling smaller tasks or setTimeout with a zero delay.

Large DOM size

Pages with thousands of elements make every style and layout calculation slower. Simplify page builder output, paginate long lists and avoid deeply nested wrappers. Rendering fewer elements means faster updates after each interaction.

Layout thrashing

Reading layout values such as element sizes and then writing styles repeatedly in a loop forces the browser to recalculate layout again and again. Batch reads together, then writes together.

WordPress sites

On WordPress, INP problems commonly come from page builders, sliders, pop-up plugins, analytics tags and stacked marketing scripts. Audit with a plugin-by-plugin approach: disable one, retest the slow interaction, and keep the result. Choose lightweight themes, and avoid plugins that load their scripts on every page.

Does hosting affect INP?

Less than it affects loading metrics, because the work happens in the visitor's browser. But a server that delivers the page and scripts slowly can still push scripts late and cause busy periods during interaction. Fast delivery, compression and caching all help the browser reach an idle state sooner. Plan options are listed on the hosting overview.

A simple improvement routine

1. List the five interactions that matter most on your key pages: opening the menu, searching, adding to a basket, submitting a form and opening a gallery.
2. Test each one with CPU throttling enabled in DevTools, which simulates a slower phone.
3. For any that feels delayed, record a trace and find the long task behind it.
4. Remove, defer or replace the script responsible, then record again to confirm the long task is gone.
5. Repeat after every plugin, theme or tag manager change, since new scripts are the most common way INP gets worse over time.

Treat INP as something you monitor rather than fix once. New marketing tags and plugin updates quietly add work to the main thread, and a regular check keeps interactions feeling quick.

Fast delivery helps your front-end work pay off

INP is mostly a front-end problem, but quick delivery of every file matters too. Zebra Hosting Cloud offers Cloudflare CDN on hosted sites, which serves static files from locations closer to visitors. Learn more on the CDN page.