A reCAPTCHA file from Google, WooCommerce scripts on your blog, the page builder’s front-end bundle, a slider library, a tag manager, an analytics file: the unused JS warning in PageSpeed Insights tends to read like an inventory of everything installed on your site. The report says each one contains code that never ran while the page loaded, and that you could save time if you reduce unused JavaScript.
The useful question is not “how do I make the number go away” but “which of these files should be on this page at all?” Answer that file by file and the warning shrinks as a side effect, without forms, carts or tracking quietly breaking along the way.
What “unused” means for a script
The report records which parts of each JavaScript file ran during the page load. The rest is marked unused. That covers three quite different situations:
- Code that will run later. A lightbox script does nothing until someone clicks an image. Its code is “unused” at load time but needed on that page.
- Code for other pages. A shop’s cart and checkout scripts loading on your About page. Never needed there.
- Code for features nobody uses. A large library loaded for a single small effect, or a plugin you stopped using months ago that still adds its files.
The first kind you might delay, but you should not remove. The second and third are where the real savings are, and they are what this post is about. If the question is when a needed script should run, rather than whether it should load, that belongs to choosing between defer and async.
Scripts that commonly load on every WordPress page
Plugins tend to add their files site-wide because it is the simplest way to make sure the feature works wherever you place it. The usual suspects:
- Contact forms and spam protection. Some form plugins and their reCAPTCHA add-ons load Google’s script on every page, not only where a form appears. That one is often among the largest files on the list.
- WooCommerce. Store scripts on pages that have nothing to do with the shop.
- Sliders, galleries and lightboxes. Used on one or two pages, loaded everywhere.
- Page builder front-end files. Animation libraries and widget scripts, sometimes for widgets the page does not contain.
- jQuery and jQuery Migrate. Many themes and plugins still need jQuery; Migrate exists for older code and is not always required.
- Small WordPress extras such as the emoji detection script and the embed script. These are small, but they add up on a lean site.
- Marketing tags added over the years for campaigns that ended.
Make a simple inventory before switching anything off
Ten minutes of note-taking prevents most of the breakage. Open a page in a private window, open DevTools, and on the Network tab filter by JS. Reload. For each file, write down three things:
| File | Comes from | Needed on |
|---|---|---|
| recaptcha api file | Form plugin | Contact page only |
| slider script | Slider plugin | Home page |
| woocommerce scripts | WooCommerce | Shop, product, cart, checkout |
| gtag file | Analytics | Every page |
The rows above are only an illustration; your list will differ. You can usually fill in the “comes from” column by reading the file address, since each plugin keeps its files in a folder named after itself. Third-party domains such as Google, Meta or a chat vendor show in the domain column. Those external tags need their own audit, which is covered in third-party scripts and how to tame them.
If you cannot tell which plugin is behind a heavy file, the method in finding the plugin that is slowing your site helps narrow it down.
How to reduce unused JavaScript page by page
With the inventory in front of you, work from the least risky change to the most.
1. Use the plugin’s own settings
Check each plugin’s settings for an option to load its assets only where needed. Some form, slider and gallery plugins have one. A theme’s performance panel may let you switch off features like smooth scroll, animations or bundled libraries you do not use. These are the safest changes, because the plugin’s own authors made them.
2. Unload files with a script manager
Perfmatters, Asset CleanUp and similar plugins let you disable individual scripts on chosen pages, post types or everywhere except selected URLs. Typical rules:
- Form plugin and reCAPTCHA: only on pages that contain a form.
- WooCommerce scripts: off on blog posts and plain pages, on for the shop and account areas.
- Slider: home page only.
- Emoji script: off site-wide, unless you rely on WordPress converting emoji for very old browsers.
Be careful with forms that appear in footers, sidebars or popups. They are on every page, so their scripts are too.
3. Remove or replace
Some files are unused because the feature is not used. If a plugin adds a heavy script for something trivial, such as animated counters or a sharing bar, ask whether the feature earns its weight. A simpler plugin, a theme option or plain HTML might do the same job. Removing a plugin you no longer need beats any optimisation setting.
4. Leave the rest alone
Some unused code will remain, and that is fine. jQuery, your theme’s main script and analytics will always show a share of unused bytes. The aim is to stop paying for code on pages where it has no job, not to reach zero.
Where per-page rules get tricky
Rules that look simple on a brochure site get harder as the site grows. A few situations to plan for:
- Archives and search results. A category page or a search page can show content from several post types, each of which may need a different script. Rules written for single pages may not cover them.
- Templates applied by the builder. If your header or footer template contains a form or a slider, that script is needed everywhere the template appears, even though no individual page “uses” it.
- Popups with display conditions. A newsletter popup set to appear on blog posts after a delay needs its form scripts on those posts, even though the popup is not visible when you test.
- New pages added later. Rules based on “only load on these URLs” do not know about the landing page your marketing person creates next month. Prefer rules by post type or template where the tool allows it, and add a line to your site notes so whoever builds the next page knows to check.
Testing after each change
JavaScript breakage is often silent: the page looks fine but something no longer works. After each rule, clear caches and check in a private window:
- The browser console (F12, Console tab). New red errors, especially “is not defined”, mean a script another file depends on has been removed.
- Every form you have, including the one in the footer. Submit a real test message and confirm it arrives.
- Menus, tabs, accordions and popups on desktop and phone.
- On a shop, add to cart, update the cart, and go through checkout.
- In your analytics real-time view, confirm your own visit and any conversion events still register.
Keep a note of every rule you add. Six months later, when someone adds a form to a new page and it does not work, that note saves an hour.
Why this helps more than the first load
Every script the browser downloads also has to be parsed and compiled, and most of them run some code at start-up. On a mid-range phone that work keeps the main thread busy, which is the same thread that responds to taps. Fewer scripts on a page usually means it responds sooner, which is one of the reasons heavy JavaScript turns up in fixing a poor INP score.
For the bigger picture of how scripts compare with images, server time and caching as causes of a slow page, our guide to website performance sets the priorities. And if you want to see how scripts fit with the other files that block the first render, the group overview walks through the safe order of fixes.
Frequently asked questions
Can I remove jQuery to fix the unused JavaScript warning?
Only if nothing on your site needs it, which is rare on WordPress. Many themes, sliders, forms and WooCommerce features still depend on jQuery. Removing it usually breaks something. Look for jQuery Migrate instead, which some sites no longer need, and test with the browser console open.
Why does the reCAPTCHA script load on pages with no form?
Some form plugins and spam protection add-ons load it everywhere to keep setup simple, and Google suggests its score-based version works better with more context. If your forms are only on a few pages, check the plugin settings or a script manager for an option to load it only there.
Will disabling scripts per page affect my analytics or ad tracking?
It can if you unload the wrong file. Tracking tags usually need to run on every page, so leave analytics, tag manager and ad pixels out of any per-page rules. After changes, check the real-time report in your analytics and test any conversion events you rely on.
Do script manager plugins slow the site down themselves?
They add a small amount of work when a page is built, but on a cached site that happens once per cache refresh, not for every visitor. The saving from not sending several unneeded files is usually larger. Keep the rules tidy and remove ones for pages that no longer exist.
Building per-page script rules is quick. Testing them across every template is the slow part. The third-party script audit and clean-up in our WordPress speed work covers both, and each rule goes live only after you have approved it.
Next in this series: Minify CSS and JavaScript: What It Saves and What It Risks
