Delay JavaScript in WordPress: WP Rocket, Perfmatters and Exclusion Rules

What is Delay JS?

Delay JavaScript execution means a script is not run when the page first loads. Instead, it waits until the visitor does something – moves the mouse, scrolls, taps the screen, presses a key, or touches the page. Only then does the delayed script load and run. Until that first interaction, the browser has less JavaScript competing for the main thread, so the page can become interactive sooner and feel lighter on first load.

That is the whole appeal of delay javascript execution wordpress sites use: many scripts are useful, but not all of them are needed in the first second. Chat widgets, social embeds, marketing tags, video players and comment systems often sit below the fold or are only used by some visitors. If they all run immediately, they can slow down the first paint, block interaction and hurt Interaction to Next Paint (INP). Delaying them moves that work out of the critical path.

It is important to be precise about what delay does and does not do. It does not remove a script, make it smaller, or fix a slow server. It changes when the script runs. A delayed script that is heavy will still be heavy once it runs – it will just run later. That distinction matters for testing: a page can look fast on first load and still feel slow the moment a visitor interacts and a pile of delayed scripts wakes up at once.

If you are still working through the fundamentals, start with the WordPress Core Web Vitals guide and the INP guide for WordPress. Delay JS is best understood as one tool inside that larger picture, not as a magic switch for every performance problem.

Delay vs Defer vs Async, in Plain Terms

These three words are often used as if they mean the same thing. They do not, and choosing the wrong one is a common cause of broken pages.

• Normal (blocking) JavaScript: The browser stops parsing the page, downloads the script and runs it, then carries on. This is the slowest option for first load when the script is large or comes from a third party.
• Async: The browser downloads the script in parallel with parsing, but runs it as soon as it arrives, pausing parsing at that point. Order is not guaranteed, so async suits independent scripts that do not depend on other scripts running first.
• Defer: The browser downloads the script in parallel, but waits until the HTML has been parsed before running it, in document order. Defer is a safer general improvement than blocking, because the page structure is ready first.
• Delay (until user interaction): The script is held back entirely until a visitor interacts. This goes further than defer: with defer, the script still runs automatically after parsing; with delay, it does not run at all until interaction.

Think of it this way. Defer says, load this after the page structure is ready. Delay says, do not load this until someone shows they need the page. That is why delay can help INP and page load more dramatically than defer in some cases – and why it can also break more things. Anything that must be ready before the first click, scroll or keypress is a poor candidate for delay.

What Breaks When You Delay Scripts?

Delay javascript breaks site features in predictable ways, because the breakage follows the same rule every time: a feature whose script has not run yet cannot work yet. The symptoms look different depending on the feature, but the cause is the same – the visitor tried to use something before its script was allowed to run, or a script that other code depends on was not available when it was needed.

• Consent banners and privacy tools: If a consent banner is delayed, it may appear late, appear only after a click, or not appear in the way your privacy setup expects. Because consent can affect whether other tags should fire at all, treat consent-related scripts with particular care and test them first.
• Sliders and carousels: A hero slider may show only the first slide, show stacked images, or fail to auto-advance until the visitor interacts. That is often the first visible sign that delay is too broad.
• Forms: Contact forms, checkout forms, pop-up forms and multi-step forms can fail to validate, fail to submit, or show a broken layout if their script, or a script they depend on, is delayed. Test every form, not just the contact form on one page.
• Chat widgets: A chat button may be missing, unresponsive, or slow to open on first click, because the first click is spent waking the script rather than opening the chat.
• Payment scripts: Payment fields, wallets and checkout buttons must be ready when the visitor is ready to pay. Delaying payment-related scripts on cart and checkout pages is risky and should be avoided unless you have tested the full checkout flow.
• Analytics that must fire early: Some measurement needs to capture the visit itself, not only visits where someone clicks or scrolls. If analytics is delayed, early page views and some events may be missed. Decide deliberately what you are willing to trade for speed.
• Menus, tabs, accordions and pop-ups: Any interactive element powered by JavaScript can feel dead on first click if its script is delayed. Visitors often interpret a dead first click as a broken site, even if a second click works.

Two more failure modes are easy to miss. First, script order: if script B depends on script A, and only one of them is delayed, B may run before A exists. Second, above-the-fold behaviour: a script that controls the visible header, hero or menu is not a good delay candidate just because it is large. Size alone does not decide whether a script is safe to delay; timing and dependency do.

How to Test for Breakage on Staging Before Going Live

Never test delay JS for the first time on a live site. Use a staging copy, enable delay there, and work through the site as a visitor would – including as a visitor who does nothing for a few seconds, then clicks immediately. That immediate click case is where many delay problems appear.

1. Take a baseline on staging: note which features work, and check the browser console for errors, before you change anything.
2. Enable delay in one plugin only, with a conservative starting point. Do not enable delay in two plugins at the same time, or you will not know which one caused a problem.
3. Test the homepage, a blog post, a landing page, cart and checkout (if you sell anything), and every form. Click menus, open tabs and accordions, play sliders, open the chat widget, and submit a test form.
4. Test on mobile and desktop, and test with a fresh browser session, not only a warmed-up session where scripts may already be cached.
5. Check the browser console again, and use Query Monitor to see what is actually loading and what may be conflicting.
6. When something breaks, exclude one script at a time, clear the cache, and retest. Changing five exclusions at once hides the real cause.
7. Only after staging passes should you repeat the same steps, in the same order, on live – and retest checkout and forms there too.

Pay special attention to the cases that already stress interaction timing. If you use Elementor, read how to fix INP in Elementor alongside this guide, and if you run a store, work through WooCommerce INP and slow add to cart before delaying anything on product, cart or checkout pages.

WP Rocket Delay JavaScript Execution, in General Terms

WP Rocket delay js is its Delay JavaScript Execution feature: it holds back selected scripts until user interaction, while letting you list scripts that should be excluded and therefore load normally. In general terms, you enable the feature, review the scripts it is delaying, and add exclusions for anything that breaks or must run early. The exact menu labels, screen layout and built-in exclusions can change between releases, so check the plugin’s current documentation for the version you are running before you rely on any specific label or default list quoted elsewhere.

The practical workflow matters more than the label. Start conservatively, exclude the scripts that power consent, checkout, forms and above-the-fold interaction, and test on staging. If a feature breaks, find the script behind it in the page source or browser developer tools, exclude that script by a stable part of its file name or handle, clear the cache, and retest. A broad exclusion that restores everything may fix the symptom, but it can also undo most of the benefit; a narrow exclusion for the one script that actually broke is usually better.

Perfmatters Delay JS, in General Terms

Perfmatters delay js works from the same principle: scripts are held until interaction, with exclusions for scripts that must load normally and controls for where delay applies. As with WP Rocket, check Perfmatters’ current documentation for the exact settings, labels and defaults in your version, because those details change and an out-of-date screenshot can mislead you.

Perfmatters is also useful for the step before delay: seeing what is loading. Before you delay anything, look at which scripts load on each page type and ask whether a script needs to load there at all. A script that is disabled on pages where it is not used does not need a delay rule, and a script that is only needed on one page type does not need to be delayed everywhere. Delay is most effective when it is the last step, not the first – after you have already removed or limited scripts that should not be there.

Do not run WP Rocket delay and Perfmatters delay at the same time on the same scripts. Two delay systems competing over the same script can produce confusing results, double handling and errors that are hard to trace. Pick one plugin for delay, keep the other delay feature off, and keep a note of which plugin owns the job.

Exclusion Rules That Work

Good delay js exclusions are narrow, named for a reason, and tested one at a time. An exclusion is not a guess to copy from someone else’s list; it is a decision about one script on your site, based on what that script does and when it must run. The patterns below are examples of the kind of script to consider excluding – test each one on your own staging site, and do not treat them as a guaranteed list.

Exclude by script keyword or handle

Most delay tools let you exclude a script by a distinctive part of its file name, URL or handle. Use a keyword that is specific enough to match only that script. For example, you might exclude, as a pattern to test, a script whose name clearly identifies it as a consent tool, a payment library, a form handler, a slider library, or a chat widget. Avoid very short or generic keywords, which can accidentally exclude unrelated scripts and quietly undo your delay setup.

When you add an exclusion, write down why: the feature it protects, the page where you saw the breakage, and the date you tested it. That note is what stops a future clean-up from re-breaking checkout or a form. If you cannot name the feature an exclusion protects, it is a candidate for removal and retesting.

Exclude by page

Some pages should not be delayed at all, or should be delayed far less aggressively. Cart, checkout and account pages are the clearest examples: the visitor is already in a transaction, and a delayed payment or form script can cost a sale. The same logic applies to a landing page whose main conversion is a form, or a page whose hero interaction is the whole point. Page-level exclusions let you keep aggressive delay on blog posts and content pages, where the risk is lower, while protecting the pages where interaction must work immediately.

Test one change at a time

• Add one exclusion, clear the cache, and retest the broken feature.
• If it works, keep the exclusion and move to the next broken feature.
• If it does not work, the problem is a different script, a dependency, or script order – look at the console and page source before adding more exclusions.
• Re-check performance after each exclusion. If excluding one script removes most of the gain, ask whether that script should be optimised, replaced or loaded differently, rather than simply delayed.

A Safe Rollout Order

1. Staging first. Build or refresh staging, enable delay there, and run the full test list above.
2. One plugin at a time. Enable delay in WP Rocket or Perfmatters, not both. Confirm which plugin owns delay before you go live.
3. Conservative exclusions first. Exclude consent, payment, form and above-the-fold interaction scripts before you test, not after a visitor reports a problem.
4. Checkout and form tests. Complete a test purchase or form submission on staging, then repeat it on live after deployment.
5. Watch, then widen. Only once live checkout, forms, menus and sliders are confirmed working should you consider delaying additional scripts – again, one at a time.

That order is deliberately boring. Delay JS rewards patience: the sites that get the benefit without the breakage are usually the ones that changed one thing, tested it, and wrote down what they did.

It also helps to keep delay in perspective. There is a lot of noise about measurement changes and thresholds, and not every claim you read is current. If a headline promises a shortcut, check it against the Core Web Vitals 2026 changes myth-bust before you reshape your whole setup around it.

Used carefully, delay JavaScript execution is a powerful way to keep WordPress fast without sacrificing the features visitors rely on. Start on staging, exclude what must run early, test one change at a time, and let checkout and form tests – not a single speed score – decide whether your setup is ready to go live.

Common Questions

Frequently Asked Questions

Clear, honest answers about delaying JavaScript, WP Rocket, Perfmatters, and exclusion rules.