How to Improve INP in WordPress (Interaction to Next Paint Guide)
When you interact with a menu, open an accordion, or press an “Add to cart” button, there can be a moment of hesitation. The page doesn’t freeze; it just feels unresponsive. This sensation has a specific term known as Interaction to Next Paint (INP), which Google monitors with every visit.
INP is now one of the Core Web Vitals, having officially replaced First Input Delay (FID) on March 12, 2024. Unlike FID, which evaluated only the first interaction a user made on your page, INP tracks **all** clicks, taps, and keystrokes during the entire session, reporting on the slowest of these actions.
The silver lining is that most INP-related issues can be traced back to a few common culprits (such as JavaScript from plugins, page builder bundles, or third-party tags), and identifying these doesn’t require a degree in performance engineering.
This guide will elucidate what INP measures in straightforward terms, how to evaluate your current status **before** making any adjustments, and the corresponding WordPress fixes categorised by their potential impact. Let’s get started!
Understanding INP: What It Measures (Simplified)
INP stands for Interaction to Next Paint. Simply put, it measures the duration from when a user performs an action (like clicking a button or typing) to when the browser renders the next visual response on the page. This includes actions such as opening a menu, updating a shopping cart, or responding to form inputs. If the next visual change is delayed too long, the site may feel broken, even if it’s still technically functional.
INP differs from older metrics in several key ways:
- It evaluates the entire visit, not just the initial load. Google’s own usage analysis indicates that users spend 90% of their time on a page after it has loaded, so metrics limited to first impressions overlook most of the actual experience.
- It reports the slowest typical interaction. INP records every interaction, ultimately reflecting the slowest one as its score—discarding a small number of genuine outliers. The resulting score is derived from the 75th percentile of actual visits.
- It encompasses the entire interaction process. Each interaction involves three stages: input delay (the browser was occupied when the user clicked), processing time (executing the JavaScript triggered by the click), and presentation delay (rendering the outcome). INP measures all three.
- Only genuine inputs count: such as clicks, taps, and keystrokes. Scrolling and hovering are not included.
The scoring is straightforward:
- 200 ms or less: Excellent responsiveness.
- 200 to 500 ms: Improvement needed.
- Over 500 ms: Poor performance.
INP vs FID vs LCP: Clarifying the Distinction
These three metrics are often confused, so let’s clear them up:
| Metric | Description | Good Score |
|---|---|---|
| FID (First Input Delay) | Measures only the input delay of the initial interaction. It’s purely a responsiveness check at the moment of loading. | Retired (replaced by INP in March 2024) |
| INP (Interaction to Next Paint) | Measures the overall duration of virtually every interaction during the visit, from input to the next rendered frame. | 200 ms or less |
| LCP (Largest Contentful Paint) | Tracks loading performance, specifically how long it takes for the largest visible element to appear. | 2.5 s or less |
While passing FID was often accidental by succeeding on the first click, INP was developed to provide a complete picture. On the other hand, LCP addresses a separate query (whether the page loads quickly), which is why optimising images aids LCP but does little for INP. If you’re experiencing issues with a lazily loaded LCP image, there’s a dedicated guide available on the blog.
This article will focus solely on INP. For a comprehensive understanding of all three Core Web Vitals, including CLS and their potential impact on rankings, check out the complete Google Core Web Vitals guide.
Step 1: Assess Your INP Before Making Changes
Resist the temptation to begin uninstalling plugins immediately. INP is a field metric, meaning it derives its results from actual users on actual devices. Your first task is to establish whether there’s a problem and, if so, where it exists.
Begin with PageSpeed Insights. Enter your URL, run the test, and examine the “Core Web Vitals Assessment” section at the top. This part contains field data from the Chrome User Experience Report (CrUX), the official dataset for Web Vitals, taken from the 75th percentile of genuine visits over the preceding 28 days. Below is an example illustrating this very blog:
With an INP of 194 ms, we’re in the clear, though there’s not much room for complacency. If your URLs fall into the yellow or red zones, keep reading.
Note: New or low-traffic sites may display “not enough usage data” instead of a score, as CrUX requires a minimum volume of real Chrome visitors. Occasionally, you might receive origin-level data instead of page-level data. If neither are available, use the lab approach outlined below and revisit as traffic increases.
Field data informs you **that** there are latency issues, while Chrome DevTools explains **why**. Launch your page in Chrome and follow these steps:
- Open DevTools and select the Performance tab.
- Click Record, then interact with your page as an actual visitor might: open the mobile menu, conduct a search, add an item to the cart, or click a filter.
- Stop recording and check the Main thread track.
The main things to look for are long tasks: any task that ties up the main thread for more than 50 ms. DevTools indicates these with a red triangle at the corner and a striped red section. During a long task, the user’s click is held up, and that waiting time is exactly what INP measures. The Bottom-up or Summary views below will break down main thread usage by first-party and third-party scripts, spotlighting the offenders:
For detailed guidance, refer to the Performance panel documentation. Additionally, the Search Console Core Web Vitals report provides a site-wide overview, grouping URLs that have similar issues.
PRO TIP: Lab tools cannot independently capture INP, as nothing interacts with the page during a lab test. If you have field data available, use Total Blocking Time (TBT) from the Lighthouse lab report as a makeshift alternative. While it’s not a substitute for INP, a high TBT typically indicates that INP issues may arise.
Step 2: Address the Common WordPress Issues (Listed by Impact)
Most factors that negatively impact INP on a WordPress site stem from JavaScript vying for the main thread’s attention. The following solutions are organised based on where WordPress sites usually see the most significant gains, not necessarily based on how enjoyable they are.
1. Evaluate Your Plugin Bloat
Each active plugin can inject JavaScript into every page, even those where it is not necessary. Do you have a contact form plugin from 2023? Its scripts might still be active on all 400 of your blog posts. Navigate to Plugins → Installed Plugins and deactivate (and delete) anything that doesn’t actively contribute to your site’s performance. Whenever possible, opt for plugins that load assets solely on the relevant pages.
If you have a staging site, test your changes there and re-examine the INP after the clean-up to assess the impact of each removal.
2. Defer or Delay Non-Critical JavaScript
Scripts for analytics, popups, chat tools, and social pixels don’t need to execute immediately when the page loads. By deferring them until after the user interacts (or at least postponing them until after the primary content has rendered), you free up the main thread when visitors begin clicking.
You don’t need to code this yourself! WP Rocket (premium) features a Delay JavaScript execution option, while Flying Scripts (a free option) offers a similar capability with a straightforward keyword rule list. Most reliable performance plugins also allow for script deferral.
CAUTION: Delaying the wrong script can disrupt functionalities. Elements like sliders, menus, and cookie banners are often affected. Implement changes one at a time and thoroughly check your core pages after each adjustment. While it may seem tedious, it’s faster than trying to debug multiple changes simultaneously.
3. Streamline Page Builder and Slider Scripts
Page builders and slider plugins are common offenders for high INP due to their often hefty JavaScript payloads, which might load sitewide. Many builders come with performance features allowing you to unload unused widgets or restrict asset loading to relevant pages; so explore those settings before assuming you have no alternatives. If a slider is only applicable to one page, there’s no need for it to load sitewide.
The unembellished fact is: if your INP is subpar and a hero slider is to blame, replacing it with a static hero section is the solution. No one has ever grieved the loss of a slider.
4. Trim Third-Party Tags
Chat widgets, heatmaps, and A/B testing scripts, along with social pixels, each add to the main thread workload, and you have no control over the quality of their code. The breakdown of third-party usage from Step 1 will help you pinpoint who consumes what. Remove any tags that you don’t actively use (be ruthless; “potential future use” is not a valid reason), and apply delays to the remaining tags based on the previous point.
5. Keep in Mind That Hosting Context Matters, Not Just Fixes
INP operates in the browser, not directly from your server, so upgrading to a faster host won’t necessarily improve it. The Time to First Byte doesn’t factor into the INP scores. However, a sluggish server can hold everything up, including the moment the main thread finally settles enough to respond swiftly to early user actions. If your TTFB is also lagging, rectify it as part of your comprehensive speed enhancement strategy (this WordPress speed guide discusses it). Don’t expect a hosting enhancement to alleviate JavaScript-related issues.
Limitations of What You Can Fix (And Alternative Solutions)
It’s time to be realistic, as much advice regarding INP seems to imply that everything is adjustable. However, that’s not always the case.
Necessary Third-Party Embeds. Features like support chat, payment forms, and embedded content run their own JavaScript which counts towards your INP. Your users won’t discern whose code is responsible for longer load times, nor can the metric. You can’t optimise someone else’s code, but you can manage when it loads: consider click-to-load options for videos or chat widgets that only initialise post-interaction, and static images for maps until users interact.
Advertising. If your site relies on display ads, the scripts that operate them can be some of the heaviest on the page, with bidders and refresh rates demanding main thread resources throughout the user’s session. Ad tech settings can offer minor enhancements, but often the most straightforward remedy is to eliminate certain placements or features rather than fine-tuning them. Treat your INP as a discussion between costs and benefits: every script on the page should justify its presence.
Low-End Devices. Bear in mind that the 75th percentile includes users on budget Android devices that may lack the performance of your MacBook. Enable CPU throttling in the Performance panel when recording in DevTools to better reflect the experience of these users.
Conclusion
INP ultimately reduces to a fundamental principle: when a user performs an action, an observable reaction should happen quickly. The recommended approach, in sequence, is as follows:
- Measure first using field data from PageSpeed Insights, and identify long tasks within the DevTools Performance panel before making changes.
- Cull JavaScript at the source: conduct a plugin audit, then defer or delay any remaining non-essential scripts.
- Address any bulky bundles: page builder and slider scripts, then tackle third-party tags.
- Recognise limitations: any necessary embeds and ads can be deferred or click-to-load, and sometimes the best course is to remove them altogether.
Following this sequence will help your INP score stay comfortably below 200 ms. Your visitors may not express their gratitude, but they will explore your site with greater ease, and Google will take note.
What’s the most significant INP issue you’ve identified on your website? Share your thoughts in the comments below!
FREE GUIDE
4 Essential Steps to Speed Up Your WordPress Website
Follow these simple steps in our 4-part series to reduce your loading times by 50-80%.
