Interaction to Next Paint (INP): Diagnose & Improve Responsiveness

Interaction to Next Paint (INP) measures how responsive a webpage feels when a visitor interacts with it. It observes qualifying clicks, taps, and keyboard interactions during a page visit and evaluates the delay before the browser can present visual feedback.

A page can load quickly and still have poor INP. For example, the hero image may appear immediately, but a navigation menu, filter, search box, checkout control, or mobile drawer may respond slowly because JavaScript is occupying the main thread.

Improving INP therefore requires a different workflow from optimizing Largest Contentful Paint. Instead of focusing primarily on network delivery and initial loading, INP work concentrates on input delay, event-handler execution, long tasks, rendering cost, DOM complexity, and third-party JavaScript.

Last verified: September 26, 2026.

---

---

1. INP Performance Thresholds

INP	Classification	Meaning
≤ 200 ms	Good	Interactions generally feel responsive
> 200–500 ms	Needs Improvement	Some interactions may feel noticeably delayed
> 500 ms	Poor	Users may experience substantial interaction delay

Evaluate INP at the 75th percentile of page visits and consider mobile and desktop independently.

Do not confuse the visit-level interaction selection with the field percentile across visits. Within one visit, INP is the worst or near-worst qualifying interaction. Across many real-user visits, Core Web Vitals reporting uses the 75th percentile.

A page can also have no INP value for a visit when the user never performs a qualifying click, tap or keyboard interaction.

---

2. What INP Measures

An interaction can be divided into three broad stages:

User Interaction
      ↓
1. Input Delay
      ↓
2. Event Processing
      ↓
3. Presentation Delay
      ↓
Next Painted Frame

Total interaction latency can therefore increase even when the event handler itself is relatively small.

---

3. Input Delay

Input delay is the time between the user initiating an interaction and the browser beginning to run its event callbacks.

The most common reason for high input delay is that the browser's main thread is already busy.

Possible causes include:

• JavaScript parsing and execution.
• Large synchronous tasks.
• Third-party scripts.
• Timers.
• Previous user interactions.
• Large DOM or style calculations.

---

4. Event Processing Duration

Once the main thread becomes available, the browser runs the event handlers associated with the interaction.

For example:

button.addEventListener('click', () => {
  updateCart();
  calculateTotals();
  updateSidebar();
  sendAnalytics();
});

If every action runs synchronously before visual feedback appears, the interaction can feel slow.

---

5. Presentation Delay

After event handlers finish, the browser may still need to:

• Recalculate styles.
• Perform layout.
• Update the DOM.
• Paint changed elements.
• Composite the next frame.

A complex UI update can therefore produce poor INP even when event-handler JavaScript itself is not unusually long.

---

6. INP Is Not the Same as First Input Delay

INP evaluates responsiveness throughout the page visit rather than focusing only on the first interaction.

This makes it more useful for applications where visitors interact repeatedly with:

• Navigation.
• Filters.
• Search interfaces.
• Product selectors.
• Forms.
• Dashboards.

A page that performs well on its first click can still have poor interaction responsiveness later.

---

7. Start with Field Data

Real-user data is the strongest starting point because device capability, browser workload, main-thread contention and user behavior vary considerably. Network conditions can affect application behavior too, but INP itself ends at the next presented frame rather than waiting for every asynchronous network consequence of the interaction.

Useful sources include:

• Chrome User Experience Report data exposed through supported tools.
• PageSpeed Insights field data.
• Search Console Core Web Vitals reports.
• A Real User Monitoring system.
• Custom Web Vitals instrumentation.

Field data answers the first question:

Do real visitors actually experience poor responsiveness?

PageSpeed Insights and Search Console can expose CrUX-based field data when enough real-user data is available. Lab tools remain useful for reproduction, but a lab trace is not a substitute for real-user INP because users interact at different times, on different devices, under different main-thread conditions.

---

8. Field Data and Lab Testing Have Different Roles

Field data identifies real-world problems.

Lab testing helps reproduce them.

Once a problematic interaction is identified, reproduce actions such as:

• Opening the mobile navigation.
• Submitting search.
• Changing a product filter.
• Adding an item to a cart.
• Opening an accordion.

Then inspect the browser's performance trace.

---

9. Reproduce the Interaction in Chrome DevTools

Record the exact user action in Chrome DevTools instead of profiling an idle page.

1. Open DevTools → Performance.
2. Use CPU throttling only when needed and record the setting.
3. Start recording before the interaction.
4. Perform one real flow such as opening the mobile menu, applying a filter or changing cart quantity.
5. Stop after the visual response appears.
6. Find the interaction in the Interactions track.
7. Inspect input delay, processing duration and presentation delay.
8. Correlate the slow phase with main-thread tasks, JavaScript call stacks, style/layout work, paint and third-party activity.

Current Chrome DevTools marks interactions longer than 200 ms and exposes the three INP subparts. That breakdown is more useful than optimizing the largest script without proving it delayed the interaction.

---

10. Use Long Animation Frames for Deeper Attribution

The Long Animation Frames API can add useful field context for slow interface updates. Chrome documents it as a way to connect long frames with INP diagnosis and understand what else was running during the same frame.

Feature-detect it because support is not universal:

if (PerformanceObserver.supportedEntryTypes.includes('long-animation-frame')) {
  const observer = new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
      if (entry.firstUIEventTimestamp > 0) {
        console.log({
          duration: entry.duration,
          blockingDuration: entry.blockingDuration,
          startTime: entry.startTime
        });
      }
    }
  });

  observer.observe({
    type: 'long-animation-frame',
    buffered: true
  });
}

Do not collect every large trace object indiscriminately in production analytics. Send only the minimum diagnostic context you need and follow your site's privacy policy.

---

11. Long Tasks Are a Common Cause of Poor INP

A long-running main-thread task can prevent the browser from responding promptly to input.

For example:

function processLargeDataset(items) {
  items.forEach(item => {
    calculate(item);
    render(item);
  });
}

If this work occupies the main thread while the user clicks a control, the interaction waits.

---

12. Break Large Tasks into Smaller Work

When application logic permits it, split noncritical work so the browser gets opportunities to process input and render between chunks.

Modern browsers can support task-yielding patterns such as:

button.addEventListener('click', async () => {
  updateVisibleState();

  if ('scheduler' in window && 'yield' in scheduler) {
    await scheduler.yield();
  } else {
    await new Promise(resolve => setTimeout(resolve, 0));
  }

  runNonCriticalWork();
});

The goal is not to yield after every line. Yielding too often can reduce overall throughput. Use it around noncritical chunks where responsiveness matters, feature-detect scheduler.yield(), and test application behavior before deployment. Current web.dev INP guidance demonstrates yielding as a way to create scheduling opportunities during long work. setTimeout(..., 0) is a compatibility fallback, not an exact scheduling equivalent.

---

13. Show Visual Feedback Early

When an interaction performs several operations, prioritize the visible response first.

For example:

1. Update the button or interface state.
2. Allow the next frame to render.
3. Perform less urgent analytics or background calculations afterward.

Users should not have to wait for unrelated work before seeing that their click was received.

---

14. Reduce JavaScript During Page Startup

A page can look loaded while JavaScript is still being parsed, compiled, and executed.

If visitors interact during this period, startup work can increase input delay.

Audit:

• Large application bundles.
• Unused plugin JavaScript.
• Analytics libraries.
• Advertising scripts.
• Chat widgets.
• Page-builder runtime code.

Loading fewer bytes is useful, but reducing how much JavaScript must execute is particularly important for responsiveness.

For script loading, unused JavaScript, long-task reduction, execution cost and event-work implementation, continue with the JavaScript Performance Optimization Guide. This INP guide stays focused on diagnosing the slow interaction itself.

---

15. defer Does Not Automatically Guarantee Good INP

Using:

<script src="/app.js" defer></script>

can prevent a script from blocking HTML parsing during download, but the JavaScript still needs to execute.

A large deferred script can create main-thread work after parsing and affect interactions occurring during startup.

If script or stylesheet loading is delaying initial rendering, use the Render-Blocking Resources Guide. For INP, remember that defer changes loading behavior but does not remove JavaScript execution cost.

---

16. Third-Party JavaScript

Third-party code deserves particular attention because it may execute outside your application's direct architecture.

Common examples include:

• Advertising.
• Analytics.
• Heatmaps.
• Consent-management platforms.
• Social widgets.
• Chat applications.
• Recommendation engines.

Remove obsolete tags and load only services that provide real value.

For deeper work on analytics, ads, consent tools, chat widgets and other externally controlled scripts, use the Third-Party Script Performance Guide.

---

17. WordPress Plugin JavaScript

WordPress sites can accumulate JavaScript from plugins that load assets on every page even when their interface is not present.

Examples include:

• Forms.
• Sliders.
• Popups.
• Social sharing.
• WooCommerce extensions.
• Page-builder widgets.

Audit which script handles are genuinely required on each template.

---

18. Do Not Delay Everything Until Interaction

Some performance plugins postpone large amounts of JavaScript until the first click or tap.

This can improve initial loading metrics but move expensive work directly into the user's first interaction.

The result can be:

• Fast initial render.
• Slow first menu click.
• Delayed button feedback.
• Poor INP.

---

19. Large DOM Trees Can Increase Rendering Work

Interaction handlers that modify a large document may trigger expensive style recalculation and layout work.

Common causes include:

• Deep page-builder markup.
• Large mega menus.
• Hundreds of hidden product filters.
• Large tables.
• Complex dashboard components.

Reducing unnecessary DOM complexity can improve both maintenance and runtime rendering behavior.

If large DOM trees, style recalculation or layout work dominate the trace, continue with the DOM Size & Rendering Performance Guide.

---

20. Avoid Layout Thrashing

Layout thrashing can occur when JavaScript repeatedly reads layout information and then changes styles or geometry in a loop.

For example, repeatedly mixing operations such as:

element.offsetHeight;
element.style.height = '200px';

across many elements can force additional layout calculations.

Batch DOM reads and writes where practical.

---

21. CSS Can Affect INP Too

INP is often described as a JavaScript metric, but rendering work after an event can also contribute.

Expensive style recalculation may be influenced by:

• Large DOM trees.
• Complex selectors.
• Large layout changes.
• Components that modify many elements at once.

Do not diagnose poor INP by examining JavaScript execution alone.

When expensive stylesheet delivery, selector complexity or large CSS payloads are part of the rendering problem, use the CSS Performance Optimization Guide for the deeper implementation work.

---

22. content-visibility Can Help Large Off-Screen Sections

For certain large pages, CSS content-visibility can reduce rendering work for off-screen content.

Example:

.article-section {
  content-visibility: auto;
  contain-intrinsic-size: 800px;
}

Test layout, accessibility, browser behavior, and scrolling before deploying it broadly.

---

23. Web Workers for CPU-Heavy Work

Some computational work can be moved away from the page's main thread using a Web Worker.

Potential candidates include:

• Large calculations.
• Data processing.
• Parsing large datasets.

Web Workers cannot directly manipulate the DOM, so they are useful for particular workloads rather than as a universal INP fix.

---

24. WordPress Navigation and Mobile Menus

A mobile menu is a useful interaction to test because it may combine:

• JavaScript click handlers.
• Class changes.
• Large menu DOM trees.
• Overlay rendering.
• Animations.

If the menu feels delayed, inspect the full interaction rather than assuming the hosting server is responsible.

---

25. WooCommerce Interaction Performance

WooCommerce can introduce interaction-heavy interfaces such as:

• Variation selectors.
• Mini-cart updates.
• Quantity changes.
• Filtering.
• Checkout validation.

Separate browser-side interaction latency from network requests.

A slow AJAX request and poor INP are related only when the browser blocks useful visual feedback while waiting for that response.

---

26. Network Latency and INP Are Different

INP ends when the browser displays the next frame associated with the interaction.

A button can therefore provide immediate visual feedback while a server request continues in the background.

For example:

button.addEventListener('click', async () => {
  button.textContent = 'Saving…';

  await saveToServer();

  button.textContent = 'Saved';
});

The initial “Saving…” feedback can render before the network request completes.

---

27. Faster Hosting Does Not Automatically Fix INP

Server infrastructure can affect document delivery and backend requests, but most INP bottlenecks occur in browser-side interaction processing.

A larger VPS will not automatically fix:

• Long JavaScript tasks.
• Large DOM updates.
• Third-party script execution.
• Expensive layout recalculation.
• Slow event handlers.

For server-side latency analysis, continue with our TTFB and Server Response Time Guide.

---

28. LCP and INP Need Different Optimization Strategies

Metric	Primary Focus
LCP	Document response, resource discovery, download, render delay
INP	Input delay, event processing, main-thread work, rendering after interaction

Use this comparison to keep the optimization paths separate: LCP is primarily a loading/render milestone, while INP is interaction responsiveness.

---

29. Total Blocking Time Is Not INP

Total Blocking Time is a lab metric that can help reveal main-thread blocking during page load.

INP is a field-oriented responsiveness metric covering interactions throughout a visit.

A low TBT can be encouraging, but it does not guarantee good INP because slow interactions can occur later in the page lifecycle.

Lighthouse can help surface main-thread and JavaScript problems in the lab, but it does not reproduce every real interaction pattern that contributes to field INP. Treat TBT and lab traces as diagnostic clues, not as a replacement for field INP.

---

30. Test Real User Flows

Do not test only the initial page load.

For a WordPress site, interaction testing might include:

1. Open mobile navigation.
2. Expand a submenu.
3. Use site search.
4. Open an accordion.
5. Submit a form validation step.
6. Interact with a consent banner.

For ecommerce, add cart and filtering interactions.

---

31. Test During Page Load Too

Visitors do not always wait for a page to become completely idle before interacting.

Test important interactions while:

• Analytics initializes.
• Advertising loads.
• Deferred JavaScript executes.
• Images are still loading.

This can expose startup main-thread contention that an idle-page test misses.

---

32. Capture More Specific RUM Data When Possible

If your analytics or RUM stack supports it, collect enough context to identify the interaction rather than recording only a page-level INP number.

The attribution build of the web-vitals library can expose the interaction target, interaction type, input delay, processing duration, presentation delay and associated Long Animation Frame entries in supporting browsers.

import { onINP } from 'web-vitals/attribution';

onINP(({ value, rating, attribution }) => {
  const {
    interactionTarget,
    interactionType,
    inputDelay,
    processingDuration,
    presentationDelay,
    longAnimationFrameEntries
  } = attribution;

  sendInpData({
    value,
    rating,
    interactionTarget,
    interactionType,
    inputDelay,
    processingDuration,
    presentationDelay,
    loafCount: longAnimationFrameEntries?.length || 0
  });
});

Send only the minimum diagnostic information required for performance analysis. Avoid collecting form values, typed text, account identifiers or other sensitive content merely to debug INP.

Useful dimensions include:

• page template;
• interaction target or element label;
• device class;
• input delay;
• processing duration;
• presentation delay;
• release/version;
• major third-party script state.

This makes it much easier to distinguish “the site has poor INP” from “the mobile filter interaction on product pages is slow after consent scripts initialize.”

---

33. Before/After Trace Worksheet

Do not publish “INP improved” without recording what interaction changed and under what conditions.

A lab improvement is evidence for the reproduced flow, not a replacement for later field validation at the 75th percentile.

---

34. INP Optimization Workflow

1. Check field data: Confirm that INP genuinely needs improvement.
2. Identify affected templates: Articles, product pages, checkout, homepage, or application views.
3. Find the slow interaction: Menu, filter, form, button, input, or other control.
4. Reproduce it in the lab.
5. Separate the interaction: Input delay, processing duration, presentation delay.
6. Inspect long tasks.
7. Reduce unnecessary JavaScript.
8. Optimize event callbacks.
9. Reduce DOM and rendering cost.
10. Re-test on slower hardware.
11. Deploy carefully.
12. Monitor field data after rollout.

---

35. INP Specialist Guide Map

---

Summary: INP Optimization Checklist

• Target INP of 200 milliseconds or less at the 75th percentile.
• Start with field data where available.
• Identify the actual slow interaction.
• Separate input delay, processing duration, and presentation delay.
• Reduce long main-thread tasks.
• Reduce unnecessary startup JavaScript.
• Keep event handlers small where practical.
• Show important visual feedback early.
• Move noncritical work out of the immediate interaction path.
• Audit third-party JavaScript.
• Investigate embedded iframes when CrUX INP is worse than top-level RUM attribution suggests.
• Remove unused WordPress plugin scripts where safe.
• Do not delay massive JavaScript bundles until the first interaction.
• Reduce unnecessary DOM complexity.
• Avoid repeated forced layout work.
• Remember that CSS and rendering can affect INP too.
• Do not assume faster hosting fixes browser-side interaction delays.
• Do not treat TBT as identical to INP.
• Test real interaction flows during and after page load.

Frequently Asked Questions

What is a good INP score?

A good Interaction to Next Paint value is 200 milliseconds or less at the 75th percentile of page visits.

What causes poor INP?

Common causes include long main-thread tasks, heavy JavaScript execution, slow event handlers, third-party scripts, large DOM changes, expensive style calculations, and rendering work after an interaction.

Is INP a server-speed metric?

No. INP primarily measures browser interaction responsiveness. Server requests can influence application behavior, but a faster server does not automatically repair main-thread JavaScript or rendering bottlenecks.

Does defer fix INP?

Not automatically. Defer can improve script loading behavior, but the JavaScript still needs to execute and can still create long tasks or expensive interactions.

Is Total Blocking Time the same as INP?

No. Total Blocking Time is primarily a lab loading metric, while INP measures real interaction responsiveness throughout a page visit.

Can WordPress plugins cause poor INP?

Yes. Plugins can add frontend scripts, event listeners, large DOM structures, third-party widgets, or expensive interaction behavior. Diagnose individual resources before removing functionality.

Can reducing JavaScript improve INP?

Often, especially when unnecessary JavaScript creates long main-thread tasks. However, rendering and DOM complexity can also contribute to interaction latency.

Why can CrUX INP be worse than my own RUM measurement?

One reason can be interactions inside embedded iframes. Page-level INP includes relevant iframe interactions for the user experience, while top-level JavaScript cannot always attribute cross-origin iframe activity. Compare the affected templates and embedded third-party interfaces before assuming either dataset is incorrect.

Does good INP guarantee higher Google rankings?

No. INP is one component of Core Web Vitals and page experience. Search performance also depends on relevance, content quality, crawlability, indexing, competition, links, and other signals.