ansaurus

Question

Best way to use Google's hosted jQuery, but fall back to my hosted library on Google fail

Answer 1

A:

I wouldn't rely on a third party to host an important script, even if it is Google.

One reason: It is one more domain to have to resolve on your site.

Another reason: Google has had their share of downtime. They are not perfect, you know. Would you want your site being unusable because a third party stopped serving crucial files? I wouldn't.

Bryan Migliorisi 2009-06-18 17:54:52

That's why I asked the question. :-)

Nosredna 2009-06-18 17:58:39

Most people should already have Google.com pre-cached in their DNS tables. Resolving domains *shouldn't* be a concern anyway though since it is considered a good practice to use several domains on one page to speed up loading of your site anyway.

Dan Herbert 2009-06-18 18:02:05

An extra DNS lookup is actually negligible compared the the benefits of fetching a resource on a different domain (more http requests total) and most likely closer to the user (because Google has datacenters around the world).

Ryan Doherty 2009-06-18 18:03:02

Yes, but too many extra DNS lookups will cause a slowdown.

Nate Bross 2009-06-18 18:16:11

Based one what? Google's DNS will almost certainly be cached

micmcg 2009-06-19 05:16:41

Not only will Google's DNS most likely already be cached, but since many sites already use this file, the file itself has a higher chance of being in your browser's cache.

Amir 2010-01-25 20:19:57

spreading your downloads among multiple domains improves performance. web-browsers will make only up to 2 concurrent connections to single domain. that's why many websites are hosting resources on multiple domains (including stackoverflow.com) to overcome this limitation

lubos hasko 2010-04-19 22:09:15

@lubos - not related to Google's hosting which is likely to be cached, but spreading across domains is only beneficial up to a point because the DNS lookups do indeed take time. Only IE7 limits 2 connections per domain, newer browsers have higher limits. For IE7, Yahoo!'s research shows 2-4 (but not more) domains to be best: http://yuiblog.com/blog/2007/04/11/performance-research-part-4/

orip 2010-05-02 22:12:44

In South Africa if your international bandwidth is finished you can only browse local South African sites, if a site use the google/code even addsense and analytics it would cause your site to not display properly on a clients computer

Gerald Ferreira 2010-05-23 21:05:46

Answer 2

+132 A:

One more reason to not use Google-hosted jQuery is that in some countries, Google's domain name is banned.

But this is how you achieve it:

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js"&gt;&lt;/script&gt;
<script type="text/javascript">
if (typeof jQuery == 'undefined')
{
    document.write(unescape("%3Cscript src='/path/to/your/jquery' type='text/javascript'%3E%3C/script%3E"));
}
</script>

This should be in your page's <head> and any jQuery ready event handlers should be in the <body> to avoid errors (although it's not full-proof!).

Rony 2009-06-18 18:00:16

Yes. As in Iran. "I'm not saying Google is flaky. There are cases where the Google copy is blocked (apparently in Iran, for instance)."

Nosredna 2009-06-18 18:01:42

I assume you would want to write an alternate script tag in that document.write('') ?

John JJ Curtis 2009-06-18 18:02:12

This may not work because when the browser does the check for the jQuery object, it may be currently downloading the jQuery file and not done parsing it yet. Then you'll end up including it twice.

Ryan Doherty 2009-06-18 18:05:53

that's a nice point I am not sure how to force these steps to behave in a synchronous manner

Rony 2009-06-18 18:11:16

@Rony, yeah that's the trick.

Nosredna 2009-06-18 18:15:00

there must be some way in JavaScript to check the existence of a file and if it returns a 400 class status message then the local script can be downloaded, but I am not sure how that works it tried some examples but its not working for me

Rony 2009-06-18 18:34:10

@Rony, see my edited question. You can use google.load to load jQuery off Google's site. That might help forcing the problem into being synchronous.

Nosredna 2009-06-18 18:40:04

@Nosredna the problem with this in turn is that which file contains the google.load method, that is again hosted with google

Rony 2009-06-18 18:56:36

Couldn't you have a local version of google.load?

Nosredna 2009-06-18 19:00:09

yes you can copy the source from http://www.google.com/jsapi

Rony 2009-06-18 19:08:39

I believe that using a self hosted version of jsapi will make some Google services unusable. For example, ClientLocation.

Ionuț G. Stan 2009-06-18 19:16:54

In reference to making it synchronous: the fact that Google doesn't even attempt to address this issue in their typical jsapi include setup makes me think that it's not only extremely unlikely to be fixable, but also of minimal impact. (see http://code.google.com/apis/ajax/documentation/#GettingStarted - third code block)

Matchu 2009-06-22 01:28:38

Aren't javascript downloads blocking (synchronous) already? Seems to me the double-copy issue would therefore not be a problem.

Matt Sherman 2009-06-22 02:08:45

Javascript downloads should be synchronous already, as Matt Sherman said. Otherwise, many problems would occur if the page tried to execute an inline script that relied on a library that was only half downloaded, or a library extension was executed without the library fully downloaded and executed.That's also one reason why Yahoo YSlow recomends placing javascript at the end of pages; so that it doesn't block the downloading of other page elements (including styles and images). At the very least, the browser would have to delay execution to occur sequentially.

GApple 2009-06-24 20:16:42

Small fix from a validator fanatic: The string '</' is not allowed in JavaScript, because it could be misinterpreted as the end of the script tag (SGML short tag notation). Do '<'+'/script>' instead. Cheers,

Boldewyn 2009-06-26 08:13:48

This example will not work. 1) if Google ajax library is not available it'll have to time out first before failing. This may take a while. In my test of disconnecting my computer from the network it just tried and tried and tried and didn't timeout. 2) if (!jQuery) will throw an error because jQuery is not defined so Javascript doesn't know what to do with it.

RedWolves 2009-06-28 13:42:34

To test if jQuery was loaded, (!window.jQuery) works fine, and is shorted then the typeof check.

Jörn Zaefferer 2009-07-26 12:52:25

Still works great ^^

path411 2010-03-30 14:49:26

I think the expression is "fool-proof" but I could be making this up.

sova 2010-10-29 21:31:55

Answer 3

A:

You can test the effects of both coming through by including jquery twice in your website right now and seeing what that does.

DDaviesBrackett 2009-06-18 18:00:40

Answer 4

A:

I don't think you can do this reliably on the client side. One way to achieve this is to use a simple ashx handler to go download the google version and spit it out to your client side code.

In your ashx handler you can test the google version, if it happens to be down you can insert your own version from a file on your server. This way, you get the latest up-to-date version from google while having the ability to override and insert your own version.

Nate Bross 2009-06-18 18:20:21

Yeah, but that eliminates the advantage of the Google one likely already being cached on the client's machine (because so many sites are already using the Google one). I might as well not even use the Google one if I'm just going to pass it along instead of hand off the bandwidth to Google.

Nosredna 2009-06-18 18:22:37

I was only addressing the up-to-date version issue. You are correct this will not improve performance.

Nate Bross 2009-06-18 18:43:52

Yeah. Good point on the versioning. Although I always lock to a version I've tested with.

Nosredna 2009-06-18 19:00:48

Answer 5

+32 A:

This seems to work for me:

<html>
<head>
<script type="text/javascript" src="http://www.google.com/jsapi"&gt;&lt;/script&gt;
<script type="text/javascript">
// has the google object loaded?
if (window.google && window.google.load) {
    google.load("jquery", "1.3.2");
} else {
    document.write('<script type="text/javascript" src="http://joecrawford.com/jquery-1.3.2.min.js"&gt;&lt;\/script&gt;');
}
window.onload = function() {
    $('#test').css({'border':'2px solid #f00'});
};
</script>
</head>
<body>
    <p id="test">hello jQuery</p>
</body>
</html>

The way it works is to use the google object that calling http://www.google.com/jsapi loads onto the window object. If that object is not present, we are assuming that access to Google is failing. If that is the case, we load a local copy using document.write. (I'm using my own server in this case, please use your own for testing this).

I also test for the presence of window.google.load - I could also do a typeof check to see that things are objects or functions as appropriate. But I think this does the trick.

Here's just the loading logic, since code highlighting seems to fail since I posted the whole HTML page I was testing:

if (window.google && window.google.load) {
        google.load("jquery", "1.3.2");
    } else {
        document.write('<script type="text/javascript" src="http://joecrawford.com/jquery-1.3.2.min.js"&gt;&lt;\/script&gt;');
    }

Though I must say, I'm not sure that if this is a concern for your site visitors you should be fiddling with the Google AJAX Libraries API at all.

Fun fact: I tried initially to use a try..catch block for this in various versions but could not find a combination that was as clean as this. I'd be interested to see other implementations of this idea, purely as an exercise.

artlung 2009-06-22 01:15:06

What is the advantage of using google.load in this situation, rather than loading ajax.googleapis.com/ajax/libs/jquery/1.3.2/jquery.min.js directly, like Rony suggested? I guess loading it directly catches issues with removed libraries as well (what if Google stops serving JQuery 1.3.2). Furthermore, Rony's version notices network problems AFTER www.google.com/jsapi has been fetched, especially when jsapi has been loaded from cache? One might need to use the google.load callback to be sure (or maybe there's some return value to include the google.load in the if(..)).

Arjan 2009-06-27 08:32:57

If one is testing for the presence of Google.com, one could make a network call, or one could check for the presence of the "gatekeeper" object. What I'm doing is checking for the google object and its "load" function. If both of those fail, no google, and I need the local version. Rony's version actually ignores the www.google.com/jsapi URL entirely, so I'm not sure why you indicate that it will have been fetched.

artlung 2009-06-27 15:26:06

Arjan 2009-06-27 18:45:16

ah, I see how I caused the confusion. "Rony's version notices network problems AFTER www.google.com/jsapi has been fetched" should better read: "Your version does not notice network problems AFTER www.google.com/jsapi has been fetched".

Arjan 2009-06-27 18:47:30

We've recently switched to using Google as our jQuery host; if we get any bug reports from blocked users, I'll be using a variant of your answer to refactor our client code. Good answer!

Jarrod Dixon 2009-07-26 07:45:43

Answer 6

+8 A:

There are some great solutions here, but I'll like to take it one step further regarding the local file.

In a scenario when Google does fail, it should load a local source but maybe a physical file on the server isn't necessarily the best option. I bring this up because I'm currently implementing the same solution, only I want to fall back to a local file that gets generated by a data source.

My reasons for this is that I want to have some piece of mind when it comes to keeping track of what I load from Google vs. what I have on the local server. If I want to change versions, I'll want to keep my local copy synced with what I'm trying to load from Google. In an environment where there are many developers, I think the best approach would be to automate this process so that all one would have to do is change a version number in a configuration file.

Here's my proposed solution that should work in theory:

In an application configuration file, I'll store 3 things: absolute url for the library, the url for the js api, and the version number
Write a class which gets the file contents of the library itself (gets the url from app config), stores it in my datasource with the name and version number
Write a handler which pulls my local file out of the db and caches the file until the version number changes.
If it does change (in my app config), my class will pull the file contents based on the version number, save it as a new record in my datasource, then the handler will kick in and serve up the new version.

In theory, if my code is written properly, all I would need to do is change the version number in my app config then viola! You have a fallback solution which is automated, and you don't have to maintain physical files on your server.

What does everyone think? Maybe this is overkill, but it could be an elegant method of maintaining your ajax libraries.

Acorn

Acorn 2009-06-26 17:02:10

If you're doing all that work *just* for jQuery, then I'd say it is overkill. However, if you already have some of those components in place for other pieces of your app (e.g. if you already load scripts from a DB) then it looks pretty nice.

Michael Haren 2010-01-19 13:28:24

Answer 7

A:

This is just a thought, but could you maybe include the jQuery serverside? So, you have a serverside file called jQuery.php/jQuery.aspx/jQuery.asp (whatever server side language you use). Then you just include that file in your head in a script tag like so ... <script type="text/javascript" src="jQuery.php"></script>. Inside your server side javascript file you could do an http request to Google to get their copy of jQuery and if the http request fails you get your own copy. Then you only have it included once and you get your failover. Thoughts?

Fred Clown 2009-07-27 16:08:00

There is no benefit to this method over hosting JQuery by yourself. The main reason to use Google's JQuery is that people have it cached already in their browser, so no download at all is required. In this case, the browser would have to cache your server-side script, since it's coming from your domain.

zombat 2009-08-11 22:16:44

Yeah, that's true. I was thinking too hard I guess and over-thought it to the point of failure.

Fred Clown 2009-08-24 18:50:44

Yeah, it defeats the whole purpose. Good thinkin tho

Jonah 2010-04-22 18:32:51

Answer 8

A:

Don't use it! Why give Google all that precious data for free?

AnApprentice 2010-03-20 19:57:21

My first reaction was: Duh! Then I mulled it over and discovered that you are right but I am afraid not in the sense you mean... :-) Nosredna's clients are giving their IP addresses AND their Google cookies (!) to Google when they surf to Nosredna's web site and therefore with the referrer Google can know who uses Nosredna's web site.

nalply 2010-04-03 08:39:34

Sneaky little Google.

Jonah 2010-04-22 18:31:33

is it for free, when you let Google pay the traffic for the API hosting?

BerggreenDK 2010-05-09 21:51:45

ansaurus

tags:

views:

answers:

Best way to use Google's hosted jQuery, but fall back to my hosted library on Google fail

related questions