> And Google is one step closer to tracking everything everyone does on every website.
As long as you link the right files (make sure you specify the specific version and not use the one to give the lastest), there are very long expires headers and Google will have no idea the vast majority of your users ever visited. A user just needs to visit one site using the same version of Google hosted jQuery and they won't have to download it again when visiting another site.
> Hosting your own 23kb jQuery file does not cost that much. Actually practically nothing. Not in terms of bandwidth and neither in terms of perceived performance. Unless you are hosting your website on a 36.6kbps modem, host your own. Do the web some good.
People aren't using Google CDN for the cost, but for the performance. A high percentage of user will have the file cached already, so the performance gain is quite significant. Doubly so in a mobile environment.
> - If you use the standard jQuery hosted off Google's CDN, most users won't have to load it in the first place. So that overhead doesn't count. Only if you do some boneheaded thing like rolling your own version and hosting it on your server are you going to guarantee every visitor has to download jQuery.
> If everyone simply linked the "canonical" version of jQuery (the CDN link is right on their site) then requiring jQuery will be effectively free because it will be in everyone's cache.
It's not, though. I ran this experiment when I tried to get Google Search to adopt JQuery (back in 2010). About 13% of visits (then) hit Google with a clean cache. This is Google Search, which at the time was the most visited website in the world, and it was using the Google CDN version of JQuery, which at the time was what the JQuery homepage recommended.
The situation is likely worse now, with the rise of mobile. When I did some testing on mobile browsing performance in early 2014, there were some instances where two pageviews was enough to make a page fall out of cache.
I'd encourage you to go to chrome://view-http-cache/ and take a look at what's actually in your cache. Mine has about 18 hours worth of pages. The vast majority is filled up with ad-tracking garbage and Facebook videos. It also doesn't help that every Wordpress blog has its own copy of JQuery (WordPress is a significant fraction of the web), or for that matter that DoubleClick has a cache-busting parameter on all their JS so they can include the referer. There's sort of a cache-poisoning effect where every site that chooses not to use a CDN for JQuery etc. makes the CDN less effective for sites that do choose to.
[On a side note, when I look at my cache entries I just wanna say "Doubleclick: Breaking the web since 2000". It was DoubleClick that finally got/forced me to switch from Netscape to Internet Explorer, because they served broken Javascript in an ad that hung Netscape for about 40% of the web. Grrrr....]
> If you use Google CDN, why does it matter how big jQuery is?
1. Most people won't have the version you wanted to use cached from the location you were trying to use it from. Studies show hit rates on requests for libraries on "shared" CDNs are very low in real world conditions. (Also, caches are small. Oh, you wanted 2.3.4r17 of BigLib? I've only got 2.3.4r18 cached; I'll go ahead and delete that so I have room to download your new copy.)
2. We don't get have HTTP/2, which means that while the number of bytes is important, so is the number of requests. If your app can get by with JUST jQuery, that doesn't matter. But if you need jQuery, plus two plugins, and lodash, and a promise polyfill, and...then all of a sudden your performance starts to be dominated by the number of requests being made, and (again) in real world situations you may see your effective load times improve if you concatenate your libraries.
The dream is "just list the libraries you need and let the browser sort it out super fast". The reality is a long way from it, and I don't think telling people "just use a CDN!" is currently good advice.
1. This cost is minimal, and most of the time will be served from cache anyway. I'd be willing to stake a claim that literally zero people ever have worried about the cost of serving jQuery when they weren't already worried about the cost of serving a bunch of other shit that eliminating just jQuery wouldn't fix.
2. This is completely undesirable, and doesn't happen anyway because you like to a specific version which does not change from under you.
The arguments in favor of hosting it on a CDN like googles are:
1) Clients who visit other sites will precache the file, so there is a chance they wont even need to load jQuery at all, and this can increase perf
2) Pushing some files to different domains can decrease load times because browsers can load files from multiple domains in parallel instead of serially like they would from one domain.
3) For smaller sites the google CDN is likely actually more dependable than your own. But if you've invested in a CDN this is no longer true.
> jQuery is ˜30k gziped and most likely already cached from CDN.
This part isn't so true in reality anymore, due to revised browser caching systems[1]. Doesn't mean you shouldn't use jQuery, just that part of the benefits of a centralized CDN are no longer a factor and it's a lot more sensible to self-host.
I wouldn't link to the Google CDN anyway, personally. If your whole site is hosted on your servers and then you add this because maybe some people won't have to reload JQuery, it just means google knows everybody who visits your site. Free analytics you don't get to benefit from.
No doubt Google considers it a best practice, because they are in the business of knowing what people do on the internet. How often will a browser get the jquery for a particular website or check with the CDN? There are a lot of jquery versions in use, the cache gets deleted (often on browser close) or expires, cache-age=0, etc. Almost always?
Besides providing jquery themselves, websites can use a CDN from another provider. OK, that might cost an extra 20 ms.
No, but I think the parent was making the case for combining everything into a single file (jQuery + app) which has benefits in reducing number of HTTP requests, especially important on mobile for example.
>> The point of a CDN is local distribution, not just load balancing.
Personally, I build web-apps for UK customers, and host in the UK, so this is a non-issue. I suspect the same is true for a lot of people building complex web-apps (i.e. apps complex enough that you should care about your build process).
>> You also get to share a cache with other sites; if you point to jQuery on Google's CDN, and the visitor has been to any other site using that CDN, they already have the file cached.
Not really true, they have to have hit another site that has uses that exact version of jQuery in order to have it cached. There was a study done recently that illustrated this was very unlikely. I wish I could link to it, but all I can tell you is Alex Sexton referenced it on the Shoptalk podcast [1].
Edit: Another commenter has now referenced the survey in question [2].
Can't you whitelist the specific jQuery library on Google's CDN though?
Serving widely used libraries out of a CDN is a best practice for a reason. Most visitors will already have it in cache. What alternative are you supposing? Local hosting? That has drawbacks, including more cache misses and increased bandwidth costs for the website provider.
> If you’re pulling jQuery in from one of the popular CDNs (which you should be), your clients will almost certainly already have it cached locally anyway.
Have you ever measured this on a large scale? I’ve never found it to be true because there are many CDNs, versions, and browser caches are not infinite. If performance is a priority it’s almost always faster to serve it directly to avoid things like the DNS and TLS latency from those CDN connections.
Thomas wasn't really discussing about this in regards to the external CDN going down he was discussing it in regards to the CDN being a large point of attack with little benefit to your speed increase.
Look at it this way: if google's jquery is attacked and becomes compromised you and everyone else who uses it has become compromised because you were relying on third party security.
Next if you use jquery from google's cdn for the reason of they can do file security better than you you are already fucked because if someone is targeting your specific jquery hosted on your server chances are you are compromised in other ways.
If you want to use it for the precaching you can but I don't think precaching the 100kb jquery is really going to give you that much benefit in the long run, especially if your website is an application or something along those lines.
True... but by pulling jQuery from Google's CDN for example, you theoretically save page-load time anyway. If multiple sites pull from the same CDN, then it's already cached in the user's browser.
Don’t forget that one of the advantages of CDNs is that the user may already have the file cached in their browser. This is why I use Google’s CDN for jQuery and CDNJS for everything else – more web sites use Google’s CDN for jQuery, so the user is more likely to have that cached. Not to mention the HTTP limitation of 3 simultaneous requests from one domain…
As long as you link the right files (make sure you specify the specific version and not use the one to give the lastest), there are very long expires headers and Google will have no idea the vast majority of your users ever visited. A user just needs to visit one site using the same version of Google hosted jQuery and they won't have to download it again when visiting another site.
> Hosting your own 23kb jQuery file does not cost that much. Actually practically nothing. Not in terms of bandwidth and neither in terms of perceived performance. Unless you are hosting your website on a 36.6kbps modem, host your own. Do the web some good.
People aren't using Google CDN for the cost, but for the performance. A high percentage of user will have the file cached already, so the performance gain is quite significant. Doubly so in a mobile environment.
reply