This is a game I'm increasingly unwilling to play. The number of domains has got out of hand and are increasingly vaguely named - whether it's a CDN, ads or tracking is often almost impossible to judge.
Life's too short now sites are frequently calling out to 15 or more domains for me to jump through hoops just to get some text to display. Images I'm usually happy to dispense with. So I increasingly favour sites that don't need these games. There's still more than enough - for now at least!
Does it really decrease bandwidth usage and load times? Is there a study that looked at that specifically in recent months or is it just a assumption? I'm getting the feeling that including common JS libraries is on the decline and more and more developers are using node.js packages that are built into their frontend code. Not to mention that there are quite a few CDNs that are basically providing the same service for the most common frameworks and are thus detrimental to this theory.
If a browser already has https://code.example.com/blah.1.0.0.js in cache, wouldn’t it just use that instead of loading it again?
Edit: This post from StackOverflow lists a number of benefits, most of which will result in better perceived performance when using Google’s CDN vs hosting jQuery yourself: https://stackoverflow.com/questions/2180391/why-should-i-use...
This is an interesting comment.
So, packing all the JS into one file + optionally removing unused symbols would be similar to statically linked binaries. If optimized well, this would be the smallest amount of code / binary a system has to load to execute the program, but if you have multiple binaries, you might load the same library code multiple times. And security updates of libraries require you to recompile everything. But, in this context, you have to trust basically one JS-file from the host you're accessing.
On the other hand, dynamic libraries minimize the bandwidth / memory required to hold the code for a set of binaries, because libc/jquery/... just gets loaded once, instead of once per application. And, technically, shared libraries simplify security updates - update openssl, restart services, and hope that RHEL tested well so you don't end up with a mess. This would be really cool, if you think about it. Depend on magic-js-provider.acme.org/jquery/2.1.x.js, and get security fixes like that. Except the testing would be a nightmare.
More info on SRI: https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
CSP/SRI already enables this.
Ideally you should be able to serve content from your own domain + specify the hash, and let browsers optimize things by re-using cached content from another domain. There’s no easy/standardized way of doing that today.
Decentraleyes is an example of an existing codebase you could use: https://github.com/Synzvato/decentraleyes
Person goes to a porn site, get's file #A.
Spying site, offers file #A, but never delivers it.
If a person already has #A (i.e. doesn't request it), spy site knows they've been to porn site.
As a bonus, developers could use it knowing that there is much less likely to be a performance hit from fetching it.
I’m really torn by this sort of thing.
On one hand, when many sites use jQuery (for example), there’s huge benefits (bandwidth, speed, etc) in having it loaded from one location relatively infrequently and cached for many pages. This is exactly the promise of shared libraries, just on a much wider scale.
On the other hand, why aren’t web site operators delivering all of the code that is needed for the site to function? If they want all their users to execute that code, why aren’t they willing to serve it themselves?
I’m not sure what the right answer is, but this incident is a pro for pulling in all of your dependencies. The limited data plans that a lot of people have are a big pro for hosting libraries centrally.