Why you should let Google host jQuery for you
encosia.com
encosia.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.
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.
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.
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...
(questions are 80% rhetorical, 20% genuine curiosity)
It did not happen for very long (a few minutes each time), and not often, but it has happened.
Routers are configured by people, and people make mistakes.
He's not claiming that Google is infallible. I'm more confident in their ability to maintain availability than yours. All of this paranoia about Google going down is mostly FUD.
OTOH if your site is down, it's fully down - no partial content, and javascript errors.
I wouldn't say this whole issue is FUD though. For instance I would not want to depend on four different even high quality third party sites for each request to my website because the likelyhood of failure would be (almost) five times as high.
I don't know enough about JS to say, but you might be able to do if(!$loadedvar){document.whatever.write("<script src=\"...\" />"); }; as well
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).
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.
The goal is speed, not tracking.
1. A cookie would be a waste of bytes.
2. Since the headers instruct your browser to cache it for 10 years, it's quite likely that you won't even hit their server on the second page that uses this file.
Don't believe me? Check for yourself:
curl -I http://yui.yahooapis.com/2.6.0/build/yahoo/yahoo-min.jsI 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.
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.
They just care that your page works and loads fast.
You are a vanishingly small minority.
Is changing the URL slightly enough to circumvent this?
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.
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.)
Perhaps I'm being paranoid, but I do not want to rely on ANY external providers - not even when it's Google.
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.
In practice, I would think the chances of Google's entire CDN going down are the very least of your worries though.
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.
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 :)