It is too bad that the HTML standard has no built in way to fallback.<p>They've added a cryptographic hash/integrity and the async/defer attributes to the script tag, but something as essential as a fallback if a script or stylesheet fails to load (which the browser is best placed to know), has no built in functionality.<p>Instead you're left doing JavaScript tricks which for missing CSS gets a little ugly[0]. But CDN with local fallback (or visa versa) has been common now for decades but yet no official support at all. Honestly if the integrity attribute is specified the browser should just be able to fall back to a cached copy it has (e.g. jquery.1.2.3.min.js has a crypto hash of ABC123, and I have that file already).<p>[0] <a href="https://stackoverflow.com/questions/7383163/how-to-fallback-to-local-stylesheet-not-script-if-cdn-fails" rel="nofollow">https://stackoverflow.com/questions/7383163/how-to-fallback-...</a>
I always self-host my JS/CSS libraries: the connection is already open (thanks to keep-alive) so what's the problem of serving a couple of more KiBs of compressed data instead of making an additional DNS request and a new connection to a CDN?<p>I understand that the CDN version of the library may have already been cached by the browser while visiting other websites, but does it really save that much time/traffic compared to self-hosting?
Great opportunity to strip out unnecessary uses of jQuery, and move to vanilla javascript.<p><a href="http://youmightnotneedjquery.com/" rel="nofollow">http://youmightnotneedjquery.com/</a>
Years ago, I used to link the library from Google [1] or CloudFlare [2].<p>Nowadays, with all the Node.js stuff that goes around modern front-end, I don't see the point of embedding a JavaScript library from a CDN, unless that library is dependent on a remote service, e.g. Google Analytics, Google Maps, etc… That being said, if you are still maintaining a legacy website that depends on jQuery, you should consider to embed the library like this instead:<p><script>window.jQuery || document.write('<script src="/js/jquery.min.js"><\/script>')</script><p>[1] <a href="https://developers.google.com/speed/libraries/" rel="nofollow">https://developers.google.com/speed/libraries/</a><p>[2] <a href="https://cdnjs.com/libraries/jquery" rel="nofollow">https://cdnjs.com/libraries/jquery</a>
<a href="https://www.jsdelivr.com" rel="nofollow">https://www.jsdelivr.com</a> is a good alternative.
We actually monitor for https failures and automatically remove the problematic CDN.
Starting to see complaints, questions, etc. on twitter about it too.<p><a href="https://twitter.com/search?f=tweets&q=jquery" rel="nofollow">https://twitter.com/search?f=tweets&q=jquery</a>