You want to use jQuery? Why not use their CDN to load it into your site? You want to use that gallery- or form-javascript? They have a convenient CDN for you. I don't believe using those is actually in your interest.
A CDN, a content delivery network, can do a lot of things for you. It can provide a way for you to deliver the assets of your high-volume site in a performant way, it can protect you from denial of service attacks and several other things. But what a lot of small websites use them for is to include some third party Javascript and sometimes even CSS into their site. The idea is, that instead of providing a copy from your own site, browsers are loading these resources from a central server once and then cache them, thus eliminating the need to download it several times.
Let me focus on that exact use case, small websites including third party resources via CDN to gain a small optimisation. The concept does work and it provides a performance benefit, even bigger than just the time to download the file from the server, since the browser can cache the parsed and optimised version of the file, but there are several downsides to it, which make this very unappealing.
First of all, the javascript that you are loading via CDN has to have a big enough distribution that a normal user stumbles over it often enough to benefit from it. A gallery-script used on maybe 20,000 small websites delivered via CDN will not have the desired effect for the normal user, simply because he only ever just visited one of those sites. That makes this concept interesting only for really widely distributed scripts, like jQuery. At the same time, you have to decide what you are loading from the CDN. Do you take the chance of always using the latest version of the script, making it more likely that others use them, too, at the same time taking the risk of breaking your site due to a change in a new version. Or do you take a specific version to secure yourself from breaking changes, while drastically reducing the number of other users using the same script. Remember, jQuery at the time of writing has 146 releases on Github, so you sticking to just one of those versions will greatly reduce the number of sites that use the same version.
Using such a CDN also means, that you can not modify the script. You are required to use the version that they ship you and if you need to make modifications, you again have to create your own copy.
With the effectiveness of CDNs covered, let us look at the technical side. The thing is, that with such a third party service, you are introducing a new source for failure into your site. Granted, it is pretty unlikely that a well maintained CDN goes offline, but if it does, it also breaks all those other sites that depend (in part) on its content. Consider how many websites would be unusable when the jQuery CDN were to become unreachable. And that doesn't even have to be a technical issue of the CDN, but your government could block access to the CDN or an ISP could have the route to the CDN misconfigured. In all those cases your site would be broken (and you wouldn't even necessarily notice it at first) and getting your site working again means getting a copy of the file from the CDN and changing your site to point to your copy of it.
Unexpected outages are not the only risk here. What if someone got unauthorised access to the CDN and changed the files on there? What if that person added malicious code, which attacks your visitors or your own site? You don't have any control over what the CDN delivers to your users. You are relying on trust that you are giving the people behind the CDN to not screw you over.
Last but not least, it is a matter of data privacy. With such a CDN, you are (potentially) reporting each and every visitor of your website to a third party. Again, you are trusting the CDN to not record your users visits and to treat their data responsibly.
Now we need to see if these downsides can be outweighed by the benefits of the CDN. My example again is the CDN from jQuery. This Joomla site right now uses the minified version of jQuery 1.12.4, which weighs in at about 97kb, gzipped it is just 33kb. That is between 7 and 10% of the overall size of one of the pages of this website, similar numbers apply for other websites that I maintain for customers. So we could potentially save 10% of bandwidth if we didn't have to download this file for this website again. However, loading this file on my home machine with a landline takes just 77ms. That is almost just the round trip from me to the server and back. At the same time however generating the page on the server takes between 300 and 800ms. That means that 10% saved bandwidth does not equal to a 10% decrease in waittime for the user.
Granted, people do access websites from slow connections and those would benefit in a bigger way from such a CDN. However, if we take a GSM or EDGE connection as an example, this still means that a typical website of about 1MB in size would take around 3 minutes to load on an EDGE connection, while just around 6 seconds of those 3 minutes would be used for the jQuery CDN file.
So should you use a CDN to deliver third party resources to your users? I would say no. The additional risks, the data privacy problems and the loss in control are not countered with a big enough performance gain to merrit such a step. What I would rather look into is merging different assets into larger files and optimising the response times of your server. Especially websites with a complex CMS behind them often enough have great potential for improvements here.