Where do you include the jQuery library from? Google JSAPI? CDN?

Question

There are a few ways to include jQuery and jQuery UI and I'm wondering what people are using?

• Google JSAPI
• jQuery's site
• your own site/server
• another CDN

I have recently been using Google JSAPI, but have found that it takes a long time to setup an SSL connection or even only to resolve google.com. I have been using the following for Google:

<script src="https://www.google.com/jsapi"></script>
<script>
google.load('jquery', '1.3.1');
</script>

I like the idea of using Google so it's cached when visiting other sites and to save bandwidth from our server, but if it keeps being the slow portion of the site, I may change the include.

What do you use? Have you had any issues?

Edit: Just visited jQuery's site and they use the following method:

<script type="text/javascript" src="http://ajax.googleapis.com/ajax/libs/jquery/1.3/jquery.min.js"></script>

Edit2: Here's how I've been including jQuery without any problems for the last year:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.4.3/jquery.min.js"></script>

The difference is the removal of http:. By removing this, you don't need to worry about switching between http and https.

Solution 1

Without a doubt I choose to have JQuery served by Google API servers. I didn't go with the jsapi method since I don't leverage any other Google API's, however if that ever changed then I would consider it...

First: The Google api servers are distributed across the world instead of my single server location: Closer servers usually means faster response times for the visitor.

Second: Many people choose to have JQuery hosted on Google, so when a visitor comes to my site they may already have the JQuery script in their local cache. Pre-cached content usually means faster load times for the visitor.

Third: My web hosting company charges me for the bandwidth used. No sense consuming 18k per user session if the visitor can get the same file elsewhere.

I understand that I place a portion of trust on Google to serve the correct script file, and to be online and available. Up to this point I haven't been disappointed with using Google and will continue this configuration until it makes sense not to.

One thing worth pointing out... If you have a mixture of secure and insecure pages on your site you might want to dynamically change the Google source to avoid the usual warning you see when loading insecure content in a secure page:

Here's what I came up with:

<script type="text/javascript">
    document.write([
        "\<script src='",
        ("https:" == document.location.protocol) ? "https://" : "http://",
        "ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js' type='text/javascript'>\<\/script>" 
    ].join(''));
</script>

UPDATE 9/8/2010 - Some suggestions have been made to reduce the complexity of the code by removing the HTTP and HTTPS and simply use the following syntax:

<script type="text/javascript">
    document.write("\<script src='//ajax.googleapis.com/ajax/libs/jquery/1.2.6/jquery.min.js' type='text/javascript'>\<\/script>");
</script>

In addition you could also change the url to reflect the jQuery major number if you wanted to make sure that the latest Major version of the jQuery libraries were loaded:

<script type="text/javascript">
    document.write("\<script src='//ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js' type='text/javascript'>\<\/script>");
</script>

Finally, if you don't want to use Google and would prefer jQuery you could use the following source path (keep in mind that jQuery doesn't support SSL connections):

<script type="text/javascript">
    document.write("\<script src='http://code.jquery.com/jquery-latest.min.js' type='text/javascript'>\<\/script>");
</script>

Solution 2

One reason you might want to host on an external server is to work around the browser limitations of concurent connections to particular server.

However, given that the jQuery file you are using will likely not change very often, the browser cache will kick in and make that point moot for the most part.

Second reason to host it on external server is to lower the traffic to your own server.

However, given the size of jQuery, chances are it will be a small part of your traffic. You should probably try to optimize your actual content.

Solution 3

jQuery 1.3.1 min is only 18k in size. I don't think that's too much of a hit to ask on the initial page load. It'll be cached after that. As a result, I host it myself.

Solution 4

If you want to use Google, the direct link may be more responsive. Each library has the path listed for the direct file. This is the jQuery path

<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.3.1/jquery.min.js"></script>

Just reread your question, is there a reason your are using https? This is the script tag Google lists in their example

<script src="http://www.google.com/jsapi"></script>

Solution 5

I wouldn't want any public site that I developed to depend on any external site, and thus, I'd host jQuery myself.

Are you willing to have an outage on your site when the other (Google, jquery.com, etc.) goes down? Less dependencies is the key.

View more solutions

Comments

[Josh Smith]

Darryl, great edit. Might I suggest you move your edit up to the top of the page and change the src to the simpler/safer/faster syntax you use now? Your answer has become basically canonical and both changes would help people get what they came for quickly.

[Jason Miesionczek]

i was found that method to be kinda dangerous, what if a code change in the library breaks your site? or the jquery site goes down? i'd rather have complete control over the file.

[Chris J.]

Also, I hate to hit the jQuery folks' bandwidth like this. They already provide a really cool free tool, and I'd hate for them to go down because of bandwidth costs. Better to use Google as your external source if you don't want to host it yourself, since they are providing it for that purpose.

[penetra]

Using HTTPS because the site is HTTPS, so kinda have to.

[Kip]

another reason- odds are users already have jquery from google in their cache, so they might not even need to download it the first time they visit your site.

[Veggivore]

I respectfully disagree, based on your stated reason. If you get a lot of traffic then the 18k per session can quickly add up to a sizable amount of traffic. Especially if your web hosting charges by the bandwidth used...

[Veggivore]

I would recommend switching over to use Google instead of JQuery. The main reason is that Google would likely have many more servers around the world than JQuery and from my experience more people use Google hosting which increases your chance they already have it cached.

[Veggivore]

All your content is https based, or only some of it?

[Veggivore]

But are you already running Google Analytics on your site? Since I am I don't suppose it makes much difference whether the JQuery comes from Google or not, they probably already know I am running it on my site...

[Kristen]

But its Cached for 1 year - are we even sending a 304 "File changed" to Google in the meantime?

[Nosredna]

What do you mean by "good manners?" Google encourages you to link to their server. It's pumped out by Google's incredible infrastructure.

[penetra]

Yeah, I've seen those periodic calls back to Google as well (Safari's activity manager has a nice list).

[Kristen]

I would hope that Google will never change the file - for bug-fixes they will host a new file, with different version number in filename. Or am I being naive? will they rollout "Minor fixes" using the same filename??

[Lordn__n]

http links on https sites are annoying because IE (at least by default) bugs you with annoying "This site contains a mixture of secure and insecure content." confirmation boxes.

[penetra]

Google should never change the file if you ask for a specific version.

[penetra]

I haven't experienced any of the issues you mention. Just loading things in the right order will solve pretty much everything as far as i understand.

[Aaron Wagner]

I agree with all three of your reasons which is why I include jquery from Google on my production sites. Instead of the the js dynamic injection for SSL pages I just reference url in a script tag without the protocol specified. Seems to work fine for me. <script src="//ajax.google..."></script>

[Veggivore]

I put user experience (fast load times) right up there with less dependencies.

[jeroen]

I agree with Jason, automatically switching to a newer version is very dangerous. Perhaps not as much if you only use jquery, but with plugins I definitely don´t recommend it. I for one use a plugin on one site that works with 1.2.6 but not 1.3.x (yet...)

[aruno]

there is definitely a confusion at first when you hear about using google. but as nosredna said it is encouraged "We take the pain out of hosting the libraries, correctly setting cache headers, staying up to date with the most recent bug fixes, etc." - code.google.com/apis/ajaxlibs

[aruno]

until someone at Google maliciously messes with the jquery file or google DNS ... ;-) probably not going to work if you're a bank but everyone else should go for it

[aruno]

@slacy hey your site is down! actually jk, but i did notice you're using google analytics and have their script at the beginning instead of the end - which will slow your site down fractionally if google IS being slow

[Veggivore]

Interesting idea... But if you're going to use DNS poisoning to hijack the JQuery load why not just hijack the the whole site request? Or how about the Google Analytics script?

[Veggivore]

hmm...slacy is using Google Analytics? Didn't he just say that he wouldn't want any public site that he developed to depend on an external site? ;-)

[jro]

Dscoduc - yep, using Analytics. At least with that implementation, I understood ahead of time that I was giving up usage data. Not so with the JS libs.

[slacy]

Wow, dudes, some harsh comments there. :) Yes, I do use Analytics on my personal blog, but that's not a production site that generates revenue, so I think it's really just fine. I'm sure my site is down for many days per year. Remember, what you do for personal sites and for work aren't the same

[Veggivore]

nah, we aren't being harsh, just some good old fashion ribbing... ;-)

[Kristen]

My view is that is only of a concern if your visitors only look at one page. If your profile is fewer visitors & multiple page-views, then minimal overhead when spread across page-views per visitor. Ditto for returning visitors.

[penetra]

I also agree with everything, except to simplify things, I use the this format: <script src="//ajax.google..."></script>. Then I don't need to worry about http or https. Thxs Aaron Wagner for that.

[Josh Smith]

Dscoduc: I think your answer deserves an update with Aaron and Darryl's simplification. Their version is quite simply easier to read, quicker to load, and safer. And this page seems to have become one of the canonical answers for including jQuery from Google.

[Veggivore]

While I agree with the 'easier to read' portion, I don't see how removing the http/https from the code makes it any more quicker or safer to load... But in any case I have updated the comment to reflect the option.

[vol7ron]

I don't see what document.write() is being used? a simple <script src="..."></script> is fine to place in the header. →@Dscoduc:← it's not going to be quicker, it's just going to take that warning message away. If your site is using secure https and you're pulling from an non-encoded content (eg http://googleapis) then you'll get that warning message. What will be a little quicker if you're only using http but you're linking to https://googleapis, there's a little overhead with the "secure" encoding. Thus, linking to http://googleapis would be a little faster.

[Nakilon]

It is Firefox's cons, not Google's ,.)

[Hans-Christoph Steiner]

Also keep in mind that Google will then use this to track the websites that users go to. So if you are making a website that needs to be conscious of privacy, then hosting a couple of small files is a small price to pay for privacy.

[Hans-Christoph Steiner]

There are other good reasons to use the local copy: Google is frequently blocked in many countries like Iran, China, etc. So that means well over a billion people won't have access.

[Hans-Christoph Steiner]

unless your website is absolutely tiny, 18k will always be a tiny fraction of your traffic.

[Hans-Christoph Steiner]

If you care at all about the security of your users, always use HTTPS for javascript. Without HTTPS, it is quite easy to man-in-the-middle (MITM) those requests and serve exploits along side the javascript that you intend to send to people. Think public wifi, hacked home routers, etc. as possible MITM locations. Look at all those pwn-to-own competitions: they always exploit the browser to get in.

[SF.]

@vol7ron: In case you use //googleapis..., you don't need to worry about choosing between http and https - the browser does it for you. That makes the whole document.write() part obsolete.

[flow2k]

What is meant by jQuery not supporting SSL? I see HTTPS being used for jQuery's CDN - see links on code.jquery.com.