6,953 reasons why I still let Google host jQuery for me

http://encosia.com/2010/09/15/6953-reasons-why-i-still-let-google-host-jquery-for-me/

by Encosia • 16 years ago

122 67 16 years ago

Encosia11• 16 years ago

My original post about using Google's CDN to host jQuery generated a lot of discussion here, so I thought you might be interested in this one too.

endlessvoid943• 16 years ago

I ran into a problem with https -- will google allow me to securely reference their CDN?

seiji2• 16 years ago

Works for me: https://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.js

endlessvoid943• 16 years ago

damn, my solution was to host it locally. how did i blatantly not try this?

_delirium• 16 years ago

One thing that doesn't seem to have numbers, though I think the data would be sufficient to give them, is what the caching probability is like after taking the fragmentation into account. If I reference the Google CDN URL for jQuery 1.4.2, how many of the top 200,000 sites reference that? I assume it's rather less than the 6,953 that reference any version, but how much less?

Encosia11• 16 years ago

The split is about 50/50 right now. I've run the crawler three times in the last ~5 months and observed the transition from 1.3.2 to 1.4.2 moving along quite nicely though. After my first run, 1.4 adoption was so anemic that I was worried 1.3.2 was going to be jQuery's IE6. At this rate, it looks like 1.3.x should be a small minority by the time 1.5 rolls around.

il2• 16 years ago

I'm interested in the technology behind your crawler, you could potentially use it to discover many more things, like which sites use popular APIs etc. What language is it written in? What do you use for the backend/DB? How fast is it? I'm working on a project involving similar large scale crawling and I would love to know more.

spokey3• 16 years ago

You might be interested in http://trends.builtwith.com/

It doesn't give you a crawler or API, but they have done a lot of the analysis you're talking about and put it together in an explorable interface.

il2• 16 years ago

That site is nice, but they also want to charge me close to $2000 for a list of sites using a single technology, I could definitely do this myself for much less.

Anyone want to build a free version with me?

Encosia11• 16 years ago

It's a C# console application that logs to a SQL Server Express database. It's fairly primitive and the source isn't anything I'd want to advertise. I'd be happy to share it with you if you don't mind C# and want to give it a whirl yourself though.

spokey3• 16 years ago

It seems to me that unless the likelihood of a cache miss is fairly small you need to balance the probability of a cache hit against the expense of an extra HTTP call, as opposed to bundling the JQuery libraries directly with your custom JS with some JavaScript minimization trickery (and two HTTP calls if you're using both jquery and jquery-ui).

I have no doubt that the likelihood of a cache hit here is growing, but I wonder what the likelihood of an actual hit is? These data show that 4.7% of the top 1000 Alexa sites use some version of JQuery. What you'd need to consider is the likelihood that your visitor has (a) visited one of the those 47, (b) that is using the same version of JQuery as you are, and (c) has done it recently enough that the (relatively large) files are still locally cached. I suspect that for most sites that works out to much more than 4.7%, but is it more than 50%? If not aren't half of your users getting a slower response as a result?

(Moreover, and I don't know if or how this effects the JQuery CDN, but doesn't it seem like many sites drag because of delays in loading the Google Analytics JavaScript files? Wouldn't this pose an even greater problem if you're using Google to serve JQuery, since your UI depends upon it?)

MicahWedemeyer• 16 years ago

On the other hand, if you don't want to mess with minimization/packaging trickery, this gets you a nice quick win.

mike-cardwell7• 16 years ago

Where is the messing? Where is the hassle?

wget https://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.mi... -O main.js

cat local.js >> main.js

photon_off• 16 years ago

I started off using Google CDN to host my jQuery file, then later ditched it because about 20% of the time there would be a noticeable delay in retrieving it (if I'd cleared my cache).

There's really no reason not to just host jQuery yourself. Use GZip, and set a far-future expires header. Ensure the jQuery file is named by version, so that if you update the version the cached filename will be different. That's all you need to do, really.

One last note: The benefit of putting script tags at the bottom of the body is very similar to having the scripts cached in the first place. Just in case you didn't know, putting script includes at the bottom of the page lets the browser render the page progressively as it retrieves the HTML text [generally very, very quickly]. Scripts in the HEAD block rendering, as the browser needs to be load each script file sequentially, in case there are dependencies. [Note: not exactly true, it will grab several in parallel and execute them in order, but there's still a delay.]

Whether or not the scripts are cached, very fast page rendering will make the page appear to have loaded quickly. Likely, the user will not require javascript by the time the scripts are loaded anyway, if they aren't already cached.

mnutt• 16 years ago

Those are all good points, although as a different method you can offset some of the load time of putting scripts in the head tag by flushing the head as soon as possible:

http://yehudakatz.com/2010/09/07/automatic-flushing-the-rail...

(not a new idea, just new to rails)

_harry• 16 years ago

You can also speed up load time using LAB.js http://www.labjs.com

It loads and executes all scripts in parallel. Just be careful and hide any elements that rely on javascript before the scripts finish loading.

mike-cardwell7• 16 years ago

I'm not willing to hand over the security of my websites and privacy of my users to a third party, in exchange for my first page load to be fractionally shorter for a small number of my visitors.

Googles jQuery hosting is now a highly desirable target and I don't want to be included in the victims if it does get attacked. We learnt earlier this year how Google can be hacked.

Encosia11• 16 years ago

If Google's CDN were hacked (as unlikely as that is), it's almost certain that you'd find out about it far sooner than if your own server were hacked. There would be a huge controversy and then it would be quickly fixed, probably in the course of hours or minutes, just like with the Twitter CSRF issue this morning.

Conversely, the Internet is absolutely littered with compromised sites that have been modified to inject malicious scripts.

The situation is similar to Linus' Law.

mike-cardwell7• 16 years ago

Without using Googles CDN, they have to hack my website

With Googles CDN, they have to hack either my website, or Googles CDN.

Whichever you choose, it wont make any difference to how quickly you notice a local hack. Increasing the attack space doesn't make you more secure.

nphase• 16 years ago

I used to let Google host jQuery for me. And then one day their CDN went down for a large chunk of the midwest (where I live), and I noticed the render time of my site (and a few others) jump up anywhere between 5x and 100x.

That was the moment I resolved never to leave critical, blocking elements of any site I run into the hands of others, no matter how well known or reliable they are. (FWIW, this also includes ad network invocation scripts and similar, which always seem to be notoriously slow to load).

Encosia11• 16 years ago

I decided it's outside the scope of that post (which was already laboriously long winded), but you can/should use a fallback technique like this to mitigate the potential for Google downtime: http://weblogs.asp.net/jgalloway/archive/2010/01/21/using-cd...

Also, HTML5 Boilerplate has that built-in: http://html5boilerplate.com/

points2• 16 years ago

The fallback technique does nothing to mitigate the "It can connect but loading takes forever" case surely.

vog2• 16 years ago

This technique doesn't address the right problem, which might be a misunderstanding in statistics.

That is, no matter how reliable the other source (Google etc) is, it is still below 100%. If you host the JS on your own, your site becomes slow only if your server hangs. However, if you host the JS somewhere else, your site becomes slow whenever your server or the other server hangs. The probability of the latter is always greater than the former, i.e. you don't really gain anything.

So this trick slightly improves the good cases, but increases the likelihood of the bad cases. That kind of trade-off isn't desirable. Usually, people design trade-offs for the exact opposite: scarifying the speed of the normal case (which should be more than fast enough anyway) in order to decrease the probability of the worst case.

(BTW, this is true for almost all long-living projects. The opposite strategy makes only sense in "car racing" like situations where you either win fast, or lose everything. However, hardly any website is designed to live only a few weeks or so.)

lsb• 16 years ago

One of the major problems involved with using third-party login systems, like Facebook Connect, is exactly that: you need to make sure it's not critical (so you need your own login system anyway) and you need to make sure it's not blocking (which involves iframe shenanigans).

ciupicri2• 16 years ago

But aren't these kind of events pretty rare?

vog2• 16 years ago

As long as their probability is greater than 0%, they inevitably do more harm than good.

CWIZO• 16 years ago

HTTP errors – About 10% of the URLs I requested were unresolvable, unreachable, or otherwise refused my connection. A big part of that is due to Alexa basing its rankings on domains, not specific hosts. Even if a site only responds to www.domain.com, Alexa lists it as domain.com and my request to domain.com went unanswered.

At first, that may seem like an awful lot of potential error. However, the one thing all of these inaccuracies have in common is that none of them favor the case for using a public CDN.

I would have to disagree with the last paragraph there. I think that if one is so incompetent that his page is not available without the "www.", that there is a very strong chance that such person hasn't heard of a CDN. So domains that are not working without the "www." are, in my opinion, favouring the non CDN way.

estel2• 16 years ago

I've started to see some best-practice-if-you-ignore-user-expectation guides out there which say that allowing the domain to ignore the www is Not A Good Idea. I don't really know why this is the case, though.

eli2• 16 years ago

I've seen people worry that if incoming links are split between foo.com and www.foo.com, it will affect Google's ranking of your site.

I don't think this is true and, anyway, the right solution would be to redirect one to the other.

dtby• 16 years ago

if one is so incompetent that his page is not available without the "www."

Does this level of competence require that all services be provided on the root domain or just HTTP?

Encosia11• 16 years ago

To be clear, I did not adjust any of my numbers to include an extrapolated extra 10%. Any numbers you see in my post are based on direct observation of a script tag's src attribute.

misterbwong2• 16 years ago

The one reason we don't use Google's CDN for our public website: Some of our business users block sites by domain or IP, so they allow our site but block google's CDN. It's a PITA to get a rule added to a client's security setup.

joshuacc• 16 years ago

Do you know why they block Google's CDN?

misterbwong2• 16 years ago

I don't know their institutional reasoning, but I believe they are on a whitelist based system. They're not so much blocking Google as they are allowing us through.

Encosia11• 16 years ago

That's a scenario that the local-fallback technique handles well. The CDN reference will immediately fail for those overly-firewalled users, jQuery will be undefined in the next script block, and the fallback can detect that and inject a script element referencing a local copy instead.

jread• 16 years ago

Another option for using a CDN that will let you maintain better control and outage visibility, is to sign up for a paygo CDN account yourself. GoGrid and Speedyrails resell Edgecast CDN and Softlayer resells Internap CDN both of which are very good performing CDNs with both origin and pop pull models. The cost for these services would only be about $0.57 per 100k jQuery hits (assuming 24KB minified version is used).

Encosia11• 16 years ago

One of the biggest underlying benefits of using a shared, public CDN for this is that you can take advantage of cross-site caching. As more and more people use it, the potential for that is greater and greater.

However, it only works if sites are referencing exactly the same URL; just referencing the same file is unfortunately not good enough. So, using private CDNs like those don't confer quite the same benefit (though they're a great idea for hosting site-specific assets, of course).

redstripe• 16 years ago

I was playing around with the google map API one day when it started throwing very strange errors. Upon further investigation, I found the library URL was returning an html captcha page - not very useful to a browser expecting a javascript file.

Even google screws up simple stuff sometimes. So I think I'll pass on using their CDN for something as small as the jquery library. You're optimizing the wrong thing if you're worried about this.

6,953 reasons why I still let Google host jQuery for me

Related Stories