I guess the lesson to learn here is that you shouldn't rely on externally hosted assets. Just host it yourself, its not that hard. If you're concerned about the bandwidth cost, you should probably charge more for the service your providing.
What’s missing is a way to tell the browser to use a certain resource (identified by its hash) and a url to download it.
That way the browser could cache the object across websites and download from a source that the requesting website controls.
It could look like this
hash://sha256/71dc8dd15ea156387fa9efaf380e7f8d39187a549649bec62a39aee3cf4fdc55//https://raw.githubusercontent.com/cdnjs/cdnjs/2c95eae0dc3569f0cb15c8a5f9173220b49156bc/README.md
And I believe it's a good solution to restrict such a feature to files already marked with a hash on the origin. They would only do that for common libraries found elsewhere as well.
Just stop loading 100 resources on a single pageload. If a website loads just one css and maybe one js there wouldn't be any performance issues, unless of course those files are several megabytes in size.
I feel like we're really close now. Come on guys, one last push.
/s
The major browsers (FF, Chrome, Safari) all fragment cache by the domain in the URL bar now, for privacy reasons, so this doesn't apply anymore.
> the browser could cache the object across websites and download from a source that the requesting website controls
You can't do this without reintroducing the same privacy issues that cache fragmentation was introduced to prevent.
Performance vs security trade offs seem to be popping up everywhere recently.