What “unused JavaScript” actually means
If PageSpeed Insights keeps telling you to “Reduce unused JavaScript,” you are not alone. It is one of the most common warnings on WordPress sites, and also one of the most misunderstood. Most site owners read it as an instruction to delete files. In practice, it is a prompt to stop loading code that a visitor’s browser downloads, parses, and executes without ever needing it on that page.
Unused JavaScript rarely comes from a single culprit. It comes from plugins that load their scripts on every page whether they are used or not, themes that bundle large libraries for features you never enabled, page builders that ship a full toolkit for a single widget, and third-party embeds that bring their own frameworks along for the ride. The fix is rarely dramatic. It is methodical: find the waste, identify who owns it, remove or defer only what is safe, and test after every change.
When a browser loads a page, it does not just download JavaScript files. It parses them and runs the code needed to render the page and make it interactive. If a file is 200 KB but only 20 KB of it runs on the homepage, the other 180 KB still costs time: download time on slow connections, parsing time on slower phones, and memory while the page stays open.
PageSpeed Insights estimates this waste by running the page in a simulated environment and comparing the code that executed against the code that was downloaded. That is why the number is an estimate, not a precise measurement of your real visitors. Two things follow from that. First, do not chase the number to zero. Some “unused” code is conditional — it runs only when a visitor opens a menu, submits a form, or scrolls to a slider. Removing it can break features that the test never triggered. Second, treat the report as a shortlist, not a verdict. Your job is to investigate each entry before you touch it.
Step 1: Find the worst offenders
Start with PageSpeed Insights, but read the “Reduce unused JavaScript” section properly. Expand it and note three things for each entry: the script URL, the estimated savings, and whether the script belongs to your theme, a plugin, or a third party. Sort by potential savings, not by the order on screen. A 5 KB saving is not worth an hour of work; a 150 KB saving from a single plugin might be.
Next, confirm the finding in Chrome DevTools, which shows you what actually runs:
- Open your page in Chrome and press F12 to open DevTools.
- Press Ctrl+Shift+P (or Cmd+Shift+P on Mac) and type “Coverage.”
- Click “Start instrumenting coverage and reload the page.”
- Click a script in the list to see the code. Red lines did not run; green lines did.
Coverage is more useful than PageSpeed here because it shows you which parts of a file are used, and because you can click around your page — open the mobile menu, submit a test form, play the slider — and watch more lines turn green. That tells you what is truly dead versus what is merely conditional. If a script shows almost no green lines even after you interact with the page, it is a strong candidate for removal. If large sections turn green only after interaction, the code is needed, but it may still be a candidate for delaying until interaction.
Repeat this check on three page types: the homepage, a typical post page, and a page with a form. A contact-form script that is unused on the homepage is normal. The problem is when it loads on every page anyway.
Step 2: Trace each script to its owner
Before you remove anything, you need to know which plugin or theme enqueues it. Guessing is how sites break.
The fastest way is to look at the script URL. Plugin scripts usually contain /wp-content/plugins/plugin-name/ in the path, and theme scripts contain /wp-content/themes/theme-name/. Third-party scripts point to an outside domain — Google, Facebook, a chat provider, an ad network — and need a different approach, because you cannot edit someone else’s file.
If the URL is not obvious, use Query Monitor, a free plugin that lists every script loaded on a page and which component requested it. Deactivate suspect plugins one at a time on a staging site, or during a quiet period, and re-run your coverage check. When the script disappears, you have found the owner. Keep a short note of what you found: script, owner, pages where it is needed, and estimated savings. That note becomes your removal plan and your rollback guide if something breaks later.
Step 3: Remove or unload scripts per page
This is where most of the savings live. A surprising number of plugins load their scripts everywhere by default. A slider plugin loads on pages without a slider. A form plugin loads on pages without a form. A social-sharing plugin loads on the checkout page. Each of those is waste you can remove without losing any feature, simply by loading the script only where it belongs.
The cleanest way to do this is a script manager plugin. Perfmatters and Asset CleanUp both let you disable a script or stylesheet on specific pages, post types, or site-wide, from a simple manager screen. See our Perfmatters vs Asset CleanUp comparison for how the two differ. The workflow is the same in both:
- Open the script manager on a page where the script is not needed.
- Find the script in the list and disable it for that page or post type.
- Save, clear your cache, and test the page in a private browser window.
- Repeat for the other page types, and check the pages where the script must stay.
Start with the obvious wins: form scripts on pages without forms, slider scripts on pages without sliders, gallery scripts on pages without galleries, and review or booking widgets on pages that never show them. Test each change. If a page looks right and its interactive elements still work, the removal is safe.
If you are comfortable with a little code, you can do the same thing without another plugin by dequeuing scripts conditionally in your child theme’s functions.php file. For example, to stop a contact form script loading everywhere except the contact page, you would dequeue it on every page except that one. The principle matters more than the exact code: only load a script on pages that use it. If you are not comfortable editing theme files, use a script manager plugin instead — the result is the same, and it is far easier to undo.
For scripts that are needed but not immediately — chat widgets, comment systems, social embeds, analytics add-ons — delaying is often better than removing. Many caching plugins, including WP Rocket and FlyingPress, can delay JavaScript execution until a visitor interacts with the page. The script still loads, but it no longer blocks the first paint or the first interaction. That is a good fit for code that is conditional: the chat widget nobody opens on the first screen, or the video player below the fold. Be careful with anything tied to the first interaction itself, though. Delaying the script that powers your mobile menu or your add-to-cart button can make the site feel broken for the first second, which is worse than a slightly slower score.
Step 4: Deal with your theme and page builder
Themes and page builders are the hardest source of unused JavaScript because their code is bundled, not neatly separated per feature. You usually cannot delete half of a builder’s JavaScript file without breaking the other half.
What you can do is switch off the features you do not use. Most page builders have settings to disable unused widgets, turn off default animations, or stop loading icon libraries you never use. Elementor, for example, lets you disable default fonts and icons, improve asset loading, and turn off features like the lightbox on pages that do not need it. Theme settings often hide similar toggles: a slider library, a mega-menu script, or a social-sharing script that loads even when the feature is off in the customizer. Go through your theme and builder settings once, slowly, and turn off anything your site does not actually display.
If your theme loads a large library — jQuery UI, a carousel, a masonry layout — for a single feature, ask whether that feature is worth its weight. Sometimes the honest answer is to replace a heavy slider with a native image block, or a fancy animation with plain CSS. CSS animations cost far less than JavaScript libraries, and they do not block interaction. This is the kind of trade that quietly fixes several PageSpeed warnings at once, not just unused JavaScript.
Step 5: Handle third-party scripts differently
Third-party scripts deserve a separate decision because you cannot trim them. You can only decide whether to load them, when to load them, or whether to replace them.
Audit every third-party script the way you audited plugins: what does it do, where does it run, and what happens if it loads later? A live-chat widget that loads on every page but is used by a handful of visitors is a prime candidate for loading on click or after a delay. A social feed embedded in the footer can usually be replaced with a static image linking to the profile, which costs nothing in JavaScript. An analytics script is small and usually worth keeping, but a stack of marketing pixels, heatmaps, and A/B testing tools adds up fast, and each one brings its own dependencies.
Where a third party offers a lightweight “facade” embed — a static placeholder that loads the real widget only when clicked — use it. The same pattern applies to maps, social posts, and chat widgets.
What never to remove blindly
Some removals look tempting and break real things. Do not remove jQuery from a WordPress site unless you have checked that your theme and every active plugin works without it — many still depend on it, and removing it is a common cause of broken menus, forms, and sliders. Do not remove a script just because it shows as unused on one page type; check the page types where it is used first. Do not combine, minify, or defer a script you have not tested afterwards. And do not trust a plugin’s “remove unused JavaScript” toggle without checking what it actually removed: some tools guess aggressively and break checkout pages, forms, and payment fields that the test never exercised.
The safe rule is simple: one change, one test, one cache clear. Change a single script’s loading, clear the cache, test the affected pages in a private window — including a form submission or a cart action if the page has one — and only then move to the next script. If something breaks, you know exactly which change caused it, and reversing one toggle is trivial.
Verify the improvement
After your changes, re-run PageSpeed Insights on the same pages you tested at the start, and re-check coverage in DevTools. Expect the “Reduce unused JavaScript” savings to fall, and expect related metrics to improve too: less JavaScript usually means a faster first interaction and less work for the main thread. If you want a deeper picture, read our guide to reducing JavaScript execution time overall, the companion guide to eliminating render-blocking resources, and our guide to reducing Total Blocking Time.
Keep your notes. The next plugin you install will bring its own scripts, and the next theme update may re-enable a feature you switched off. A quick coverage check every few months keeps unused JavaScript from creeping back. The goal is not a perfect score. It is a site that loads only the code each page actually needs.