Most WordPress sites pass their loading scores and then quietly fail INP, because INP does not measure how fast your page appears; it measures how fast your page responds when someone actually clicks, taps, or types. That is a different problem, and it lives almost entirely in your JavaScript.
This guide is the diagnostic version, not another list of plugins to install. I will show you what INP is really made of, how to find the exact interaction that is slow, which WordPress habits cause it, and the JavaScript diet that actually moves the number.
Principaux enseignements
- INP replaced First Input Delay as a Core Web Vital in March 2024, and it is the metric most WordPress sites now fail because it measures real interaction responsiveness, not first-load speed.
- A good INP is 200ms or less; 200 to 500ms needs work; above 500ms is poor, judged at the 75th percentile of real visits.
- INP has three parts: input delay, processing time, and presentation delay; knowing which one is slow tells you exactly what to fix.
- On WordPress the usual culprits are page builders, live-chat widgets, heavy third-party tags, and plugins that load JavaScript on every page.
- The fix is a JavaScript diet: delay and defer scripts, load heavy widgets behind a facade, and cut the plugins running JS you do not need, not one magic plugin.
Why INP is the Core Web Vital most WordPress sites fail
Google swapped First Input Delay for Interaction to Next Paint in March 2024, and that swap is why a lot of sites that used to pass now do not. FID only timed the delay before the browser started handling your very first interaction, so a site could score well while still feeling sluggish on every click after that.
INP is stricter because it watches every interaction across the whole visit and reports close to the worst one. A good score is 200ms or less, 200 to 500ms needs improvement, and anything above 500ms is poor, measured at the 75th percentile of your real visitors.
WordPress fails this more than most stacks for one reason: it ships a lot of JavaScript. Between a page builder, a few plugins that each enqueue their own scripts, and a couple of third-party tags, the main thread ends up busy, and a busy main thread is exactly what makes an interaction wait. Passing your Largest Contentful Paint says nothing about this, which is why I treat INP as its own job in my Core Web Vitals guide.
What INP actually measures: input delay, processing, and presentation
Here is the part most guides skip, and it is the part that makes fixing INP straightforward instead of guesswork. Every interaction is really three stretches of time added together, and your slow number is almost always sitting in just one of them.
Input delay is the wait before your code even starts, usually because the main thread is busy running something else. Processing time is your event handlers actually doing their work. Presentation delay is the browser rendering and painting the result on screen. Diagnose which stretch is long, and you know whether the problem is too much background JavaScript, a heavy handler, or a bloated layout.
| The three parts of INP | De quoi s'agit-il ? | Common WordPress cause | La solution |
|---|---|---|---|
| Input delay | The wait before your handler starts, while the main thread is busy | Scripts from plugins, tag managers, and builders all executing at once | Delay and defer non-critical JS so the thread is free when the user acts |
| Processing time | Your event handlers doing their work | A heavy widget or a handler that does too much on click | Break the work up, or load the widget behind a facade until it is needed |
| Presentation delay | The browser rendering and painting the next frame | An oversized DOM from a page builder with deeply nested elements | Simplify the layout and cut the element count on heavy templates |
How to find your slowest interaction with real field data
You cannot fix an interaction you have not identified, so start with field data, not a lab guess. The Chrome User Experience Report holds the INP your real visitors experienced, and PageSpeed Insights surfaces it at the top of any URL you test. That number is the one Google grades you on, so it is where I always begin.
The catch is that field data only exists once a page has enough traffic, so a new or low-traffic site often shows no INP report yet. For those, and for reproducing a specific slow click, use the Performance panel in Chrome DevTools with the interaction recorded; it breaks a single interaction into the three parts above so you can see which one is long. I covered this field-versus-lab split in detail in my breakdown of CrUX Vis versus PageSpeed Insights, because reading the right one is half the battle.
The WordPress plugins and widgets that wreck INP
In practice, the same handful of offenders show up on almost every WordPress audit. Heavy page builders are the first, because a builder like Divi adds large scripts and deeply nested markup that make both processing and presentation slower. A live-chat widget is often the single worst item; one chat script can add hundreds of milliseconds of processing on its own.
After those come the quieter ones: analytics and tag-manager setups that load several third-party scripts, slider and popup plugins, and the general pile-up of plugins that each enqueue JavaScript site-wide even on pages that never use it. None of these is fatal alone, but together they keep the main thread busy, and a busy thread is what turns a click into a wait. A lighter theme helps here too, which is part of why I keep pushing on whether your theme is hurting your SEO.
The JavaScript diet: fixing INP on WordPress step by step
The goal of the fix is simple to state: keep the main thread free so that when a user interacts, the browser can respond right away. You get there by loading less JavaScript, loading it later, and only running the heavy pieces when they are actually needed.
Fixing WordPress INP, in the order that clears the most first
- Audit what loads JavaScript on each template and remove plugins you do not need
- Delay and defer non-critical scripts so the main thread is free on load
- Put heavy widgets (chat, video, maps) behind a facade that loads on click
- Conditionally load plugin scripts only on the pages that use them
- Re-measure INP in the field and confirm the worst interaction improved
Start by auditing what each template actually loads, because the cheapest millisecond is the one you never ship. Deactivate plugins you no longer use, and for the ones you keep, check whether they enqueue scripts on every page or only where needed.
Then delay and defer the non-critical scripts. Most caching plugins, including LiteSpeed Cache, have a “delay JavaScript” option that holds scripts until the first user interaction, which frees the thread during the crucial early moments. Be a little careful here, because delaying a script your above-the-fold content depends on can break it, so test after you enable it.
Le facade pattern is the highest-value single fix for most sites. Instead of loading a live-chat or video widget on page load, you show a lightweight fake: a static button or a thumbnail that looks like the real thing, and the heavy script only loads once the user clicks it. A chat widget that was adding 300ms of processing to every interaction stops touching your INP entirely until someone actually opens the chat.
Finally, load plugin scripts conditionally so a contact-form or slider script only appears on the pages that use it, not site-wide. This is more work than flipping a switch, but it is often what separates a site that keeps failing from one that finally passes, because it attacks the input-delay pile-up at its source.
How to confirm your INP actually improved
Do not judge the result by a lab score alone. Lab tools simulate one run, but INP is a field metric built from your real visitors, so the number that matters updates slowly in CrUX as fresh data comes in. Expect to wait a few weeks after a change before the field INP fully reflects it.
In the meantime, verify in the lab that the specific interaction you fixed is faster: record it again in the Performance panel and confirm the part you targeted, input delay, processing, or presentation, actually shrank. When the lab shows the fix working and the field number drifts down over the following weeks, you know it stuck.
So, how hard is INP to fix on WordPress really?
Honestly, it is more approachable than its reputation, as long as you stop treating it like a loading-speed problem. Almost every INP failure I diagnose traces back to JavaScript that did not need to run when it did, and the facade pattern plus a proper delay-JS pass clears the bulk of it on most sites.
So do not go plugin-shopping for a fix; diagnose which of the three parts is slow, then cut, delay, and defer your way back to a free main thread. Yes, the conditional-loading step takes real effort, but that is usually the one that turns a stubborn “needs improvement” into a pass, and it is worth doing properly.
Still Stuck on a Failing INP Score?
N'hésitez pas à nous contacter ou m'envoyer un courriel and I will help you trace the interaction that is dragging it down. Remember, INP is a JavaScript problem before it is anything else, so the fix is almost always closer than it looks.
Want our posts to show up more often on Google?
One step & Google will surface this site in your Top Stories.
