For the last half decade, almost all apps have been deployed with webpack/browserify/other bundles. All the assets get smashed together into a big custom bundle that doesn't get cached across sites.
This has been really sad & a big loss for the web, in my opinion. And it's one that we were about to emerge from[1], it seems like.
Alas, if we do go back to a more old-school CDN-based style of web scripting/javascripting, powered by our new ES Modules (& hopefully Import Maps) this new sharding-by-origin change will mean that we will never ever see the CDN hit-rate benefits we once saw.
It seems like it is a necessary change, to protect the user from being tracked, but it still hurts my heart so much, that we are so near to getting back to sharing resources on the web, only to have all that sharing snatched away. Whatever metrics you are looking at today, know that they represent a very sad state of affairs, that brought great pain & suffering to the hearts of many webdevs who aspired for much much much higher hit rates.
I think the linked resources show that it probably never worked the way we hoped it would. The first investigation I linked was from 2011, prior to the existence of webpack.
A lot of people have high-hopes that import-maps[1] will allow us to consume a variety of ES Modules from a variety of CDNs effectively. It gives us back the "bare specifies" that CommonJS introduced, where you say `import $ from "jquery/index.js"` in the code you write. Then the import-map helps the browser understand which CDN or otherwise to reach out to get that index.js file. We think this will allow ES Modules to be broadly usable & "modular", in a way that they have not been. I & a bunch of others are holding our breath on this one. It feels like it really can fix this huge hang up, giving us a way to author modules in a way that allows modular consumption.