Every Plugin Adds a Script, and a Page Can Load Dozens
Every script file has to be downloaded before the browser can run it, and the browser stops to read the ones that are not marked async or deferred. One or two are nothing. A WordPress page with plugins, a page builder, and a couple of third-party widgets can quietly end up loading twenty or more.
When the script count passes ten, the report adds a finding called high number of JavaScript files. It lists the count and the total kilobytes, and it is the inventory problem behind slower pages rather than a verdict on its own.
The finding carries no points of its own. The score comes from the Core Web Vitals measured in the browser, and the metric this pile feeds is Total Blocking Time, which is where heavy JavaScript shows up.
Reading the script count
The check counts every script file the page loads and adds up their size. The bar sits at ten, so more than ten script files earns the finding, and the report shows the count and the total kilobytes right in the card.
Ten sounds low until you remember what counts as a script. A slider, a gallery, a form handler, an analytics tag, a chat widget, an icon script, each one is a file, and a theme plus half a dozen plugins can pass ten before the page is doing anything unusual.
Why a pile of scripts is not a slow page
The honest part is that a high count does not mean a slow page. Scripts marked async or defer download in the background and run without holding the browser hostage, so the kilobytes can pile up while the page stays responsive.
Deferred does not mean free. The browser still has to parse and compile every kilobyte before the script runs, and on a budget phone that work alone can cause small stutters mid-scroll, even when nothing blocks the page from painting.
The number the score actually cares about is Total Blocking Time, the time the main thread is too busy to answer. A page can load 21 scripts and block for only tens of milliseconds, while a page with three badly built scripts can freeze for a second. The pile is a warning sign, the blocking time is the damage.
TBT is the lab stand-in for a reason. Real responsiveness, the Core Web Vital called Interaction to Next Paint, only shows in data from actual visitors, and a heavy script pile is what drags it down when a script runs in the middle of someone’s tap.
Every script has an owner
Most scripts on a WordPress site belong to something you installed. The theme loads its own, often a bundle for menus and animations. Each plugin loads what it needs, a slider library here, a lightbox there. Chat and analytics widgets load their own too, and those two are usually the heaviest scripts on the page.
The report’s waterfall shows the whole list with sizes, so you can see who is heavy and who is just noise. You are looking for the files nothing on the page actually needs.
The list you can shorten
Start with the plugins nothing uses. Every active plugin can load its scripts on every page, so deactivating what is not used removes files immediately. Test the page after each deactivation.
A plugin you need on one page can usually have its script restricted to that page instead of the whole site. Asset-management plugins handle this per page, and a developer can restrict the script in the theme with a dequeue line.
Cut the third-party weight first. Chat widgets, analytics, and social embeds are the heaviest scripts on most pages, and their own settings usually decide where they load. Loading them only where they are needed, or only after the page is usable, is often the single biggest drop in script weight.
The strongest version delays them until the visitor first moves, scrolls, or taps. Some optimisation plugins expose this as a delay JavaScript setting, and a chat widget that loads only when someone is about to use it adds almost nothing to the page before that moment.
Let an optimisation plugin handle the mechanics. A caching or optimisation plugin can mark non-essential scripts as defer or async, which keeps them off the critical path without removing the features.
Defer is the safer setting when scripts depend on each other, because it keeps their order, which suits WordPress features that build on jQuery. Async runs each script the moment it arrives, so it fits standalone tags like analytics better. Change the settings one at a time and test, because a script another feature depends on can still break when deferred.
The detailed rules of defer and async belong to the TBT guide in this series, which is the metric this finding feeds. For a hand-built site the same work is bundling the scripts into fewer files, tree-shaking the unused code, and splitting what only some pages need, none of which is something you type into the WordPress dashboard.
Re-test, and watch TBT
Run the test again after each change. The report prints the script count and the total kilobytes on every run, and the score that matters, Total Blocking Time, sits in the same performance section, which the guide to reading an Enterramon test walks through part by part.
Our own homepage shows the split in practice. It loads 21 scripts totalling about 1.4MB, comfortably past the bar of ten, yet the main thread stays clear, 69 milliseconds of blocking on desktop and 17 on mobile. The flag fires, the metrics stay green, and both statements are true.
The scripts are not the problem, the scripts that do nothing are. Cut the pointless ones, keep the rest, and let the measured metrics decide.
