Too many external scripts (25+)
too_many_scriptsShort answer
This page references more than 25 external <script src> files. Every one of them is a separate request, and scripts without defer or async block the parser until they are downloaded and executed. This issue affects how fast the page opens and the user experience; it is not a ranking factor by itself. Combine what you can, load what can wait with defer/async, and remove scripts nothing uses.
Why it matters
Script count is a proxy for JavaScript weight. Each external script costs DNS, connection and download time on first visit, and synchronous scripts in <head> delay the first paint. Many scripts also mean more long tasks on the main thread, which is what pushes INP over its threshold.
How Glimana detects it
During the crawl Glimana counts <script> elements with a src attribute. The rule fires when the count is above 25; the evidence shows the number.
How to fix it
- Find the affected pages in Glimana. Open Issues › Too many external scripts (25+). Every affected page is a row; open one to see the evidence Glimana recorded for it (the measured value, the offending element or the target URL). The same list sits on the task card under Tasks, and the page's own detail view under Pages shows its full signals.
-
Apply the fix on your platform.
- List them. Open DevTools › Network, filter JS, and sort by size. Note which domain each script comes from.
- Remove the unused. Tag managers, old A/B tools, chat widgets nobody checks, duplicate analytics. A surprising share of scripts on a typical page do nothing.
- Defer the rest. Everything that is not needed before first paint gets
defer; third-party widgets getasyncor are loaded on interaction. - Bundle your own. Your own scripts can be combined into one or two bundles served from your domain with long cache headers.
Each plugin tends to enqueue its own script on every page. Use Asset CleanUp or Perfmatters to unload scripts per page type, and turn on "delay JavaScript" / "defer" in your cache plugin. Keep only one analytics tag.
Every installed app can inject a script via its app embed. Review Online Store › Themes › Customize › App embeds and turn off what you do not use; uninstalling the app removes its script. Keep the theme's own JS in one bundle.
Bundle with your build tool, split by route, mark non-critical scripts
defer, and load third-party tags through a single tag manager with triggers rather than hard-coding each one. -
Publish and clear caches. Save and publish, then make sure the crawler will see the new version: WordPress — clear the page cache in your cache plugin and purge the CDN; Shopify — theme and content changes go live on save, but purge any CDN in front of the store; custom code — deploy and purge the edge cache. Check in a private window or with
curl -s https://your-domain/page | grep -i '<title\|canonical\|robots'that the live HTML has changed; Glimana reads what the server sends, not what your browser has cached. - Verify in Glimana. Open the task under Tasks and click Mark as done. The affected pages are queued for a verification crawl within a few hours, and the task closes when the page has 25 or fewer external scripts. If the check still fails, the task returns to New with a note; when it passes, the task is listed under Resolved technical issues on Impact reports. To check sooner, use Re-crawl affected pages on the issue.
How the fix is verified
Re-crawl; the task closes when the page has 25 or fewer external scripts.