Develop Reference

How robust is online sourcing of js scripts, and best practices

I come from an R background and I am starting to learn some javascript for data visualization purposes (think leaflet, d3, chart,...).
I trying to wrap my head around the fact that many tutorials and templates suggest loading packages, CSS, or even data directly from online sources. For example, https://leafletjs.com/examples/quick-start/ recommends:
Before writing any code for the map, you need to do the following
preparation steps on your page:
Include Leaflet CSS file in the head section of your document:
<link rel="stylesheet" href="https://unpkg.com/leaflet#1.7.1/dist/leaflet.css"
integrity="sha512-xodZBNTC5n17Xt2atTPuE1HxjVMSvLVW9ocqUKLsCC5CXdbqCmblAshOMAS6/keqq/sMZMZ19scR4PsZChSR7A=="
crossorigin=""/>
Include Leaflet JavaScript file after Leaflet’s CSS:
<!-- Make sure you put this AFTER Leaflet's CSS -->
<script src="https://unpkg.com/leaflet#1.7.1/dist/leaflet.js"
integrity="sha512-XQoYMqMTK8LvdxXYG3nZ448hOEQiglfqkJs1NOQV44cWnUrBc8PkAOcXy20w0vlaXaVUearIOBhiXZ5V3ynxwA=="
crossorigin=""></script>
It's not that you can't do things like that in R as well. But still, coming from "an R culture", I am used to the feeling that I have a local "hard copy" of every package and piece of data my code relies on. Then, when I ship my code (e.g., when I publish a Shiny app), an instantaneous of all required dependencies ship with it so it works as a standalone.
I understand the downside in terms of storage space on the server, but my sense is this might be faster and less more reliable.
What I'd like to know is whether my understanding of online sourcing and its tradeoffs in javascript is correct, and if so, what the best practices are to address potential shortcomings. In particular:
Do I understand correctly that dependencies like https://unpkg.com/leaflet#1.7.1/dist/leaflet.js or https://unpkg.com/leaflet#1.7.1/dist/leaflet.css are reloaded every time I refresh the page?
The page is therefore dependent on those links not breaking, right? Or are there some inner mechanics I am not aware of that avoid this kind of wasteful reloading and risky dependency?
If there are not, do people just live with the risk of links breaking down? Or is it best practice to keep a local copy of scripts like https://unpkg.com/leaflet#1.7.1/dist/leaflet.js and source them locally instead? Or even, is there yet another best practice, like using a "safer provider" as a source for dependencies (do I understand correctly that this is the role of services like https://www.jsdelivr.com/?)?

Do I understand correctly that dependencies like https://unpkg.com/leaflet#1.7.1/dist/leaflet.js or https://unpkg.com/leaflet#1.7.1/dist/leaflet.css are reloaded every time I refresh the page?
No. HTTP clients perform caching.
The page is therefore dependent on those links not breaking, right?
Yes. (Where "breaking" includes "being blocked by a firewall" (a particular problem for users in China who often find that they can access a website but the JS doesn't work because it is hosted somewhere blocked by the Great Firewall) and "the CDN server being taken over by someone malicious")
do people just live with the risk of links breaking down?
Yes. Risk is relative though. CDNs are generally selected because the provider is trusted.
The potential benefits include faster access to the JS through the CDN making use of edge servers and the possibility that (for popular libraries, at least) a client will have already cached the data because another site used the same library.
You're also using the CDN host's bandwidth to serve the JS instead of your own, which can be a cost saving.

Do I understand correctly that dependencies like https://unpkg.com/leaflet#1.7.1/dist/leaflet.js or https://unpkg.com/leaflet#1.7.1/dist/leaflet.css are reloaded every time I refresh the page?
Yes and no. The important thing here is caching. Browsers will cache resources that have been loaded. Therefore, if a user goes on the page and hits refresh over and over, they would only download these resources once and each reload will use the cached version. Thus no they are not reloaded every time.
However, any time the user clears the cache or a new user comes in without the resource in their cache, then the file will be downloaded. Cache expiration for browsers is not entirely predictable as it is controlled by the users to a large extent. However, chances are that if a user visited today and then again next week using the same browser, they would still have the item in their cache. However, if their cache is flushed, or they use a different browser, or a different machine, or it is an entirely different user who visits, then yes - they would load the resource again.
The page is therefore dependent on those links not breaking, right? Or are there some inner mechanics I am not aware of that avoid this kind of wasteful reloading and risky dependency?
The inner mechanics are caching from above. However, if a resource link is taken down for whatever reason, then the page cannot use it. This could happen because:
the source of the link is no longer working.
the source is blocked by a firewall or other mechanism thus the user does not have access to it.
the user employs some blocking mechanism like an adblocker or a script blocker extension which means they have opted into preventing requests for certain resources.
In all these cases the result is similar: the user might have access to the full functionality of the page if they have a cached copy of the resources it needs. Otherwise, they cannot use them. Script files will not be executed, stylesheets will not be applied, images will not show, etc.
The way to fix each of these would be different:
For non-working links you need to find a new source or maybe even host it yourself.
For blocked resources, you might need to find a hosting site that is acceptable for the blocking mechanism. Self-hosting might be an option.
If the user is blocking the scripts you they would most likely need to unblock them. Although a combination of the above two approaches might also work - hosting on a domain not known for ads might avoid being blocked and self-hosting might also work. At least in the case of uMatrix - the addon by default blocks all scripts external to the page (with very few exceptions). If the scripts come from the same domain, then uMatrix would allow them by default.
If there are not, do people just live with the risk of links breaking down? Or is it best practice to keep a local copy of scripts like https://unpkg.com/leaflet#1.7.1/dist/leaflet.js and source them locally instead?
There are essentially two approaches here. Each with their strengths and downsides. A quick breakdown is:
You can accept externally hosted resources.
Advantage: There are several big content delivery networks (CDN) such as unpkg or jsdelivr. They are widely used for their reliability. In addition, some libraries might offer their own CDN - jQuery does that, for example. Getting the resource from a CDN saves you badwidth and space but can also improve the load speed. CDNs might have better speed than your hosting does. Furthermore, for widely used libraries, the CDN copy is likely to be cached on the user site from visiting another site that used the same CDN copy as you.
Disadvantage: it does leave you dependent on resources you do not control. Big CDNs are reliable but you still cannot have any direct control if anything happened. And if you use a smaller CDN (e.g., library specific or otherwise) then you do not have data about its reliability. If an external link dies, your website will not work until it is fixed and that might take days - you have to find out about it, figure out what was changed, hopefully find a replacement link, update the site. If you cannot find a drop-in replacement, you might need to make more changes.
You can host the resources yourself.
Advantage: You are in complete control of when and how are things stored. You can even process the resources in some way to help with your application. Scripts can be minified, images can be scaled and resized into several different sizes to to optimise the display in different places (e.g., an icon, a small image, and a full size image).
Disadvantage: more space taken, more bandwidth taken. Also, now you have to manage all of these resources and make sure they exist, they are available etc.
You can of course also use a mixed approach. Host some resources, use others from an external place. Depends on what you want to do with your application and what level of control you want to retain versus how much extra effort and costs you want.
Saying all that, for a lot of small projects it does not matter that much which path is chosen. If you only use a handful of libraries it matters little whether you use them from a CDN or host them yourself. As long a reliable CDN provider is chosen, the chance of an outage is acceptably minimal. If you host the resources, chances are they would take up few hundred kilobytes (if that).
If your project grows and the list of dependencies you have starts to get bigger and bigger, it might be time to take stock and decide how where you host them and how you consume them. There is no single answer to this question, it will likely depend on what you already have. Perhaps your hosting has very little space. Or you pay per megabyte downloaded. In that case, external hosting would make more sense. Or perhaps you have a robust storage option for yourself and you are confident you can ensure the availability of your application, in which case self-hosting might be preferable

Load resources via CDN or minifiy/concat and serve yourself? [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 7 years ago.
Improve this question
When serving static css/js/etc resources one has the option to use a cdn or to use your own server.
With a CDN you include many includes but they can already be minified.
Alternatively you may minify and concatenate all the files into one css bundle and one js bundle.
Which method is more effecient/performant and why is this the case?

Interesting question. I'd say it depends.
Using a CDN can be slower than using your own server. This is primarily because the CDN resides on another domain, hence each request to the asset would result in an additional DNS round trip. This may cause the entire operation to become even slower than if you had just served it using your own server. That said, after a one-time DNS lookup penalty, DNS round-trip largely becomes a non-issue; the speed then depends on other network factors - how congested the CDN is, distance between the client and the CDN node (relative to your server).
The value of using CDN will only become apparent as your site grows - and your server begins to choke under heavy traffic. A CDN can be used to offload all static requests and prevent them from ever hitting your server. This is especially useful if your server bandwidth is limited and you're serving large files. If you're planning to scale, a CDN is almost a necessity.
CDNs may also help propagate your content to nodes nearer to clients from another part of the world. So if you don't have servers sprawled across multiple continents, CDNs can help provide fast access for a wider audience. This is because CDNs usually serves content from the node closest to the client.
All in all, whether you should use an external CDN depends on these factors:
how large are the static files in your site?
how much bandwidth does your server(s) have?
where are your servers located?
what is your site target audience?
how much traffic are you catering for?
I'd say most of the time, going with CDN is a better option, but there are cases where "going solo" can be justified. In my experience, the free CDNs are not exactly blistering fast compared to even modest AWS or GCE servlets. The network speed is also quite unpredictable, suffering from occasional lags (up to a few seconds) - this could possibly be because of periodic DDos attacks keeping the CDN busy. For small sites not expecting high traffic volume, it's usually faster to simply serve files off your own server, especially if you are catering mostly to local traffic.
You should always minify and concatenate files, regardless of CDN or not. Don't bother to keep individual library files separate. A false promise that you may have heard regularly: if the user has visited another site that happened to use the same library file from the same CDN, his browser would have already cached that file, and you'd save a HTTP round trip request for fetching that file.
Sadly, more often than not, this does not happen. Even with jQuery, the most popular JS library, it seldom happens. There are simply too many different versions of jQuery in deployment as websites are developed at different times. Furthermore, different sites use different CDNs - Akamai, CloudFlare, Amazon CloudFront, cdnjs, MaxCDN, the list goes on... It's actually quite rare to find two popular sites using the same CDN and the exact same library file.
So, if you don't concatenate files in hope of the occasional browser cache hit (you save what - 28KiB?), you incur the HTTP request overhead for EVERY single file. I'd say just go ahead and concatenate all your JS into one big file, including jQuery and all other vendor libraries - it's gonna be faster in 99% of the time.

In my opinion, using a CDN is more efficient because you'll benefit from parallelism : while your server will serve the main content, requests will be made in parallel to serve content from the CDN.

Lightweight JS Library vs Google-hosted CDN

When page-load speed is the priority, is it better to use a minimal, lightweight javascript library (hosted on a CDN), or is it better to use something like jQuery, hosted on Google's CDN that the browser more than likely already has loaded?
Edit: What my question really boils down to is whether the cross-site caching effect of using jQuery hosted on Google's CDN outweighs the benefits of using an ultra-light library, also on a CDN.

jQuery is not heavy as compared to any other javascript library at present looking at the amount of features and browsers it supports.
You can consider this factor while selecting the plugins to be used on the page because they are written by various users and some may right it intelligently considering this factor or some may just right it for the sake.
Yes, if you use CDN like Google for jQuery it is most likely that the library must be cached by the browser and also Google has number of servers based on location so you don't have to worry about it.

Decreased Latency
A CDN distributes your static content across servers in various, diverse physical locations. When a user’s browser resolves the URL for these files, their download will automatically target the closest available server in the network.
In the case of Google’s AJAX Libraries CDN, what this means is that any users not physically near your server will be able to download jQuery faster than if you force them to download it from your arbitrarily located server.
There are a handful of CDN services comparable to Google’s, but it’s hard to beat the price of free! This benefit alone could decide the issue, but there’s even more.
Increased parallelism
To avoid needlessly overloading servers, browsers limit the number of connections that can be made simultaneously. Depending on which browser, this limit may be as low as two connections per hostname.
Using the Google AJAX Libraries CDN eliminates one request to your site, allowing more of your local content to downloaded in parallel. It doesn’t make a gigantic difference for users with a six concurrent connection browser, but for those still running a browser that only allows two, the difference is noticeable.
Better caching
Potentially the greatest benefit of using the Google AJAX Libraries CDN is that your users may not need to download jQuery at all.
No matter how well optimized your site is, if you’re hosting jQuery locally then your users must download it at least once. Each of your users probably already has dozens of identical copies of jQuery in their browser’s cache, but those copies of jQuery are ignored when they visit your site.
However, when a browser sees references to CDN-hosted copies of jQuery, it understands that all of those references do refer to the exact same file. With all of these CDN references point to exactly the same URLs, the browser can trust that those files truly are identical and won't waste time re-requesting the file if it's already cached. Thus, the browser is able to use a single copy that's cached on-disk, regardless of which site the CDN references appear on.
This creates a potent "cross-site caching" effect which all sites using the CDN benefit from. Since Google's CDN serves the file with headers that attempt to cache the file for up to one year, this effect truly has amazing potential. With many thousands of the most trafficked sites on the Internet already using the Google CDN to serve jQuery, it's quite possible that many of your users will never make a single HTTP request for jQuery when they visit sites using the CDN.
Even if someone visits hundreds of sites using the same Google hosted version of jQuery, they will only need download it once!

It's better to use the library that best suits the needs of your application and your development team. A super-lightweight library might save you a few hundred milliseconds of load time, but may end up costing you in development hours if your team has significantly more experience with jQuery/MooTools/Dojo etc.
If new feature implementation and bug fixing is hindered by using a second-rate tool solely to improve load times, your users are ultimately going to suffer.

Serve jQuery UI from Google's CDN or as a local copy?

while it's better to serve jQuery from Google's CDN jQuery UI is a different beast. My local modified copy weighs 60kb and the one in Google's CDN ~200kb.
Are there any numbers on how many sites uses the CDN? (read: how many users have it in their cache). How do I know/calculate if it's better to serve it locally?

Coming late to the party here, but allowing for gzip compression, you're basically comparing a download of ~51k from Google's CDN (the 197.14k content becomes 51.30k on-the-wire) vs. ~15.5k from your own servers (assuming your 60k file gzips at the same ratio as the full jQuery UI file does, and that you have gzip compression enabled). This takes us into a complex realm of:
pre-existing cache copy
latency
transfer time
number of requests
proper cache headers
And the answer to your question is a big: It depends, try each of them and measure the result in a real world scenario.
Pre-Existing Cache Copy
If a first-time visitor to your site has previously been to a site using jQuery UI from Google's CDN and it's still in their cache, that wins hands down. Full stop. No need to think about it any further. Google uses appropriate caching headers and the browser doesn't even have to send the request to the server, provided you link to a fully-specified version of jQuery UI (not one of the "any version of 1.8.x is fine" URLs — if you ask for jQuery UI 1.8.16, Google will return a resource that can be cached for up to a year, but if you ask for jQuery UI 1.8.x [e.g., any dot rev of 1.8], that resource is only good for an hour).
But let's suppose they haven't...
Latency and Transfer Time
Latency is how long it takes to set up the connection to the server, and transfer time is the time actually spent transferring the resource. Using my DSL connection (I'm not very close to my exchange, so I typically get about 4Mbit throughput on downloads; e.g., it's an okay connection, but nothing like what Londoners get, or those lucky FiOS people in the States), in repeated experiments downloading Google's copy of jQuery UI I typically spend ~50ms waiting for the connection (latency) and then 73ms doing data transfer (SSL would change that profile, but I'm assuming a non-SSL site here). Compare that with downloading Google's copy of jQuery itself (89.52k gzipped to 31.74k), which has the same ~50ms latency followed by ~45ms of downloading. Note how the download time is proportional to the size of the resource (31.74k / 51.30k = 0.61871345, and sure enough, 73ms x 0.61871345 = 45ms), but the latency is constant. So assuming your copy comes in at 15.5k, you could expect (for me) a 50ms latency plus about 22ms of actual downloading. All other things being equal, by hosting your own 60k copy vs. Google's 200k copy, you would save me a whopping 52ms. Let's just say that I wouldn't notice the difference.
All is not equal, however. Google's CDN is highly optimized, location-aware, and very fast indeed. For instance, let's compare downloading jQuery from Heroku.com. I chose them because they're smart people running a significant hosting business (currently using the AWS stack), and so you can expect they've at least spent some time optimizing their delivery of static content — and it happens they use a local copy of jQuery for their website; and they're in the U.S. (you'll see why in a moment). If I download jQuery from them (shockingly, they don't appear to have gzip enabled!), the latency is consistently in the 135ms range (with occasional outliers). That's consistently 2.7 times as much latency as to Google's CDN (and my throughput from them is slower, too, roughly half the speed; perhaps they only use AWS instances in the U.S., and since I'm in the UK I'm further away from them).
The point here being that latency may well wash out any benefit you get from the smaller file size.
Number of Requests
If you have any JavaScript files you're going to host locally, your users are still going to have to get those. Say you have 100k of your own script for your site. If you use Google's CDN, your users have to get 200k of jQuery UI from Google and 100k of your script from you. The browser may put those requests in parallel (barring your using async or defer on your script tags, the browser has to execute the scripts in strict document order, but that doesn't mean it can't download them in parallel). Or it may well not.
As we've established that for non-mobile users, at these sizes the actual data transfer time doesn't really matter that much, you may find that taking your local jQuery UI file and combining it with your own script, thus requiring only one download rather than two, may be more efficient even despite the Google CDN goodness.
This is the old "At most one HTML file, one CSS file, and one JavaScript file" rule. Minimizing HTTP requests is a Good ThingTM. Similarly, if you can use sprites rather than individual images for various things, that helps keep image requests down.
Proper Cache Headers
If you're hosting your own script, you'll want to be absolutely sure it's cacheable, which means paying attention to the cache headers. Google's CDN basically doesn't trust HTTP/1.0 caches (it sets the Expires header to the current date/time), but does trust HTTP/1.1 caches — the overwhelming majority — because it sends a max-age header (of a year for fully-specified resources). I'm guessing they have a reason for that, you might consider following suit.
Since you want to change your own scripts sometimes, you'll want to put a version number on them, e.g. "my-nifty-script-1.js" and then "my-nifty-script-2.js", etc. That's so you can set long max-age headers, but know that when you update your script, your users will get the new one. (This goes for CSS files, too.) Do not use the query string for the versioning, put the number actually in the resource name.
Since your HTML presumably changes regularly, you probably want short expirations on that, but of course it totally depends on your content.
Conclusion
It depends. If you don't want to combine your script with your local copy of jQuery UI, you're probably better off using Google for jQuery UI. If you're happy to combine them, you'll want to do real-world experiments either way to make your own decision. It's entirely possible other factors will wash this out and it won't really matter. If you haven't already, it's worth reviewing Yahoo's and Google's website speed advice pages:
Yahoo! Best Practices for Speeding Up Your Website
Google's Let's make the web faster site

Google's CDN of jquery UI weighs in at 51 Kb:
https://ajax.googleapis.com/ajax/libs/jqueryui/1.8.16/jquery-ui.min.js
The HTML5 Boilerplate uses a fallback for jquery loading:
<!-- Grab Google CDN's jQuery, with a protocol relative URL; fall back to local if necessary -->
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.5.1/jquery.js"></script>
<script>window.jQuery || document.write('<script src="js/libs/jquery-1.5.1.min.js">\x3C/script>')</script>
You can apply it to jquery ui:
<script src="//ajax.googleapis.com/ajax/libs/jqueryui/1.8.16/jquery-ui.min.js"></script>
<script>window.jQuery.ui || document.write('<script src="js/jquery-ui-1.8.16.min.js">\x3C/script>')</script>
You load the CDN version then check for the existence of jquery ui (you can't guarantee 100% up-time for any CDN). If jquery ui doesn't exist, fall back to your local. In this way, if they have it already in their cache, you are good to go. If they don't and the CDN can't be retrieved for any reason, your good to go with your local. Fail safe.

I think size comparisons miss the point of the CDN. By serving a copy of jQuery (or other library) from a public, commonly-used CDN, many users will have a cached copy of the library before they arrive at your site. When they do, the effective size of the download is 0KB compared to 60KB from your server.
Google's CDN is the most widely used, so you will have the best chance of a cache hit if you reference it.
For numbers comparing the various CDNs please see this article.
For what it's worth, the minified version of Google's jQuery copy is much smaller than the size you mentioned.

I would say what matter is the load you have on your server. For the user it doesn't really matter if they are downloading it from your server or from google's server. These days there is enough bandwidth for 140kb to be easy to ignore on the user's side.
Now the really question is if you made changes to jQuery UI. If yes then you should serve your own copy. If not, then it's ok to serve google's. Because after all what you are aiming to is to lower load on your side.
And besides the caching doesn't happen just on the user's browser, but also on content distribution nodes that they are accessing. So it's safe to say that google's copy is cached almost for sure.

With sizes this small, what matters is number of http requests for a first-time visitor to your site.
If for example your site has script combining and minification configured so the entire script for a first time visitor is either one request or included in html itself, using your local copy is better because even a cached copy of JqueryUI isn't faster than all the script for the site showing up at once (the cached call still has to go out and check for Modified).
If you don't have a good script combining and minification setup (so you were going to send jqueryui separately, either from your site or elsewhere), use outside caches wherever possible.

Benefits vs. Pitfalls of hosting jQuery locally [closed]

Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 3 years ago.
Improve this question
We're currently pulling jQuery and jQueryUI (and jQueryUI CSS) libraries from the google CDN. I like this because I can call google.load("jquery", "1");
and the latest jQuery 1.x.x will be used.
Now I am to pull the libraries locally because of security.
I'm happy to pull them locally but I'm wondering what are some of the other benefits and pitfalls to watch out for?

I always use the CDN (Content Delivery Network) from Google. But just in case it's offline:
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script>
<script>!window.jQuery && document.write('<script src="jquery-1.4.2.min.js"><\/script>')</script>
Grab Google CDN's jQuery and fallback to local if necessary
Edit:
If you don't need to support IE6 and your site has partial https usage you can remove the http as well:
<script src="//ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script>

The main benefit of having them on a CDN is that the files can be downloaded in parallel to files downloaded from your own website. This reduces latency on every page. So, the flip side of this is a pitfall of hosting locally - increased latency. The main reason for that is that browsers are limited in the number of connections that they can make at the same time to the same web domain. In IE6 this was defaulted to 2 concurrent connections to the same domain - shared between all open windows of IE!! In IE8+ it improved, defaulting to 6, which is inline with FF/Chrome, but still, if you have a lot of images and you are not using sprites, you will experience heavy latency.
Using a CDN, I would always set the library version explicitly rather than getting the latest one. This reduces the risk of new versions breaking your code. Not very likely with jQuery, but possible.
The other main benefit of using a CDN is reduced traffic on your site. If you pay per GB or you are on a virtual server with limited resources, you might find that overall site performance increases and hosting costs come down when you farm off some of your content to a public CDN.
Make sure you also read the other answer to this question by #Xaver. This is a very good trick

Others have covered the benefits. Pitfalls:
If you only include content from your own server, that's one server that needs to be running—and not blocked by firewalls etc—to make your site work. Pull script from a third party and now that's two servers that need to be running and unblocked to make your site work.
Any site you pull <script> from can completely control the user's experience on your site. If Google were feeling evil they could put something in their copy of jQuery to log your keypresses, steal personal information from the page you're on to tie into their web tracking database, make you post “I love Google!” comments to every form, and so on.
Google probably aren't actually going to do that, but it's a factor that's out of your control, and certainly something to worry about with other script-hosting services. There have been incidents before where stats scripts have been compromised with malware loaders.
Before including any script from a third party—even on one single page of your site—you must 100% trust them with all user-accessible functionality visible on that hostname (including web-facing admin functions).

Google CDN:
caching, good for performance, more users likely to have it already, and it downloads in parallel
if ever, heaver forbid cdn goes down. you're screwed.
if a new version breaks your existing plugins or site, you'll know about it possibly too late
Locally:
development without being connected to the net is possible
can still get some performance benefits by gzipping, in addition to minifying

I prefer to use my local version, because I don't have control about what they will provide.
For example I don't want my users to get affected by google-analytics or anything similar, because this is a legal problem in my country.

Benefits: (Specifically for Google's CDN)
Downloads in parallel with your files. Other answers address this further
Google's Servers are likely to be able to physically deliver the content faster
Common libraries and frameworks might already be on the user's machine, as the HTTP cache for a CDN is universal across all sites
Your bandwidth wouldn't have to go towards serving large library files

Virtually every way you look at it, using Google's CDN is a good thing.
Performance will be improved (albeit fairly marginally, unless your site is really busy), and the amount of data your servers have to transmit will go down (although jQuery isn't exactly a massive thing to download), etc.
The only reason you wouldn't want to use it is if you don't trust Google. By using it, you are effectively giving Google an additional window of information into your site's traffic profile, including knowledge of URLs that you may otherwise not want to make public (eg secure areas of your site).
If you are paranoid about security then this may be enough to persuade you not to use them (after all, hosting it yourself isn't exactly going to slow your site down to a crawl), but in general most people would take the pragmatic view that Google knows enough about their site already that adding this won't make much difference.

Probably I'm in minority nowadays, but I'd say that you don't want to use CDN unless you really need to. Key factors to start using it are:
Cross geo users. If you host your website in the US but have visible amount of European users - CDN will improve the loading time.
Big amount of users and\or big content, so one main server is not enough any more. One can think of any porn-video website (or Netflix, if you want). Video stream is a heavy load, with CDN would be much much less load on the main server.
But... the point is that these points are not really applicable to 90% of websites in the world. I bet you're not Facebook with millions of online users around the globe, you're not Pornhub with hundreds of GB transferred every second.
If your website is targeted to users in your city/country and capacity of one server is enough for amount of users you have - why would you ever want a CDN? It's quicker for your users in your city and simpler for you to fetch everything from your main server locally.
It was more about CDNs in general, now let me be closer to the actual question about jQuery or any other library.
If you want your website to stay accessible and working without maintenance for more than a year, let's say - put it locally. Libraries nowadays are being updated in a crazy tempo which you probably don't want to follow. And old versions are being deleted eventually. Moreover, the whole library can die (probably not applicable to jQuery though).
From my recent experience - I updated TinyMCE on the website I maintain from 3.x.x (dated 2012) to 5.x.x (dated Spring 2019). This website was working for 7(seven!) years without any maintenance in this part of the logic. There was no "minifying" concept back then and CDNs were not as common as now. But even if they would be common - you never know what will happen in 3-5-10 years from now. Usually you want your website to stay alive even without you maintaining it, don't you? However if you pull jQuery from CDN today, then this link may (and, probably, will) break in 5 years.
Solution with CDN AND fallback to local version as #Xaver suggested can be a good compromise. But... maybe just get rid of CDN link? ;)

To me it really depends on how much control you desire to have. If you are like me and need to develop on local host when working and traveling. Having the jquery files local is better than having it hosted on google or else where.