8 ms·
Why you should let Google host jQuery for you
- akie 18y ago1 reason why not to: loss of control. Perhaps I'm being paranoid, but I do not want to rely on ANY external providers - not even when it's Google.
- teej 18y agoIf you're really that paranoid, monitor and verify. If there are issues, you can change hosting optins. You don't mitigate risk by doing everything yourself.
- ars 18y agoWhat? How are you supposed to monitor and verify that google is up from the point of view of the client? If you do it locally it's either fully working, or fully down, and you don't have javascript errors when parts work and parts don't.
- Encosia 18y agoIf you're worried about Google's reliability, you could always test for typeof(jQuery) !== 'undefined' before assuming it had loaded. Then, you can inject a script element referencing a copy of jQuery on your server if it hadn't. In practice, I would think the chances of Google's entire CDN going down are the very least of your worries though.
- ars 18y agoThat's quite an interesting idea, but I'd be worried about it running too soon, the browser doesn't give you a "gave up on downloading something" event. Google goes down more than you think - it's not usually that google itself is down, but rather that DNS didn't look them up, or some anoying routing issue. It's happened to me, so I know it does happen.
- jonknee 18y agoDo you provide your own internet bandwidth? You have to rely on external providers at some point and in all likelihood Google is better at keeping the lights on than you are.
- akie 18y agoTrue, Google is probably better at keeping their servers up... but I prefer to reduce my external dependencies anyway. Right now, I only have to rely on my hosting partner - which means I'm dependent on just ONE party. If something goes wrong, I call 'em and kick their lazy asses :) Chances are that things are up and running in no time. Remember when Amazon's cloud storage went offline last July? This meant all kinds of websites relying on that service were offline as well. No-one knew what was happening, why it was happening, and when it would be back online. I don't need that - seriously :)
- wvenable 18y agoIf course you could mirror all your resources locally and quickly switch over if Google were to go down.
- streety 18y agoI've never really understood that argument. Assuming that your site is totally down when your server goes down and that you rely on jquery so heavily that loosing it essentially renders your site unusable it doesn't seem to matter how much better google is at delivering content than you are. If you can manage an uptime greater than 50% the likelihood is that your server and google will be down at different times so the downtime is additive.
- jbert 18y agoI think the argument is that google is an order of magnitude or so better at downtime than you are, so any google-created downtime is lost in the noise.
- ErrantX 18y agoAnd extension of this theory is hosting your static content on Google App Engine. (aka cheap CDN for initial stage of a startup!)
- tdupree 18y agoI have been using Google App Engine as a CDN to serve up images and some core js, as well as using Google Ajax Library to serve up MooTools for about 5 or 6 months now. It has worked out really really well. In our case, we needed to serve our clients with our in house servers running ESRI's ArcGIS server. Splitting the load between Google and our Arc servers cut the load time in half for some cases.
- ckinnan 18y agoThe cool idea in this is that universal libraries like jquery basically become locally cached...no download needed even if it is the first time they hit your site.
- bk 18y agoIt would be even cooler if this were done by comparing a hash of the library's remote and local copy, so it could be on any server and not bound to the same domain.
- patio11 18y agoI hope it is a cryptographically secure hash that STAYS cryptographically secure. Otherwise ten years down the road someone will figure out a way to force collisions and then, bam, you'll be running l33tcrew.ru's copy of Prototype with the access privileges of bankofamerica.com . No problem fixing that one, all you have to do is roll out a patch to every standards-compliant browser in the world, oh, yesterday would have been good.
- iigs 18y agoOr specify the hash type you'd like to see at the point you invoke the script. It can't retroactively protect pages that were published with the insecure hash, but it certainly would allow the author to update their site upon awareness of a hash vulnerability.
- Tichy 18y agoI don't want to provide user stats for my site to Google for free. Granted, if the user has the library already cached, I suppose Google sees nothing, but still. Maybe HTML should be extended so that together with <link> tags you can state a hash of the content, so that the browser could recognize identical files. (Would be a bit dangerous, though).
- ovi256 18y agoIt's not like you don't already use Google Analytics, right?
- IsaacSchlueter 18y agoChances are, they're not tracking it. In fact, I'd be extremely surprised if they were. You can use YUI hosted by Yahoo's CDN. We don't track those statistics because the data is simply overwhelmingly large and not very useful even if you could parse it. The goal is speed there, not data. And, as you mention, many users will have it cached. Their cache headers invalidate the data anyhow, making that data not just expensive to gather, but completely worthless.
- Tichy 18y agoWhy is the data not useful? If any content comes from Google, I suppose the Google cookie comes with it. And then you have a history of pages a user visits. Doesn't Yahoo do the same (only with a Yahoo cookie)?
- 18y ago
- patio11 18y agoFor folks interested in his #2 benefit (using multiple domains causes static assets to be loaded in parallel, speeding up observed speeding page load times) -- you can capture it without involving Google in the slightest. It requires a perhaps two-line tweak to your web server configuration files to make it answer requests on domains other than www.example.com For example, my main domain is www.bingocardcreator.com . There are some honking images which load on the front page that used to block the (more valuable to my conversion pathway) images on the sidebar from popping up. I reconfigured my webserver to accept images1 through images4 as acceptable host names, and (lazily) manually split the static assets over the 5 hosts. This actually resulted in improving the loading of my sidebar by upwards of a second. That is worth, oh, probably $100 a month or so. (If you do not know how I can possibly say this, you owe it to yourself to try CrazyEgg right now.) Not bad for an hour's work that never has to get repeated. Credit given where credit is due: I found this tip out through using Yahoo's YSlow plugin for Firefox, and following their "Best Practices for Speeding Up Your Website". This document is one of the best practical "Here, do this, it will make you money" sources I have ever found on the Internet. http://developer.yahoo.com/performance/rules.html http://developer.yahoo.com/performance/rules.html
- showerst 18y agoThis is a tip that I've also used to great effect, but I thought that I should point out (if it isn't obvious) that you must make sure the same image always points to the same subdomain (image 1 is always linked to images1.mysite.com) otherwise you'll shoot yourself in the foot by eliminating browser caching. I usually write a quick function in $language to turn the first few letters of the filename into ASCII then modulus by the number of fake subdomains that I've set up to decide which server to link to. The overall distribution may be imperfect but file x will always be linked to server x across pages, so it's a nice quick solution, especially if you have multiple maintainers.
- ars 18y agoI've thought about this, but I decided against it for one simple reason: if google is down my site is in trouble. By serving it locally it's all or nothing, either your site works (because it's up), or it doesn't. But if the site is up, but google is down it's will do really bad stuff. Plus I don't really understand the multiple connections issue - what about HTTP/1.1 and keep alive? Doesn't it download everything all in one go, but only if it's all one server? And finally about the caching issue - sure the first time might not be cached, but most sites rely on people visiting more than once, or at least clicking on more than one page, so it'll be cached the rest of the time after that. So none of the arguments are really holding with me.
- Encosia 18y agoHTTP 1.1 helps streamline multiple downloads in sequence, but doesn't help with the issue of concurrent download limits imposed by the browser. Loading a few complex pages while watching something like Firebug's Net panel helps make that clear. You'd be surprised about how many users hit your site with less cached than you'd hope: http://yuiblog.com/blog/2007/01/04/performance-research-part-2/ http://yuiblog.com/blog/2007/01/04/performance-research-part...
- jsmcgd 18y agoHow often is Google down? Is it worth worrying about? (questions are 80% rhetorical, 20% genuine curiosity)
- ars 18y agoGoogle doesn't usually go down, but routing issues or DNS problems mean that it does happen that they are unreachable.
- tsetse-fly 18y agoHow often are there routing issues to Google, but none to your site? It's much more likely that your site will be unreachable. The probability that Google will be down is probably insignificant for most cases.
- nostrademons 18y agoSure, if JQuery's the only JavaScript file on the page. But if you use multiple plugins that depend upon JQuery, you're usually better off concatenating them all into one file, minifying that, and GZipping the content. You'll get slightly better compression than if you serve them separately, and don't need to worry about multiple HTTP requests.
- gommm 18y agoYes but you lose the benefit of the cache of jquery.min.js some people may already have when loading the first page of your site (the most important time for performance)
- nostrademons 18y agoTrue, but they're not going to hit the cache anyway for the plugins, so download time will still be slow.
- jobenjo 18y agoYUI has been doing the same thing (hosting their JS professionally), and it does really make sense. We've been doing this for years at fluther.com and it's worked out great. We have a switch for using a local copy when we're offline (on an airplane), but in general it adds speed and saves bandwidth. This was always a nice benefit of YUI, and I'm glad to see there's an option with JQuery, too. (I'm planning to switch at some point--we went with YUI in the first place because it had the only stable autocomplete plugin but that's long since changed.)
- simonw 18y agoIf you're already serving your other assets from a separate domain (which is a very good idea - and if you use a separate domain rather than a subdomain you can be sure you won't have any cookies included in incoming HTTP requests, speeding things up even further) then it might be better to serve jQuery from your own asset server, to save the additional DNS lookup. Worth benchmarking, anyway.
- briansmith 18y agoThis isn't a good idea. I use noscript and I rarely will let it load 3rd-party Javascript. The more times I have to click "temporarily allow ..." the more i hate your site. As a user, I don't like every site telling Google what I'm doing. Google is becoming the panopticon of the internet. Forcing users to load content third-party content is a sign that you don't respect their privacy. IE8 in private browsing mode will block 3rd-party scripts that are referenced from more than 10 (by default) sites. This includes all this Google stuff and Google Analytics.
- tdupree 18y agoAs we serve local, county, and state governments using a subscription model, we don't run into the problem of random visitors with noscript enabled when viewing the site, but I can see how that would affect other sites. As a side note, you can tie the CDN you create with Google App Engine to a domain, i.e. cdn.yoursite.com grabs from the App engine CDN.
- axod 18y agoI think you're a statistical anomaly.
- IsaacSchlueter 18y agoHow many users have even heard of NoScript or know what "3rd-party Javascript" is? They just care that your page works and loads fast. You are a vanishingly small minority.
- trevelyan 18y agoOut of curiosity, do you purchase subscriptions to digital products or services on the Internet?
- tlrobinson 18y ago"IE8 in private browsing mode will block 3rd-party scripts that are referenced from more than 10 (by default) sites. This includes all this Google stuff and Google Analytics." Is changing the URL slightly enough to circumvent this?
- tlrobinson 18y agoI think it's unlikely you'll see increased parallelism usually. All but the newest browsers (IE8, Safari 4, FF 3.1) wait until they encounter script tags before they download them, rather than looking ahead to download multiple scripts in parallel. http://stevesouders.com/ua/ http://stevesouders.com/ua/
- PStamatiou 18y agoand CloudFront the other JS libraries your site must use.. http://paulstamatiou.com/2008/12/08/how-to-getting-started-with-amazon-cloudfront http://paulstamatiou.com/2008/12/08/how-to-getting-started-w...
- tptacek 18y agoThis is a terrible idea if the security of your site matters, because you're loading Javascript off an untrusted, unsecure source.
- jmtame 18y agoAnswer: it's faster