Stop Extensions Loading Assets Your Template Does Not Use

Where the request comes from

Any extension can declare that it needs a core asset. Historically that was a one-liner in a module layout or a component helper:

HTMLHelper::_('bootstrap.tooltip');
HTMLHelper::_('bootstrap.framework');

Modern extensions do it through the web asset manager instead:

$wa->useScript('bootstrap.tooltip');

Either way the effect is the same. One breadcrumbs module or one shop component quietly adds a framework to every page on the site.

Find them by grepping the extensions you actually have installed:

grep -rn "bootstrap\." modules/ components/ plugins/ --include="*.php"

Disable the asset, do not patch the extension

Commenting out the line in components/com_something/... works until the next update replaces the file — and it will, silently, on a site you may not be maintaining a year from now.

Ask the asset manager to drop it instead, from your template's index.php:

$wa = $this->getWebAssetManager();

foreach (['bootstrap.tooltip', 'bootstrap.dropdown', 'bootstrap.collapse'] as $asset) {
    if ($wa->assetExists('script', $asset)) {
        $wa->disableScript($asset);
    }
}

Guard each call with assetExists(). Asking to disable something that was never registered throws, and an exception in index.php takes the whole front end down.

Disabling an asset also disables anything depending on it, which is usually what you want and occasionally not — check the pages that extension renders, not just the front page.

If jQuery is loading, it is not Joomla

Joomla's own JavaScript is written against browser APIs and custom elements — jQuery is not part of the CMS. So when you find it in the page, an extension is bundling it, and the question becomes whether that extension still has a maintained release rather than how to switch it off.

Where the layout override still applies

When an old module calls HTMLHelper directly from its layout, you can copy that layout into templates/yourtemplate/html/mod_something/ and remove the call there. Overrides survive updates, so this is safe — unlike editing the module in place.

Component helpers are the harder case: there is no override point for a helper class, so the asset manager approach above is the only clean one.

Verify with the page, not with the source

Load a page and look at what the browser actually requested, not at what you expect. Two things distort the picture: a page cache serving output from before your change, and pages you have not checked — an asset can be requested only by a search view or an article with a specific plugin. Clear the cache and check several views before concluding you have removed it.