@PasqualeJS, perhaps another plugin builder will chime in here, but properly built plugins don’t load all of their dependencies (scripts they add to the header) on every page load. This only happens on a page where the plugin is actually in use.
Now, there are some poorly-built plugins that put their dependencies in the “Shared” section, rather than in the “Headers” section of the element or action in question.
Scripts that are added in “Shared” will be loaded for “every page in the site”. (But what this means is that the script will be downloaded on the first page but thereafter it is cached and need not be accessed again. Though the script will still be added to the header and executed and that’s not desirable for plugins that don’t need to do that. Examples of plugins that would need to do that: A plugin for Google Analytics, a plugin for cookie consent, etc.)
In a properly-built plugin, any dependencies will be attached to the header only on pages in which the plugin is used. (An example of a plugin where this is done right is my “Calendar Grid Pro” plugin, which loads the giant version of moment.js and a pretty big locales file. But these only wind up in “sources” if the plugin is actually instantiated on the page.)
NOW, the above being said, you might have noticed that the core code for ALL of the plugins used in your app does seem to be “in the page” in your app. The code for plugins is delivered in the file called static.js. And that file does, in fact, include the entire core code of all of the plugins installed in your app.
However, note that this file only needs to be fetched once and then it’s cached. This seems like a sort-of-reasonable optimization to me. Your app is… well… an app and depends on certain things and when a session is started, we might as well get all the things we’re going to need. But note that on subsequent pages, static.js is already present and the browser doesn’t need to fetch it again.
This does argue for removing any plugins that you don’t actually use anywhere. But it seems like a reasonable optimization to me. (Certainly it’s not as sexy as more modern code splitting, but it is what it is.)
Though I should note: Even though static.js will be cached, that code is still executed on a new page load. (Particularly, one thing that happens is that all of the info about all of the plugins is written on the window to window.plugins. This takes a small number of milliseconds depending upon the client, but if you look at the waterfall graph in Network, you’ll see that on page loads after the first, static.js isn’t fetched, just executed.)
But there’s no way to keep this from happening on a per plugin basis.
In summary: 1. Yes, the code for all plugins in your project “is in” every page of your app, but this doesn’t mean that the code is being fetched on every page load. 2. Properly built plugins do not load their dependencies on pages in which those dependencies are not required (and again, once a dependency is fetched its cached in the browser). 3. All plugins (used in the project or not), do add some bulk to static.js and one should remove plugins that are not used anywhere in one’s app. 4. There’s no workaround for (3), but if you’re using plugins that aren’t properly built (see 2), you should seek alternatives that are.