If it's not for this page, then why are you loading it? Load it when the user goes to that other page.
That's the idea behind bundle splitting and whatnot. Don't send users code they don't need yet. Most of them are never going to get to the part of the page that does need that code.
Depending on what you are loading it may be more efficient to bundle everything in one file. If you are only loading a few kb per page, the overhead and extra time required for the network requests mean it's probably not worth splitting code.
At my day job we use app splitting rather than page splitting. Instead of breaking our codebase into individual pages and loading only those files, it's broken into apps. So you might load too much stuff for what you're currently doing, but you're never loading code that's completely unrelated.
A downside to that is that if you hit all our apps in one browsing session, you might download some vendor libraries like 10 times. But it's unlikely that a real user would ever do that.
We do something similar, but common code is shared. Webpack has a feature called chunking which we use to put everything from node_modules into it's own bundle which is loaded across multiple apps. Then the app specific code is loaded on each page.
In many cases it may not. Remember that you have to fetch data anyway when loading a new page. You could load the new parts of the CSS on the same connection.
Agreed. I often find the extra initial loading time is worth the improved user experience across the rest of the website once the bundles CSS file is cached.
Also you don't have the combinatorial explosion of making sure that the CSS for the new sidebar/footer/reusable element is available every time it appears in a page. It also simplifies debugging specificity issues a little (but shuffles the problem around a bit).
That's the idea behind bundle splitting and whatnot. Don't send users code they don't need yet. Most of them are never going to get to the part of the page that does need that code.