[0xCMP]

Because if you're not getting the real benefit (improved response times due to caching) you can stop worrying about hashing it properly or not and simply serve a copy you know to be good (or at least known and probably version controlled). Now you don't need to hash or know which hash is correct or worry about the user getting served the wrong file because someone else got hacked.

[TZubiri]

Not sure I follow, how does hashing mean you lose improved response times or caching?

Do you mean that hashing the file takes time? I guess that can be significant, but it's probably 2 or 3 cycles per byte, and average js size is like 10kb tops? 30khz doesn't look like much, it's a millionth of a second.

[0xCMP]

No, the hashing either when generating or checking is very fast like you said. Hashing itself isn't the culprit, but the battle between browsers and those fingerprinting users.

Originally the point of using a shared CDN like this was that if others used it too the file would already be cached on the user's computer and make it even faster. But, this feature was used for fingerprinting users by checking which files from other websites were cached and browsers have isolated the caches in response which makes it impossible to get the speed benefits from before.

So if you're not getting that speed benefit, and only really getting a tiny bandwidth reduction, the risks of serving the file from a 3rd party (which could be mitigated by the hashes) aren't worth it compared to simply vendoring the file and serving it yourself.

So it's not that hashing prevents caching or lowers response times, but that the risk it is mitigating isn't worth the effort. Just 'err on serving the file yourself.