Quick Summary: Interaction to Next Paint (INP), which replaced First Input Delay (FID) as one of Google’s Core Web Vitals in March 2024, measures how responsive each individual interaction is on a web page, where an acceptable response time is under 200ms. The most typical INP killers found in WordPress sites include heavy plugin JavaScript, third party code loaded by plugins or widgets, render blocking CSS/JS files, and excessive DOM size created by drag-and-drop page builders. Common remedies for these issues can be achieved through delay non-essential third-party code loading, event handler optimization, and offloading all computationally expensive tasks to a new type of thread called a Web Worker. Additionally, reduce the depth of your DOM.
The replacement of First Input Delay (FID) for Interaction to Next Paint (INP), in March 2024, as a “Core Web Vitals” metric by Google is not just an aesthetic change. FID measured only the time it took to have your first interaction or input on a web-page. INP measures how responsive all interactions are — be they from mouse-clicks, taps, or keyboard-inputs — throughout your entire session, then records the worst interaction time.
The movement to Interactive Performance (INP) has shown issues of site speed that previously went unnoticed in terms of First Input Delay (FID). Sites that easily met FID requirements are now having difficulty meeting INP standards due to a slow interaction at some point beyond the first ten to twenty interactions on the site regardless of how quickly those initial interactions may have been. Third party code loaded by a multitude of WordPress plugins, as well as complicated DOM structures, have made it difficult for many WordPress developers to meet the Interactive Performance requirement.
A failure of INP occurs when an interaction takes longer than 200 milliseconds after the users’ first input before the next visual update; therefore, if you find yourself with an interaction taking longer than 200 milliseconds then your INP will fail. Below is information about diagnosing and fixing common INP failures on WordPress sites.
What Is INP and Why Google Replaced FID With It
The biggest drawback with measuring FID was that there are only two components of the overall interaction process; input delay and no other measures existed to capture the rest of the user experience. As a result, a web page can be considered fast by its FID, but subsequent actions such as opening a navigation drop-down or expanding/collapsing accordions may still be too slow.
INP captures the entire life-cycle of every interaction on a webpage including input delay (the time elapsed until the browser begins processing) processing time (the amount of time required for all event handlers) and presentation delay (how long it takes the browser to render the final viewable state) and all three are used in calculating the total interaction time.
Google uses INP as the 75th percentile of all interaction times across ALL PAGE VISITS. Therefore, 75% of your actual users will have to see time to interact at 200ms or less for your page to pass. You can’t optimize for one quick test – you have to make sure that you are performing consistently well with the way people really use your site.
This is an inherently much tougher problem for WP Sites than LCP or CLS. It requires controlling how JAVASCRIPT executes on your site (and therefore how quickly), third party script timing and how complex your DOM is, all things that most WP Site configurations do NOT address out-of-the-box.
Common INP Killers in WordPress
Most common WordPress setups include many factors which contribute to low INP scores.
JavaScript is added by every interactive plugin. All of these plugins (Sliders, Mega Menus, Form Builders, WooCommerce) add JavaScript code that will run on the main thread. When a user interacts with the page, the browser must complete any existing JavaScript tasks prior to responding. If one plugin takes 100 milliseconds to perform a function, ALL interaction will be blocked during this time.
Scripts from Third-parties.. the time of the primary thread is competed for by analytics (Google Analytics, Facebook Pixel) chat widgets (Intercom, Drift, livechat) social media share buttons, embedded video scripts and adverting scripts. On average an average business WordPress website has 5 to 15 Third party scripts which all add some amount of processing load.
Resources that block rendering.. CSS and JavaScript files that are required to be downloaded and processed before the web-browser responds to user actions will increase input lag. Most WordPress plugins also include their stylesheets and script in the document header without either defer or async attributes so they block the rendering of the web-Page until they have been loaded and processed.
Larger than normal DOM size. developers who use a Page builder such as elementor, Divi, or WPBakery create HTML structures that are much deeper. When you build a Page using a developer you may get about 500 DOM elements but with a Page builder you could easily end up with 3000 to 5000. The larger your DOM size then the longer it takes for style recalculations to complete and the longer it takes to render the web-Page every time the user interacts with it.
Diagnosing INP Issues
Before you optimize your input fields (INP), you first have to determine which interactions are taking too long and why.
Page Speed Insights by Google provides a comparison of your actual input field data from real chrome users and lab generated input field data. Your input field performance is used by Google as part of their decision process for how to rank your site. If your actual input field performance is listed in red (greater than 500ms) or yellow (200-500ms), you have some work to be done.
Performance Tab within Chrome Dev Tools. Once you’ve identified an interaction that may be causing a delay, record a trace while using this interaction on your page. While analyzing the trace look at each long task (long blocks of main thread time greater than 50ms). Identify the long tasks that occur at approximately the same time as your interaction. Use the trace to see specifically which script(s) are causing the delay.
The web-vitals JavaScript library. the inclusion of Google’s “Web-vitals” on a website can provide data regarding real users interacting with the site. In addition to providing data about what was being interacted with (i.e., the element) and how long that interaction took, this provides an additional level of detail, including input delay (how long did it take before the computer could process the user’s action), processing time (the amount of time it took for the computer to respond to the user’s action), and presentation delay (how long did it take for the computer to visually display its response). Therefore, since it captures actual user behavior, this is considered the best way to diagnose issues related to INP.
Google’s chrome Web vitals extension. once installed in a user’s browser, the Web vitals extension allows them to see their own experience while using your site. Each time they interact with something on your site, it will highlight whether or not that interaction exceeded the 200 ms threshold.
Fix 1 — Reduce Third-Party Script Impact
Third party scripting is by far the most frequent source of poorly performing INP on WP sites due to lack of control over their performance.
Audit every third-party script. Write down every single external script your site calls and review them individually asking; Do you really need to continue loading this script? Is there another way to accomplish what you want with less overhead? Would changing how you call the script make a difference?
Delays for non-critical scripts. there is no reason to load analytics, chat widgets or other social scripts immediately as they don’t require immediate loading. Using a “delay” method for these scripts will allow you to use an on user action (scroll, click or mouse movement) and/or a time out of 3 to 5 seconds to trigger their loading. This leaves the main thread open while you are in your most important loading phase.
When possible Self-host your own content. when you call up content from another domain it increases your DNS lookup and your connection times. Both google’s own services including Google Analytics and google fonts can be Self-hosted to remove both DNS and connection latency.
Use lighter versions of heavy widgets. a full featured live chat widget can add anywhere from 200 kb to 500 kb of JavaScript. Is a simple contact form or click-to-chat link serving the same function but at less than one tenth of the cost?
Fix 2 — Optimize Event Handlers
All click handlers, scroll listeners, and input handlers on your page run javascript in the main thread. Handlers that are poorly constructed will increase INP directly.
Debounce and throttle all of your scroll and resize handlers. If you have an event handler for a scroll event that is running some complicated logic with each pixel scrolled, then this will cause continuous blocking of the main thread. De-bounding (only executing the handler when scrolling has stopped) or throttling (only execute the handler as many times per second as possible to a maximum of one time every 100 milliseconds) drastically decreases main thread pressure.
Lazy load interactive components. The mega menu doesn’t require all of the JavaScript used to create the interactive elements to be loaded and parsed when the visitor first visits your site. Instead of loading all interaction code at once (which will increase the size of the main thread), you can lazy load it on an as-needed basis by creating the code only when the visitor hovers over the menu trigger.
Batch your DOM updates using requestAnimationFrame. When event handlers are updating the DOM they should use requestAnimationFrame to batch these updates together in order to allow the browser to better optimize how the browser is rendering.
Fix 3 — Web Worker Offloading for Heavy Computations
The primary purpose of Web Workers is to allow you to run JavaScript in a separate (background) thread; therefore freeing up the Main Thread for User Interactions.
Potential Candidates for Off-Loading. Any data intensive process, such as processing large amounts of data, performing complex mathematical operations, large array sorting or other similar operation could be off-loaded into a Web Worker.
Practical implementation. Write a Web Worker script and pass data to it via a POST request from your main thread’s event handler. Once the Web Worker has processed the data you will have the results returned to your main thread so it may continue to process events without interruption by the Worker processing in the background.
Restrictions. A Web Worker does not allow direct access to a Document Object Model (DOM). Therefore, they are ideal for heavy computations rather than those requiring either reading or writing of page objects.
Fix 4 — Efficient DOM Management
A large DOM (Document Object Model) can slow down each user interaction because of all the style and layout calculations that are performed over a larger number of objects when you are using a Deeply Nested DOM.
Reduce DOM depth. The elements created by page builders often get wrapped in several levels of nested containers. When creating content for your website, try to keep it simple. For the most important pages on your site, if possible replace some or all of the sections of your page builder with custom coded versions that utilize less elements.
Don’t cause a browser to “thrash” while laying out. When JavaScript gets some kind of value from an object that has been laid out (for example, offsetHeight) then makes changes to the DOM (which causes a new layout) then goes back to reading values — that is called thrashing. Get all of the values you are going to need before making any DOM modifications. Then modify the DOM.
Tell the browser to NOT do any rendering on off screen content. The content-visibility: auto; CSS will tell the browser to ignore rendering anything it doesn’t think can be seen. If you have a very long page with lots of sections, turning off rendering of offscreen content could cut your rendering time down 30% to 50%.
Only show users what they can see. If you have hundreds of products or directory entries or data tables etc., showing them all at once may overwhelm the user’s experience. Instead of rendering every item, just render the ones that fit into their view port and use those same rendered pieces over and over as they scroll through the list.
Testing and Monitoring Ongoing INP Compliance
One-time testing of INP will be insufficient as every time that you test or update your plugin, add in some new content, or install a new third party application this could cause your INP score to fall.
You should monitor field data on an ongoing basis. The Core Web Vitals report within Google Search Console has the ability to give you a view of how INP is performing at the page group level. Monthly updates to the field data means that it may take several months before a regression appears (but by then you have lost valuable time).
Use Real User Monitoring. Add the web-vitals library using a reporting endpoint to track all visits and allow you to see if there are any regressions occurring in real-time vs. having to wait until Google performs their next monthly update.
After each modification test. The testing of new themes, new plugins, and the added use of third party scripts with an INP will be done in Staging before it is deployed. The addition of one poorly written plugin can increase your INP from 150ms to 400ms.
Create a Performance Budget. Create limits (max) for the size of your JavaScript bundles, number of DOM elements and the number of Third Party Scripts you are using. Any proposed addition or update needs to have these budgets reviewed. Remediation is much harder than prevention.
Struggling with INP on your WordPress site? Talk to our speed optimization team →
This article is part of our WordPress Speed Optimization Guide — the complete resource for maintaining a fast, secure WordPress site.
Frequently Asked Questions
A score of less than 200ms is “good” (Green) ; Between 200 and 500ms you have “room for improvement” (Yellow); Any score over 500ms is “Poor” (Red); And to get some buffer room from normal variability and for competitive SEO, shoot to be at or below 150ms.
Yes; INP is an identified ranking factor by Google as one of its three Core Web Vitals. The higher your INP, the greater chance there is that you’ll rank behind similarly qualified competitors who have better INP scores.
No, caching will improve both Time To First Byte (TTFB), which measures how long it takes for your page to load, and Largest Contentful Paint (LCP), which measures the time it takes for your page to render all content. However, caching doesn’t address the issue of how fast your page responds to user interaction once loaded. INP is a Front-End Problem related to JavaScript and Rendering; It is NOT a Server-Side Caching Issue. If object caching triggers server calls when users interact with the page, then it could help reduce the impact of INP. Most INP issues are Client-Side Problems.
Generally Yes; As many WP websites are built using Plugins which introduce arbitrary amounts of uncontrolled JavaScript. While a custom-built website allows complete control over every bit of code, WP Websites are comprised of anywhere from 10 to 30 different plugins each generating their own JavaScript. Thus, Professional Optimization — and Ongoing Maintenance — is much more important for WP Websites.
