Also reliability: by using a 3rd party service for important parts of your page/site/app for performance reasons is essentially RAID0 for web requests. You now

Also reliability: by using a 3rd party service for important parts of your page/site/app for performance reasons is essentially RAID0 for web requests. You now have two (or more) points of failure (your infrastructure and the CDN) each of which can single-handedly break your stuff. And the break doesn't have to happen at the CDN, it could for instance be a failed DNS lookup, or an odd routing error at an ISP which affects the CDN but not your main location, a plugin such as noscript, or many other possibilities. Yes, there are methods that allow you to fall-back to your own local copy if the CDN copy fails to arrive, but that is adding further complication and could effectively slow down your page/app by getting in the way of some “make the initial render as early as possible” techniques. I never liked the idea of loading code from CDNs, or anything else for that matter, even when the benefits seemed more real than they do now. > Finally performance: … there used to be the argument that the JS may already be cached For larger CDNs with the resources to have many widely distributed points of presence there is a potential benefit that is still relevant even with partitioned caching: multi-view DNS or any-cast routing can result in a user's request being served from a topologically closer host than otherwise. Though I suspect that is you care that much about this small benefit you are probably running your own multi-homed infrastructure using the same technique(s) so CDNs aren't needed for you to benefit from them. And back to reliability: such methods further abstract away from the simple “make request, get response from expected host” arrangement and make diagnosing problems further down the line more difficult.