---
title: "INP in WordPress: fixing slow interactions"
id: "513"
type: "post"
slug: "inp-wordpress"
published_at: "2026-10-06T15:13:52+00:00"
modified_at: "2026-10-06T15:13:52+00:00"
url: "https://danielpazwp.com/inp-wordpress/"
markdown_url: "https://danielpazwp.com/inp-wordpress.md"
excerpt: "Why WordPress sites fail INP, how to find the slow interaction in field data, and how to cut third-party scripts, plugin JavaScript and DOM size."
taxonomy_category:
  - "Performance"
---

[Performance](https://danielpazwp.com/category/performance/)
7 min read

# INP in WordPress: fixing slow interactions

Why WordPress sites fail INP, how to find the slow interaction in field data, and how to cut third-party scripts, plugin JavaScript and DOM size.

Published **06/10/2026**7 min read

[Written byDaniel PazDaniel Paz has worked on the web for more than 14 years and has focused on WordPress since 2016. He is CEO and founder of WebOption, creator of WP Alta Performance (Brazil’s reference channel on WordPress optimization) and has shipped WordPress for Globo, Shell, Endeavor, Estratégia Concursos and Brazil’s Federal Government. He speaks at WordCamp Brazil, WordCamp Canada and WordCamp US, TDC and PHP Conference Brazil.](https://danielpazwp.com/author/daniel-paz/)

To fix INP in WordPress, find which interactions are slow in field data, then cut the main-thread work around them. INP (Interaction to Next Paint) measures the time from a click, tap or key press until the browser paints the next frame, and Google rates 200 milliseconds or less at the 75th percentile as good, and more than 500 milliseconds as poor. On WordPress the usual causes are third-party scripts, plugin JavaScript loaded on every page, heavy handlers in menus, filters and carts, and large page builder DOMs. Remove or defer scripts, break up long tasks and shrink the DOM.

INP became a Core Web Vital in March 2024, replacing First Input Delay. A WordPress site that passed FID easily can fail INP, because INP measures far more of the work. This guide covers how to find the slow interaction and what to change on a WordPress site. For how INP fits with LCP and CLS, see [Core Web Vitals for WordPress: the complete guide](https://danielpazwp.com/core-web-vitals-wordpress/)
.

## What does INP measure?

Every interaction (click, tap or key press) has three phases:

1. Input delay: the time before the browser can start running your event handlers, usually because another task is already running on the main thread.
2. Processing duration: the time your handlers take to run, including every listener attached to that event.
3. Presentation delay: the time to recalculate styles, run layout and paint the next frame after the handlers finish.

The browser observes interactions during the whole visit. A page’s INP is close to its slowest interaction. On pages with many interactions, one outlier is ignored for every 50 interactions, so INP reports a high percentile instead of a single unlucky click. Hovering and scrolling are not counted.

FID only measured the input delay of the first interaction. INP adds processing and presentation, and it looks at every interaction. That is why sites with a fast first click but a slow mega menu, filter or add-to-cart now fail.

## Why doesn’t Lighthouse show INP?

A Lighthouse run loads the page without anyone touching it, so there is no interaction to measure. Lighthouse reports Total Blocking Time instead, which counts how much main-thread blocking happens during load. High TBT usually means poor INP, but a page can have low TBT and still have one terrible interaction later in the visit. I go deeper on this in [field data vs lab data for Core Web Vitals](https://danielpazwp.com/core-web-vitals-field-data-vs-lab-data/)
.

To find the slow interactions:

- Check the INP value in PageSpeed Insights or the Search Console Core Web Vitals report to see which templates fail, on which device.
- Add the attribution build of the web-vitals library to collect real interactions. It reports the target element, the event type, the three phases, and the scripts behind long animation frames.
- Reproduce in the Chrome DevTools Performance panel. Turn on CPU throttling, because your laptop is much faster than the phones in your field data, then record while you open the menu, choose a variation or apply a filter.

## What causes poor INP on WordPress?

| Cause | Where it shows up | Fix |
| --- | --- | --- |
| Third-party tags (tag manager, chat, heatmaps, consent, ads) | Input delay during and after load | Remove unused tags, load the rest later, test consent and chat tools on a phone |
| Plugin JavaScript on every page | Input delay and processing | Dequeue per template, replace heavy plugins |
| Heavy event handlers | Processing duration on menus, filters, variation selectors, add to cart | Show feedback first, defer the rest, yield between steps |
| Large page builder DOM | Presentation delay after every interaction | Simplify layouts, fewer wrappers, fewer widgets per page |
| “Delay JavaScript until interaction” | The first tap triggers loading and running of every delayed script | Exclude scripts needed for the first interactions, measure in the field |
| Layout thrashing in scripts | Processing duration | Batch DOM reads before writes, avoid forced synchronous layout |

The third-party row is the one I find most often, and the hardest to fix politically. Marketing added each tag for a reason, and nobody remembers which ones still matter. Start with an inventory: tag, owner, purpose, pages where it fires. Removing tags that nobody can justify is often the fastest INP win on the whole site.

The delayed JavaScript row deserves attention because it looks like a fix. Caching plugins can hold scripts back until the first user interaction. Lab scores improve, since nothing runs during load. Then the visitor taps the menu, every delayed script loads and runs at once, and that tap becomes the slowest interaction of the visit. Use the feature, but exclude the scripts your first interactions depend on, and judge it by INP in the field, not by Lighthouse.

## How do I reduce JavaScript work in WordPress?

Start by loading less. For your own scripts, use the loading strategies added in WordPress 6.3:

`wp_enqueue_script( 'my-menu', $src, array(), $ver, array( 'strategy' => 'defer', 'in_footer' => true ) );`

For plugin scripts that load everywhere, dequeue them on templates that don’t use them. Hook into `wp_enqueue_scripts` with a priority later than the plugin, check the template with conditional tags such as `is_singular()` or `is_page()`, and call `wp_dequeue_script()` with the plugin’s handle. Query Monitor lists the enqueued scripts and their handles.

Then make the remaining work cheaper:

- Give feedback first. Update the button state or open the menu, then do the expensive work in a later task.
- Break long tasks into smaller ones and yield to the main thread between them. `scheduler.yield()` does this where the browser supports it, and `setTimeout` works as a fallback.
- Debounce input handlers on search fields and filters so they don’t run on every key press.
- Read layout values (sizes, positions) before writing styles, not in alternating order inside a loop.
- Avoid re-rendering a large part of the page when only a small part changed, a common problem with AJAX filters and cart fragments.

## Does the Interactivity API help INP?

The Interactivity API, stable in core since WordPress 6.5, is the standard way to add front-end interactivity to blocks. Core blocks such as Navigation, Search, Query pagination and the image lightbox use it. The markup is rendered on the server, behavior is declared with directives, and interactive blocks from different plugins share one runtime instead of each shipping its own library.

That helps INP indirectly: less JavaScript to download, parse and run, and no separate framework per plugin. It doesn’t make slow handler code fast. If your store logic does heavy work on every click, it will still block the main thread. For new custom interactive blocks I prefer the Interactivity API over a jQuery plugin or a one-off React bundle, because the cost stays visible and shared.

## How do page builders affect INP?

Every interaction that changes the page makes the browser recalculate styles and layout. The more elements on the page, the more expensive that becomes, and it lands in presentation delay. Page builders like Elementor and Divi nest several wrapper elements around each widget, and long landing pages built with them can reach a DOM size that Lighthouse flags as excessive.

On Elementor, container-based layouts produce fewer wrappers than the older section and column structure. Beyond that, the fixes are editorial: fewer widgets per page, no hidden duplicate sections for mobile and desktop, and no mega menu that renders hundreds of links into every page. Builder assets also affect loading, which I cover in [how to improve LCP in WordPress](https://danielpazwp.com/lcp-wordpress/)
. Shifting content during interactions is a separate issue, covered in [how to reduce CLS in WordPress](https://danielpazwp.com/cls-wordpress/)
.

## How do I verify an INP fix?

Record the same interaction in DevTools before and after, with the same CPU throttling, and compare the three phases. Then watch your real user monitoring data, which shows the change within days. CrUX needs its full 28-day window, so PageSpeed Insights and Search Console will lag behind. If INP only improves in the lab, you probably moved the work instead of removing it.

## Want a second pair of eyes on your INP?

INP problems are often spread across a theme, a few plugins and a tag manager, and each owner believes the problem is somewhere else. I trace the slow interactions in field data back to the scripts that cause them and give you a prioritized fix list. Read more about [working with me as a Core Web Vitals expert](https://danielpazwp.com/core-web-vitals-expert/)
.

[Work with Daniel](https://danielpazwp.com/#book)
[More in Performance](https://danielpazwp.com/category/performance/)

[About the authorDaniel Paz has worked on the web for more than 14 years and has focused on WordPress since 2016. He is CEO and founder of WebOption, creator of WP Alta Performance (Brazil’s reference channel on WordPress optimization) and has shipped WordPress for Globo, Shell, Endeavor, Estratégia Concursos and Brazil’s Federal Government. He speaks at WordCamp Brazil, WordCamp Canada and WordCamp US, TDC and PHP Conference Brazil.Author page](https://danielpazwp.com/author/daniel-paz/)

## Related articles

[All articles](https://danielpazwp.com/blog/)

[Performance Oct 2026Elementor vs Gutenberg performance: what the architecture means](https://danielpazwp.com/elementor-vs-gutenberg-performance/)
[Performance Oct 2026WooCommerce speed optimization: an engineer’s order of work](https://danielpazwp.com/woocommerce-speed-optimization/)
[Performance Oct 2026How to fix a slow WooCommerce admin](https://danielpazwp.com/woocommerce-slow-admin/)