WP Rocket’s own documentation warns that Delay JavaScript Execution — the single feature most WordPress sites enable first to fix a bad INP score — can make that same score worse if it delays a script a visitor needs for their very first click. Google scores Interaction to Next Paint as good at 200 milliseconds or under, needs improvement between 200 and 500 milliseconds, and poor above 500 milliseconds, measured from real visitors rather than a lab test. The rest of this checklist walks through the specific exclusions WP Rocket’s documentation says to make before you trust the feature, in the order that actually matters.
What INP measures, in three parts
Interaction to Next Paint tracks the single slowest interaction a real visitor has with your page — a click, a tap, or a key press — and splits the delay into three phases. Google’s own breakdown defines them this way: input delay is the time between the visitor’s action and the start of the event callbacks that respond to it, often stretched by an unrelated long task already running on the main thread; processing duration is how long those callbacks take to finish running; and presentation delay is the time between the callbacks finishing and the browser actually painting the next frame. The three add up to the total interaction latency, and the score Google reports is the 75th percentile across all of a page’s real visits, split by mobile and desktop.
| INP score | Threshold |
|---|---|
| Good | ≤ 200ms |
| Needs improvement | 200–500ms |
| Poor | > 500ms |
What Delay JavaScript Execution actually does
Delay JavaScript Execution postpones every script on the page — both external files and inline blocks — until the visitor does something: a mouse move, a tap, a key press, scrolling, focusing a field, or submitting a form. WP Rocket’s own documentation calls it “the most powerful JavaScript optimization WP Rocket has,” built to cut unused JavaScript, main-thread work, and total blocking time in PageSpeed audits. It only runs on cached or optimized pages, and it automatically disables the separate Combine JavaScript Files option so your scripts stay in their original order. One script is excluded automatically no matter what: wp-embed-min, which loads immediately.
That last sentence in the previous paragraph is also the whole problem. Delaying “every script until interaction” is a fine trade when the visitor’s first action is scrolling to read an article. It is not a fine trade when the visitor’s first action is clicking the hamburger menu or a cookie-consent button, and the script that makes that element respond was one of the ones just delayed. WP Rocket’s own INP documentation says plainly that Delay JavaScript Execution can hurt INP, and names the fix as excluding, by hand, any script tied to a critical above-the-fold interaction.
Six mistakes the documentation specifically warns about
- Leaving your navigation menu’s script delayed. If the dropdown or hamburger menu depends on JavaScript that Delay JS Execution is holding back, a visitor’s first tap waits for whatever interaction event finally releases the queue — usually that same tap, which means the menu script fires a beat late and the tap itself registers as the slow interaction WP Rocket was supposed to fix. The fix is the “Excluded JavaScript Files” field: add the exact file name or a matching keyword, not a guess at the plugin’s name.
- Treating Safe Mode as a permanent setting. Safe Mode excludes everything in
/wp-content/and/wp-includes/, jQuery, jQuery Migrate, and any inline script added throughwp_add_inline_script(), which is broad enough to stop most visible breakage. WP Rocket’s documentation is explicit that this is meant as a temporary fallback, and that the real fix is finding and excluding the specific file causing trouble rather than leaving Safe Mode on indefinitely. - Leaving another plugin’s own “combine JavaScript” option switched on. WP Rocket automatically turns off its own Combine JavaScript Files when you enable the delay, but it cannot see a combine option that lives inside a different plugin or your theme. The documentation warns that leaving one of those on “can cause display problems,” because combined files are chunked and delayed in a way the originating plugin never designed for.
- Excluding so many scripts that you undo the point of the feature. Every file you add to the exclusion list runs immediately again, which is sometimes necessary and sometimes just a reflex after the first thing breaks. WP Rocket’s own docs note that over-excluding keeps the “Reduce unused JavaScript” PageSpeed audit failing — you keep the safety of the old behavior and lose the score improvement you turned the feature on for in the first place.
- Judging the fix from a single PageSpeed run instead of real-visit data. INP is a field metric: Google’s number comes from the last 28 days of real visitors, not from the one test you just ran after flipping a setting. A page can look instantly better in a single Lighthouse pass and still carry a poor 75th-percentile INP a week later, the same way a schema markup can pass the Rich Results Test and still lose the actual rich snippet — passing the quick check and winning the real outcome are two different questions.
- Forgetting IE11 visitors end up on an uncached page. WP Rocket redirects Internet Explorer 11 to an uncached version of the page with
?nowprocket=1appended, specifically because IE11 can’t run the delay script reliably. If you see that parameter showing up in analytics, it’s not a tracking bug — it’s this fallback working as documented.
Finding out which phase is slow before you exclude anything
PageSpeed Insights ships an “INP breakdown” insight in its Core Web Vitals section, and it exists specifically to stop the guessing described above. WP Rocket’s own documentation on the INP breakdown insight describes it as informative only — it doesn’t change your performance score — but it tells you which of the three phases (input delay, processing duration, or presentation delay) the longest recorded interaction actually spent its time in, and which element triggered it. That is the difference between excluding a script because the menu feels slow and excluding the one file that profiling actually points to.
In practice this means checking the breakdown before touching the exclusion list a second time. If input delay dominates, the problem is usually an unrelated long task already running when the visitor clicks — often a third-party script you didn’t even think to exclude. If processing duration dominates, the event handler itself is doing too much work, which Delay JavaScript Execution cannot fix by moving the script later; it only changes when the handler starts, not how long it takes once it runs. If presentation delay dominates, the browser is stuck painting a large or complex frame, which is where Automatic Lazy Rendering and Remove Unused CSS tend to help more than the delay feature does.
The other four features WP Rocket recommends alongside it
WP Rocket’s INP documentation doesn’t present Delay JavaScript Execution as a standalone fix. It names four more settings, each targeting a different part of the three-phase breakdown above, and each with its own caveat worth reading before you turn it on.
| Feature | What it targets | Documented caveat |
|---|---|---|
| Delay JavaScript Execution | Processing duration, main-thread work | Can hurt INP if a critical script gets delayed |
| Remove Unused CSS | Render speed, input delay | Can remove CSS a script adds dynamically after page load |
| Load JavaScript Deferred | Render speed | Changes execution order; can break scripts expecting an earlier dependency |
| LazyLoad (images, iframes, video) | Overall render speed | Not targeted at INP directly — helps the page feel ready sooner |
| Automatic Lazy Rendering | Presentation delay | Delays rendering of below-the-fold elements until they’re near the viewport |
The documentation adds one more honest limitation worth repeating: because INP is a field metric built from real visits over time, WP Rocket says its own impact on your score “can’t be measured properly” right after you flip a setting. Give it real traffic and a few days before deciding whether an exclusion worked.
FAQ
Why does PageSpeed Insights sometimes show no INP value at all?
Field data needs enough real interactions to report a stable number. A low-traffic page, or one visitors rarely click on, may not have 28 days of qualifying data yet, in which case Google’s tools fall back to Total Blocking Time as a lab-based stand-in until enough field data exists.
Should I enable every one of the five features at once?
WP Rocket’s documentation presents them as a set, but each one has its own breakage risk, so the safer sequence is one at a time: turn one on, exclude what visibly breaks, let real traffic accumulate for a few days, then move to the next rather than changing five settings and trying to guess which one caused a regression.
If your stack already runs Rank Math alongside WP Rocket, it’s worth confirming the sitemap it generates actually reflects your current posts before you spend more time chasing a performance number — our walkthrough on diagnosing a stale Rank Math sitemap covers the REST API publishing bug that causes that, and the companion piece on what Rank Math fills in for Article schema covers the other half of the technical-SEO checklist most WordPress sites skip.
