In general you want to avoid sync loads of js assets because depending on how the server serving the asset hangs it can cause the webpage to hang as well. For example, if the server responds with a 404 right away then there are no problems. But if the server does not respond and leaves the connection open the browser will just wait the max time.
Shouldn't a goal be to mitigate the number of possible failures which can bring down your site by reducing the number of single points of failure?
1. If you're still using HTTP 1.x, sharding assets across origins lets the browser load them in parallel (if set up correctly). You can generally load just 6 assets in parallel per origin, and sharding is a way to get around that limit.
2. A library like jQuery is so popular, and is so often served from googles CDN, that chances are a user already has it in their local cache from when they downloaded it on some other site.
That said, yes - the downside is more surface area that might go down.
Which of these versions do you have cached?
3.2.1, 3.2.0, 3.1.1, 3.1.0, 3.0.0, 2.2.4, 2.2.3, 2.2.2, 2.2.1, 2.2.0, 2.1.4, 2.1.3, 2.1.1, 2.1.0, 2.0.3, 2.0.2, 2.0.1, 2.0.0, 1.12.4, 1.12.3, 1.12.2, 1.12.1, 1.12.0, 1.11.3, 1.11.2, 1.11.1, 1.11.0, 1.10.2, 1.10.1, 1.10.0, 1.9.1, 1.9.0, 1.8.3, 1.8.2, 1.8.1, 1.8.0, 1.7.2, 1.7.1, 1.7.0, 1.6.4, 1.6.3, 1.6.2, 1.6.1, 1.6.0, 1.5.2, 1.5.1, 1.5.0, 1.4.4, 1.4.3, 1.4.2, 1.4.1, 1.4.0, 1.3.2, 1.3.1, 1.3.0, 1.2.6, 1.2.3
As an actual answer, it would be variable proportional to the size of the window between releases mentioned here: https://en.wikipedia.org/wiki/JQuery#Release_history
I'm sure a fair amount of people serve jQuery from a local storage. The usefulness that the user might already have it cached is a non-zero point, no matter how insignificant you may think it is.
That narrows your suggested problem down dramatically.
The ratio of cost of storing a library versus the cost of GETing a library is very low, so the chances of already having a library cached can be very low for the EV to be worthwhile.
Weighing that against the chance of downtime is a bit more complicated, admittedly.
This seems to only apply to Chrome, whereas Firefox will happily download everything as fast as possible.
I know this because I fixed a bug recently where chrome was taking so long to download images that other resources on the page were timing out. No problem in Firefox.
[1] http://blog.olamisan.com/max-parallel-http-connections-in-a-...
Not sure why it was phrased that way but...isn't everybody?
I know that HTTP/2 is released and browsers support it, but I'm fairly certain that next to nobody is actually doing anything with it.
I also use HTTP2 at work, and on every personal project. It's supported by every browser [1], and comes with a slew of benefits. It's usually trivial to set up, if you want to give it a shot.
A few extra ms in initial download isn't so bad compared to having your site be completely inaccessible for reasons outside your control.
[0] https://developer.mozilla.org/en-US/docs/Web/Security/Subres...
Or would you do something in the browser to fetch the local one in case of failure?
[0]: https://hacks.mozilla.org/2017/01/using-immutable-caching-to...