Introduction
A page can load quickly and still feel slow.
The headline appears almost immediately. Images are already visible. The page scores well for loading metrics. Then you click a menu, open a filter, press a button, or type into a search box, and nothing seems to happen for a moment.
That delay is a different kind of performance problem.
What Is INP? Interaction to Next Paint (INP) is a Core Web Vital that measures a page’s responsiveness to user interactions. It considers the time from an interaction, such as a click, tap, or keyboard input, until the next visual update is presented. Rather than measuring how quickly a page first appears, INP helps reveal how responsive it remains while visitors use it.
INP is particularly relevant to JavaScript-heavy websites, ecommerce interfaces, dashboards, web applications, menus, filters, search interfaces, and forms where visitors need to interact with page elements.
Quick Answer: What Is INP?
Interaction to Next Paint (INP) is a Core Web Vital that measures a page’s responsiveness to user interactions.
It looks at interactions such as:
- Clicking a button
- Tapping a control
- Typing into an input
- Opening a menu
- Selecting a filter
- Expanding an interface element
INP measures the latency from the interaction until the browser presents the next visual update.
The current thresholds are:
| INP | Assessment |
| 200 milliseconds or less | Good |
| More than 200ms up to 500ms | Needs improvement |
| More than 500ms | Poor |
INP is a field-oriented responsiveness metric. It considers interactions throughout the page’s lifecycle rather than focusing only on the first interaction.
A good INP means users can interact with the page and receive visual feedback without noticeable waiting.
Why Was INP Introduced?
Before INP became a Core Web Vital, First Input Delay (FID) was used to measure an important part of interaction responsiveness.
FID was useful, but it had a limitation.
It measured the delay between a user’s first interaction and the point at which the browser could begin processing that interaction. It did not capture the entire time required for the interaction to produce a visible response.
That leaves out an important part of what users actually experience.
Consider a button.
A visitor clicks it.
The browser receives the input immediately, but the site’s JavaScript then spends 300 milliseconds processing the event. Another 150 milliseconds is spent doing rendering work before the visual change appears.
The visitor experiences the whole delay.
A metric concerned only with the initial input delay would not tell the complete story.
INP was introduced to provide a broader view of responsiveness, and it replaced FID as a Core Web Vital in March 2024.
What Does INP Actually Measure?
The easiest way to understand INP is to follow an interaction through the browser.
A visitor clicks a button.
The browser has to:
- Receive the interaction.
- Wait if other work is blocking the main thread.
- Run the relevant event handlers.
- Perform the necessary rendering work.
- Paint the updated interface.
- Present that update to the visitor.
INP is concerned with the time involved in that path.
This is why a page can have perfectly reasonable server response times and still have terrible INP.
The problem may not happen during the page load at all.
It may happen after the visitor starts using the page.
What Counts as an Interaction?
INP considers several forms of user interaction, including common pointer, mouse, keyboard, and touch interactions.
Examples include:
Clicking
A visitor clicks a navigation button, opens a dropdown, submits a form, or activates a control.
Tapping
On touch devices, a tap can trigger an interaction that requires the page to update.
Typing
Typing into a search field, filter, or form can produce repeated interactions.
For example, a search interface might run JavaScript every time a user enters another character.
If each input triggers expensive work, the page can become noticeably sluggish.
Pressing Controls
Buttons, toggles, accordions, tabs, menus, filters, and similar interface controls can all expose responsiveness problems.
The important point is that INP is concerned with real interaction behavior, not simply whether a page initially renders quickly.
INP Measures More Than the First Interaction
This is one of the biggest differences between INP and FID.
Imagine someone opens a product page.
The first button they click responds quickly.
Later, they open a filter containing thousands of items. That interaction triggers expensive JavaScript and takes 700 milliseconds before the interface updates.
The first interaction was fine.
The page was not consistently responsive.
INP is designed to capture that broader experience.
For pages with many interactions, the metric uses the interaction with the highest latency, with an approach that accounts for the fact that some pages can generate a very large number of interactions.
The practical lesson is simple:
A fast first click does not prove that the page is responsive.
The Three Parts of an Interaction
When investigating INP, it helps to break interaction latency into three broad stages:
Input Delay
The browser may not be able to start processing an interaction immediately.
Why?
Because the main thread could already be busy.
A large JavaScript task may be executing. A page might be processing another event. Some other browser work may be occupying the main thread.
The user clicks.
The browser knows about the click.
But the code responsible for handling it cannot start yet.
That waiting period is input delay.
Processing Time
Once the event can run, the relevant event handlers execute.
This is where application code can become expensive.
For example:
button.addEventListener(“click”, () => {
updateInterface();
calculateResults();
renderResults();
});
The code itself is simple enough to read.
The important question is what those functions actually do.
If calculateResults() processes a large dataset and renderResults() causes extensive DOM work, the interaction may take far longer than the small event handler suggests.
Presentation Delay
The browser still needs to render the result after the interaction has been processed.
The interface may have changed in JavaScript, but the visitor does not see the change until the browser can produce and present the next frame.
This is why “the event handler only takes 20 milliseconds” does not necessarily mean the interaction has a 20-millisecond INP.
There can be additional work between event processing and what the visitor actually sees.
Why the Main Thread Matters So Much
A large portion of INP problems eventually leads back to the browser’s main thread.
The main thread handles important browser work such as:
- Running JavaScript
- Processing events
- Updating the DOM
- Calculating styles
- Performing layout work
- Preparing rendering
If it is occupied with expensive work, interactions may have to wait.
Consider a visitor clicking a menu button while the browser is executing a large JavaScript task.
The click does not necessarily get immediate attention.
It sits behind work that is already running.
From the visitor’s perspective, the button feels broken.
The browser is not broken. It is simply busy.
That distinction matters because the solution is usually not to make the button’s click handler slightly faster. The larger problem may be the work that happened before the click was processed.
What Is a Long Task?
A long task is a task that occupies the browser’s main thread for a significant period.
Long tasks are particularly relevant to INP because they can prevent the browser from responding promptly to new input.
Suppose JavaScript performs this sequence:
Large calculation → DOM processing → more JavaScript → user clicks
If the existing work is still running when the click occurs, the interaction must wait.
This is why a page can appear perfectly fine during an automated page-load test but become frustrating once someone starts using it.
The page may have completed its initial rendering while still carrying a heavy JavaScript workload.
Why JavaScript Often Causes Poor INP
JavaScript is not inherently bad for performance.
Modern websites depend on JavaScript for everything from simple menus to complex applications.
The problem is usually how much work JavaScript asks the browser to perform, when it performs that work, and whether the work can be broken into smaller pieces.
Common problems include:
- Large JavaScript bundles
- Expensive event handlers
- Long-running calculations
- Excessive DOM manipulation
- Repeated layout work
- Unnecessary third-party scripts
- Large client-side frameworks or application logic
- Work that happens synchronously during an interaction
A small amount of well-structured JavaScript can be extremely fast.
A relatively small script can also trigger expensive browser work.
File size alone does not tell you how responsive a page will be.
A Simple INP Example
Imagine an ecommerce filter.
A visitor clicks:
Brand → Sony
The page responds by:
- Reading hundreds of products.
- Filtering them with JavaScript.
- Rebuilding a large section of the DOM.
- Recalculating styles and layout.
- Updating several UI components.
If that sequence takes 600 milliseconds before the user sees the updated result, the interaction feels slow.
The browser did exactly what the code asked.
The problem is that the interaction asked the browser to do too much work before presenting the result.
A better implementation might:
- Update the visible control immediately.
- Avoid unnecessary DOM changes.
- Reduce the amount of data processed.
- Break expensive work into smaller tasks.
- Defer work that is not required for the immediate response.
The goal is not necessarily to make every operation disappear.
It is to make the user-visible response happen sooner.
What Causes Poor INP?
There are several recurring causes.
Long JavaScript Tasks
A long-running task can prevent the browser from processing input.
This is one of the most common causes of interaction delay.
Large tasks can come from your own application code, frameworks, analytics, advertising systems, tag managers, widgets, or other third-party software.
Expensive Event Handlers
An event handler may trigger far more work than its small amount of code suggests.
For example:
button.addEventListener(“click”, () => {
rebuildEntirePage();
});
The problem is not the addEventListener() call.
The problem is what rebuildEntirePage() does.
If a click only changes one small part of the interface, rebuilding everything can create unnecessary work.
Excessive DOM Changes
The Document Object Model represents the page structure.
Large-scale DOM changes can require the browser to perform additional style, layout, and rendering work.
A single small update is generally very different from replacing a large section of a complex interface.
Forced Synchronous Layout
Some JavaScript patterns can cause the browser to calculate layout immediately when it would otherwise be able to delay that work.
Repeatedly reading layout information and then changing styles can create unnecessary browser work.
This can become especially expensive when performed inside interaction handlers.
Third-Party Scripts
Analytics, advertising, chat widgets, social embeds, A/B testing tools, customer-support software, and other third-party systems can consume main-thread time.
You may not have written the code.
The browser still has to execute it.
This is particularly important when diagnosing INP because a page can inherit responsiveness problems from code that exists outside the site’s core application.
Why “Reduce JavaScript” Is Not Enough
You will often see performance advice that says:
Reduce JavaScript.
The recommendation is directionally useful but technically incomplete.
Suppose a website downloads 500 KB of JavaScript and another downloads 1 MB.
You cannot conclude that the second site must have worse INP.
The amount of JavaScript transferred is only one part of the story.
What matters includes:
- How much code is executed
- How often it executes
- How long individual tasks run
- What happens during interactions
- How much DOM work is triggered
- How much rendering work follows
- Whether third-party code blocks the main thread
A smaller bundle can still contain an expensive function.
The better goal is less unnecessary main-thread work, not an arbitrary JavaScript kilobyte target.
How to Improve INP
Improving INP starts with identifying what is actually delaying the interaction.
Break Up Long Tasks
If a task takes a long time, look for ways to split it into smaller pieces.
Instead of making the browser process a large amount of work in one uninterrupted block, some work can be divided so that the browser gets opportunities to respond to user input.
This is particularly useful for:
- Large calculations
- Data processing
- DOM updates
- Client-side rendering
- Non-critical application work
Breaking up work is not automatically beneficial if the total work remains excessive, but it can prevent one large task from monopolizing the main thread.
Keep Interaction Handlers Focused
An interaction should do what the visitor needs first.
If clicking a button changes a small part of the interface, do not automatically perform unrelated calculations, analytics work, data processing, and rendering during the same critical path.
Move non-essential work out of the immediate interaction when possible.
Reduce DOM Work
Look at what happens after an interaction.
Does one click cause thousands of elements to be updated?
Does the entire component tree re-render when only one value changed?
Does a filter rebuild content that did not actually change?
Reducing unnecessary DOM work can make interaction processing considerably cheaper.
Avoid Forced Layout Work
Be careful about JavaScript that repeatedly alternates between reading layout information and changing styles.
For example, code that repeatedly measures an element and then immediately changes another property can force the browser to perform layout work sooner than necessary.
Where possible, group reads and writes rather than constantly switching between them.
The exact optimization depends on the code, but the underlying principle is straightforward:
Do not make the browser repeatedly recalculate information that your code could have handled more efficiently.
Defer Non-Critical Work
Not every piece of work needs to happen before the user sees the result of an interaction.
Analytics, logging, secondary calculations, and other non-critical operations may be able to happen after the important visual response.
The user should not have to wait for work that has nothing to do with the action they just performed.
Review Third-Party Code
Third-party code deserves its own investigation.
If a page contains several external scripts, ask:
- Is each one necessary?
- Does it run during user interactions?
- Does it attach many event listeners?
- Does it perform expensive work?
- Does removing or delaying it change responsiveness?
Do not remove useful tools simply because they are third-party.
But do not assume external code is harmless just because it is loaded from a reputable service.
How to Diagnose a Slow INP
The first step is not installing another optimization plugin.
Find the interaction.
That sounds obvious, but it changes the entire investigation.
Suppose field data says a page has poor INP.
You need to know:
Which interaction is slow?
Is it:
- Opening the navigation?
- Clicking a product filter?
- Typing into search?
- Opening a modal?
- Expanding an accordion?
- Submitting a form?
- Selecting a date?
- Switching tabs?
Once the problematic interaction is known, the investigation becomes much more specific.
Use Field Data to Find the Real Problem
Field data is especially valuable for INP because interaction behavior depends heavily on what visitors actually do.
A laboratory test may never click the exact control causing the problem.
Real visitors might.
For example, a performance test may report a reasonable INP while actual users experience poor responsiveness after interacting with a complicated filter.
This does not necessarily mean the test is wrong.
It means the test did not reproduce the same interaction pattern.
Field data answers:
Which experience are real users having?
Lab tools help answer:
What happens when I reproduce and investigate the problem?
Both have a role.
Use Chrome DevTools to Investigate the Interaction
Once you know which interaction is problematic, Chrome DevTools can help break the delay into pieces.
A performance recording can reveal:
- Long tasks
- Event handlers
- JavaScript execution
- Rendering work
- Layout activity
- Paint activity
- Main-thread congestion
The goal is not to stare at a giant timeline and search randomly.
Start from the slow interaction.
Find where its time went.
For example:
Interaction: 650ms
Then the trace may reveal:
Input delay: 300ms
Processing: 200ms
Presentation delay: 150ms
That immediately changes the investigation.
If input delay dominates, look for work blocking the main thread before the interaction.
If processing dominates, inspect the event handlers and application logic.
If presentation delay dominates, investigate rendering and work occurring before the next paint.
The metric gives you the symptom.
The trace helps identify the cause.
A Practical INP Diagnosis Example
Consider a product filter that feels sluggish.
The page loads in under two seconds.
LCP is good.
The filter itself looks simple.
But when a visitor selects a category, the interface freezes briefly.
A performance recording shows that the click is waiting behind a long JavaScript task.
The task is not actually part of the filter.
It is a large piece of client-side analytics processing triggered shortly before the interaction.
In this case, rewriting the filter might accomplish very little.
The more useful fix is to prevent that unrelated work from blocking the main thread at the wrong time.
Now consider a different page.
The click starts immediately, but the event handler performs a large calculation and rebuilds hundreds of DOM nodes.
Here, the problem is in the interaction’s processing path.
Same symptom.
Different cause.
This is why INP optimization should begin with measurement rather than a standard list of JavaScript tricks.
INP and Mobile Devices
INP problems can become more noticeable on mobile devices.
A desktop computer may execute a particular JavaScript task quickly enough that the delay is barely noticeable.
A lower-powered mobile device can take substantially longer to perform the same work.
Network speed is not the only variable.
CPU performance matters too.
This is one reason a site can appear responsive to the developer testing it on a powerful desktop machine while visitors using ordinary mobile hardware experience noticeable delays.
Performance testing should therefore account for the devices your audience actually uses.
INP and WordPress
WordPress sites can develop INP problems through many different paths.
Common sources include:
- Page builders
- Themes
- Sliders
- Popup systems
- Filtering plugins
- Search plugins
- Ecommerce functionality
- Analytics
- Tag managers
- Advertising scripts
- Chat widgets
- Social embeds
- Other third-party integrations
There is no universal WordPress setting that guarantees good INP.
A page with ten plugins can be responsive.
A page with three plugins can be slow.
What matters is what those components actually make the browser do.
For a WordPress site, the useful question is not:
“Which plugin should I remove?”
It is:
“Which code is consuming the main thread during the interaction that users are experiencing as slow?”
That question produces a much more reliable optimization strategy.
INP vs FID: What’s the Difference?
FID measured the delay before the browser could begin processing the first user interaction.
INP looks at the broader interaction experience and includes the time required for the browser to reach the next paint.
A simplified comparison looks like this:
| Metric | Main focus |
| FID | Delay before processing the first interaction |
| INP | Interaction latency through the next visual update |
FID was useful, but it could miss problems that occurred later in the interaction lifecycle.
INP provides a more comprehensive view of responsiveness and is now the Core Web Vital used for this purpose.
INP vs LCP
These metrics answer different questions.
LCP asks:
“When does the main visible content appear?”
INP asks:
“How quickly does the page respond when the visitor interacts with it?”
A website can therefore have:
LCP: Good
INP: Poor
There is no contradiction.
The page can load quickly and still have a sluggish interface.
Likewise:
LCP: Poor
INP: Good
The page may take too long to display its main content but respond quickly once the visitor starts interacting.
Improving one does not automatically fix the other.
What Is a Good INP?
A good INP is 200 milliseconds or less at the 75th percentile.
Between 200 and 500 milliseconds needs improvement.
Above 500 milliseconds is poor.
These thresholds should be treated as practical performance boundaries rather than a reason to obsess over tiny differences.
A page at 205 milliseconds and a page at 900 milliseconds do not represent the same kind of problem.
If a page is comfortably in the good range, chasing another few milliseconds may be less valuable than fixing a serious problem elsewhere.
Can a Website Have a High INP Without Heavy JavaScript?
Yes.
JavaScript is a common source of poor INP, but it is not the only possible explanation.
The browser has to process more than JavaScript.
Rendering, style calculations, layout, painting, DOM complexity, and other browser work can affect how quickly the next visual update is presented.
The correct approach is therefore to inspect the interaction timeline rather than assuming the culprit before measuring it.
Common INP Optimization Mistakes
Optimizing Only the Initial Page Load
A fast page load does not guarantee fast interactions.
INP is specifically about what happens when visitors use the page.
Removing JavaScript Without Understanding It
Deleting scripts can break functionality without solving the actual bottleneck.
Find the expensive work first.
Looking Only at JavaScript File Size
A 300 KB script can contain an expensive operation.
A larger script can sometimes have little effect on a particular interaction.
Execution behavior matters more than the raw transfer size alone.
Testing Only on a Powerful Desktop
A developer’s machine may hide responsiveness problems that appear on mobile hardware.
Test realistic conditions.
Treating Every Interaction as Equally Important
Not every piece of work needs to happen immediately.
Prioritize the visual response that tells the user their action was received.
Secondary work can often happen afterward.
Chasing a Perfect 0ms Interaction
Zero latency is not realistic.
Browsers need time to process events and render changes.
The goal is a responsive interface, not a theoretical score with no measurable delay.
A Practical INP Checklist
Before declaring an INP problem fixed, check:
- Do you know which interaction is slow?
- Is the problem visible in field data?
- Can you reproduce the interaction?
- Is a long task blocking the interaction?
- Is the event handler doing unnecessary work?
- Is JavaScript processing too much data?
- Is the DOM being updated unnecessarily?
- Is layout work becoming expensive?
- Are third-party scripts involved?
- Can non-critical work be moved out of the interaction?
- Have you tested on realistic mobile hardware?
- Have you compared the result before and after the change?
- Did the improvement actually address the measured bottleneck?
Final Verdict
INP is ultimately about one of the simplest questions in web performance:
When a visitor does something, how quickly does the page respond?
That sounds easier to solve than it actually is.
A slow interaction might be caused by a long task that started before the click. It might be an expensive event handler. It might be excessive DOM work. It might be rendering. It might even be a third-party script that has nothing directly to do with the control the visitor clicked.
That is why “reduce JavaScript” is not a complete INP strategy.
Find the interaction that users are struggling with.
Measure where its time is going.
Then remove, reduce, defer, or restructure the work that is preventing the browser from responding promptly.
Good INP is not about making a page do less for the sake of a performance score.It is about making sure the browser can give the user a visible response before the waiting becomes noticeable.
Related Articles:
- Core Web Vitals Guide: 9 Powerful Ways to Improve LCP, INP & CLS
- How to Improve INP: 9 Powerful Fixes for JavaScript and Long Tasks
- Third-Party Scripts and Core Web Vitals: 9 Critical Performance Fixes
- CSS and JavaScript Minification: 7 Powerful Speed Tips
- Website Speed Audit: 9 Powerful Steps to Fix Slow Pages
Recommended Resources
- web.dev: Interaction to Next Paint (INP)
- Google Search Central: Core Web Vitals
- Chrome for Developers: Performance Overview
- Google PageSpeed Insights