Starting a website?

Purpose-Built Templates

ZU2B Blueprints

Business in a Box

Reference

ZU2B Pulse™

See what visitors experience before they leave — paste any public URL and get a plain-English performance report in seconds.

Scan Your URL Free
FAQ • Support
,

Reducing JavaScript Payload: Stop Loading What the Page Doesn’t Need

Field Note #109
🔬 Generalized 🟡 Intermediate ⏱ 30 Minutes ✓ Observation from Experience
A page-speed tool flags “excessive JavaScript” and tells you to audit your scripts. That’s easy advice to give and genuinely tedious advice to follow — until you realize most sites don’t actually have too much necessary JavaScript. They have JavaScript loading on pages that never use it.

The pattern to look for
Plugins tend to enqueue their scripts broadly, “just in case,” rather than only on the specific pages that need them. A payment gateway library is the classic example: it’s genuinely necessary on a checkout page, and completely dead weight on your homepage, your about page, or a blog post — pages with no purchase form anywhere on them. But by default, many plugins load it everywhere, on every single request, because that’s the simplest thing for the plugin to guarantee it’ll work correctly.
The fix isn’t “remove the script” — you still need it where a purchase actually happens. It’s “make the script conditional” — load it only on the pages that genuinely use it.

How to find your own version of this
View-source your homepage (or any content-heavy, non-transactional page) and count the actual <script> tags.
For each one, ask: does this specific page use whatever this script does? A payment library, a full-featured chat widget, an embedded booking calendar — anything with a genuinely narrow use case is worth checking.
The ones that fail that test are your candidates.

Two ways to make a script conditional
Dequeue before it gets enqueued. Hook into your CMS’s script-registration process and remove the script on pages that don’t need it, based on whatever condition identifies those pages (a specific page type, a URL pattern, or checking whether the page’s content contains a certain shortcode or block).

Intercept it at output time instead, if the dequeue approach doesn’t stick. Some plugins register their scripts on a later hook than you’d expect, which means an early “remove it” attempt can silently get overridden. A filter that intercepts the actual <script> tag right before it’s printed — regardless of when or how it got registered — sidesteps that timing problem entirely, since it runs after everything else has already happened.

Confirming it actually worked
Don’t trust a page-speed tool’s cached number right after you make the change — tools like that often cache their own scan results for a while, giving you a stale count that looks unchanged even after a real fix. Check the actual page source directly (or your browser’s Network tab) for the specific script you removed. If it’s genuinely gone from a fresh, private-window load, the fix worked — even if an external tool takes a bit longer to reflect it.

A lower-effort win to try first
Before hunting for individual scripts to make conditional, check whether your site has an asset-optimization plugin (something that combines and minifies CSS/JS into bundled files) and whether its more aggressive settings are actually turned on. Enabling full JS aggregation — combining many small script files into far fewer bundled ones — can often cut your script-tag count dramatically in a single toggle, before you touch any individual plugin’s loading behavior at all. It won’t fix a genuinely unnecessary heavy library loading everywhere, but it clears the easy wins first so you can see what’s actually left to fix by hand.

Tagged in :

,

More from the field