Interaction to Next Paint became a Core Web Vital in March 2024, replacing First Input Delay. For WordPress site owners, this change matters more than it did for any other platform. WordPress's combination of jQuery dependency, plugin-per-feature architecture, and page builder JavaScript makes it structurally one of the hardest environments in which to achieve Good INP scores. A WordPress site with Elementor, a contact form plugin, a chat widget, and Google Analytics loaded synchronously will typically measure 400 to 700ms INP on a mid-range Android device — well into the "Poor" range that affects rankings. This guide shows you how to diagnose exactly what is causing your INP problem and fix it methodically.
What INP Actually Measures — and Why WordPress Struggles
INP measures the time from when a user initiates an interaction — clicking a button, tapping a link, pressing a key — to when the browser visually updates the page in response. It collects this measurement for all interactions during a page visit and reports the worst one. Good is under 200ms. Needs Improvement is 200–500ms. Poor is above 500ms.
The reason WordPress scores poorly is structural. When a user clicks something, the browser's main thread must: (1) process the click event, (2) run any JavaScript event handlers attached to that element, (3) perform any resulting DOM changes, (4) recalculate styles, (5) layout the changed elements, and (6) paint the result. Any JavaScript running on the main thread during steps 1–4 delays the visual update at step 6. A typical Elementor WordPress site has dozens of event listeners registered by various plugins, all of which can run during a click event and extend the time to visual response.
jQuery makes this worse. WordPress ships with jQuery, and most plugins attach event listeners via jQuery's $(document).ready() callback. When the page loads, all these plugins initialise simultaneously, running setup code that blocks the main thread for hundreds of milliseconds — right at the moment the page becomes nominally interactive, but before it is genuinely responsive.
Diagnosing Your WordPress INP Score
Step 1: Check Search Console field data first
Before profiling individual interactions, confirm how bad the INP problem is in real field data. In Google Search Console, navigate to Core Web Vitals and look at your mobile CWV report. Click through to see which URLs are categorised as "Poor" — these are the pages where real Chrome users are experiencing INP above 500ms. Prioritise these pages for your investigation.
Step 2: Use Chrome DevTools Performance panel
Open the problematic page in Chrome. Open DevTools (F12), go to the Performance tab, and click the Record button. Perform the interaction that you suspect is causing poor INP — usually a menu click, an accordion open, a form field focus, or a button click. Wait for the visual update to complete, then stop recording. Look at the resulting timeline for "Long Tasks" — red-topped bars indicating JavaScript execution over 50ms. Click on the longest task to see the call tree. The functions shown there are your INP culprits.
Step 3: Use PageSpeed Insights diagnostics
Run your URL through PageSpeed Insights. In the Opportunities and Diagnostics sections, look for "Reduce JavaScript execution time" and "Minimize main-thread work". These show you which scripts are consuming the most CPU time during page load. The script filenames (often recognisable as plugin names) tell you which plugins to investigate first.
Step 4: Use the Web Vitals Chrome Extension
Install the Web Vitals Chrome Extension from the Chrome Web Store. With the extension open, interact with the page normally — click buttons, open menus, fill in form fields. The extension shows INP readings in real time as you interact. This is the fastest way to identify which specific interaction on a page produces the highest INP reading, so you know exactly what to target.
Common INP Culprits in WordPress Sites
Elementor and Divi page builder scripts
Elementor's frontend.min.js (approximately 450KB minified) initialises JavaScript widgets for every widget type in the Elementor library, regardless of which widgets are on the current page. A page with a simple text block and an image still loads scripts for video players, accordions, tabs, sliders, and carousels. This script execution is part of why Elementor sites consistently score 300–600ms INP on mobile devices.
Divi behaves similarly — its jQuery-based frontend framework initialises its full component library on every page. In independent testing of comparable Kerala business websites in 2025, Divi sites averaged 480ms INP on mobile versus 190ms for equivalent pages built with GeneratePress and block editor.
Contact form plugins with jQuery UI dependencies
Contact Form 7 loads jQuery and its own validation scripts on every page by default — not just pages containing a form. These scripts attach form validation event listeners that run on every click inside the document, adding latency to interactions that have nothing to do with forms. WPForms and Gravity Forms have similar (though somewhat smaller) footprints when not configured carefully.
Chatbot and live chat scripts
Intercom, Freshchat, Tidio, and similar chat widgets load 200–800KB of JavaScript synchronously or early in the page lifecycle. These scripts poll for chat availability, initialise WebSocket connections, and render the chat interface — all on the main thread, competing with user interactions. A Freshchat initialisation script running for 350ms on the main thread when a user clicks a navigation link will push that interaction's INP contribution to 400ms+.
Google Analytics and GTM with synchronous loading
Google Analytics 4 loaded directly in the <head> without async or defer attributes blocks rendering and delays interactivity. Google Tag Manager, when loaded with synchronous triggers, can fire multiple marketing scripts simultaneously during user interactions. For a WooCommerce site with add-to-cart tracking, checkout funnel events, and heatmap recording all firing on button clicks, the combined JS execution can add 200–400ms to the INP of those interactions.
WooCommerce product page JavaScript
WooCommerce loads its full JavaScript suite on every product page — variation selectors, quantity updaters, add-to-cart AJAX, gallery lightboxes, and mini-cart updaters. On product pages with many variations (colour + size + material = potentially hundreds of combinations), the variation selection JavaScript can itself take 150–250ms on mid-range Androids when a user clicks a swatch. This is a common INP failure point for Kerala e-commerce sites built on WooCommerce.
Fix 1: Defer Non-Critical JavaScript
The most impactful single fix for most WordPress sites is proper JavaScript deferral — loading scripts after the main thread is free for user interactions, rather than during the initial page load burst.
WP Rocket (approximately ₹5,000/year): WP Rocket's "Load JavaScript Deferred" option applies defer to all non-critical scripts and "Delay JavaScript Execution" holds scripts from running until user interaction (first click, scroll, or keypress). This combination typically reduces INP by 100–200ms on plugin-heavy WordPress sites. After enabling, test thoroughly — occasionally a plugin's deferred script causes a visible UI glitch that requires adding it to the exclusion list.
Perfmatters (approximately ₹3,500/year): Perfmatters' "Script Manager" allows disabling specific scripts on specific pages or post types. If Contact Form 7's scripts are loading on every page but your form is only on the Contact page, Perfmatters lets you restrict CF7 scripts to only that page URL. This is more surgical than WP Rocket's blanket deferral and often produces better results for targeted INP improvement.
Flying Scripts (free): A simpler free alternative that delays script execution until user interaction. Less configurable than WP Rocket or Perfmatters, but effective for straightforward cases. Set chat widget scripts, social embed scripts, and secondary analytics scripts to load on interaction rather than on page load.
Benchmark expectation: a WordPress site with 25 plugins averaging 450ms mobile INP before optimisation typically reaches 220–280ms mobile INP after implementing proper script deferral with WP Rocket or Perfmatters. That is a meaningful improvement — from Poor to Needs Improvement — achieved without changing any plugins or themes.
Fix 2: Replace Heavy Plugins with Lighter Alternatives
Script deferral treats the symptom. Replacing the heavy plugin treats the cause. For each identified INP culprit, here are lighter alternatives that achieve the same functionality with less JavaScript overhead.
Contact Form 7 (heavy) → Fluent Forms (lighter): Fluent Forms loads scripts only on pages containing a form shortcode and its base script is approximately 40% smaller than CF7's. The difference in INP contribution for a page with a contact form is typically 80–120ms.
Elementor (heavy) → GeneratePress + GenerateBlocks (lighter): GeneratePress theme with the GenerateBlocks plugin delivers nearly identical design flexibility to Elementor but loads page-specific block scripts only. A comparable page built in GenerateBlocks versus Elementor typically shows 200–350ms lower INP on mobile in field testing.
Google Analytics loaded in head (heavy) → Partytown integration (lighter): Partytown runs third-party scripts including Google Analytics in a Web Worker, completely off the main thread. The interaction between Partytown's worker thread and the main thread adds minimal latency — typically 5–15ms — compared to the 100–200ms that synchronous analytics loading adds to interactions on the main thread.
Full chat widget loaded on every page (heavy) → Lazy-loaded on interaction only: Instead of loading the full Tidio or Freshchat script at page load, load a lightweight placeholder chat button using CSS. Only when the user clicks the chat button do you load the full chat library. This eliminates the chat script's contribution to INP for the 95% of page interactions that have nothing to do with chat.
Fix 3: Move to a Block Theme
WordPress full-site editing (FSE) block themes — Twenty Twenty-Four, Kadence, GeneratePress, Astra in block mode — load significantly less JavaScript than classic themes with page builders. The Gutenberg block editor's output is mostly rendered HTML with minimal client-side JavaScript, unlike Elementor's runtime which continuously manages component state.
Migrating from Elementor to a block theme is a significant project — typically 10 to 20 hours of developer time for a 30-page business website. But the performance gains are substantial. WordPress sites that migrate from Elementor to a lean block theme typically see mobile INP drop from 400–600ms to 150–250ms. For businesses where organic search rankings are business-critical, the migration cost is recovered in improved CWV scores within two to three months.
A phased approach works for larger sites: migrate the highest-traffic pages first (homepage, main service pages, blog index), measure the INP improvement in Search Console after 28 days, then continue migrating remaining pages. This validates the performance improvement before committing to full migration.
Fix 4: Enable PHP Object Caching with Redis
This fix addresses a different INP contributor: slow PHP execution that delays the initial response, which in turn affects how quickly the page becomes interactive. WordPress's default database query pattern is inefficient — plugins often run dozens of MySQL queries per page load, including repeated queries for the same data. Redis object caching stores query results in memory so repeated queries return instantly rather than hitting the database each time.
On Cloudways, Redis is available as a one-click add-on (approximately ₹500–700/month additional). On DigitalOcean Managed Databases or DigitalOcean Droplets, Redis can be installed and configured in about 30 minutes. Once configured, activate the Redis Object Cache plugin in WordPress and enable persistent object caching in its settings. For WooCommerce sites and sites with complex plugin configurations, Redis typically reduces PHP execution time by 40–70%, which translates to 50–150ms lower TTFB — indirectly improving LCP and giving user interactions a less congested main thread to work with.
Fix 5: Audit and Remove Unused Plugins
Every active WordPress plugin adds JavaScript, PHP execution time, and database queries. Plugins that are installed but not actively used still load their assets on most pages. Run a plugin audit quarterly using this process: deactivate one plugin at a time, measure INP with the Web Vitals extension after each deactivation, and note which deactivations produce the largest INP improvement. Keep a spreadsheet of plugin name, JS file size, and INP contribution measured empirically.
Common findings in Kerala business WordPress sites: slider plugins (WOW Slider, Master Slider, Revolution Slider) that load 150–400KB of JS on every page but are only used on one page; social share plugins that load social platform scripts synchronously; SEO plugin bloat where a site has both Yoast and RankMath active (a surprisingly common finding); and abandoned plugins from old site builds that are still active but serve no current purpose.
Target: a well-maintained WordPress business site should have 15 or fewer active plugins. Most Kerala SME sites that contact me for CWV work are running 28 to 45 active plugins, of which 10 to 15 are either redundant or unused. Removing them is the lowest-risk, highest-impact first step before any performance plugin configuration.
Real Benchmark Numbers: What to Expect After Optimisation
Based on WordPress optimisation work done for Kerala and Indian business sites in 2024 and 2025, here are realistic before/after INP benchmarks for different starting configurations.
Elementor + 30 plugins + no performance plugin: Typical starting INP on mobile: 480–650ms (Poor). After WP Rocket + script deferral: 260–380ms (Needs Improvement). After also removing 10 unnecessary plugins: 200–280ms (Needs Improvement to borderline Good). After also migrating to a block theme: 140–200ms (Good).
GeneratePress + Gutenberg + 15 plugins: Typical starting INP on mobile: 220–320ms (Needs Improvement). After WP Rocket + Perfmatters: 160–220ms (Good to borderline). After Redis object caching: 130–190ms (Good).
Astra + Elementor + WooCommerce + 20 plugins: Typical starting INP on mobile: 520–750ms (Poor) — WooCommerce variation JS compounds the Elementor load. After script deferral and chat widget lazy loading: 320–450ms (Needs Improvement). After removing redundant plugins and disabling CF7 on non-contact pages: 260–350ms (Needs Improvement). Full block theme migration required to reach Good range.
Frequently Asked Questions
Why does WordPress score poorly on INP compared to static sites?
WordPress's plugin ecosystem and its historical dependency on jQuery are the primary culprits. A typical WordPress site with 20 to 30 plugins loads 15 to 30 separate JavaScript files, totalling 500KB to 2MB of script that the browser must parse and execute before the page is fully interactive. jQuery alone adds 90KB, and most plugins attach event listeners and initialisation code to jQuery's document ready event, creating a burst of JavaScript execution right when the page finishes loading.
Which WordPress page builders have the worst impact on INP?
Elementor and Divi consistently produce the highest INP scores in independent testing. Elementor loads approximately 450KB of frontend JavaScript on every page, regardless of which widgets are actually used on that page. Divi's architecture is similar. Lighter alternatives include Kadence Blocks, GeneratePress with GenerateBlocks, and Bricks Builder, which load only the scripts required for each specific page's elements.
What INP score should a WordPress site realistically target?
Good INP is under 200ms. For a well-optimised WordPress site using a lightweight theme, fewer than 15 plugins, a performance plugin with script deferral, and PHP object caching, achieving 150 to 180ms INP in field data for desktop users is realistic. Mobile INP on mid-range Android devices is harder: 200 to 280ms is achievable for most WordPress sites with the fixes in this guide. Sites using heavy page builders should target 250 to 350ms mobile INP as a realistic near-term goal.
Does WP Rocket alone fix INP, or do I need additional plugins?
WP Rocket's JS deferral, cache preloading, and lazy loading features address many INP contributors, but they do not fix everything. WP Rocket cannot remove INP-causing code inside plugins that add event listeners at DOM ready — it can only defer when those scripts load, not what they do when they load. For the deepest INP improvements, combine WP Rocket with Perfmatters for granular per-page script disabling, and replace or remove the specific plugins identified in your Chrome DevTools performance recording as the INP bottlenecks.