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

16

241

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.

Towboat answered 13/2, 2009 at 19:43 Comment(1)
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.Ludwigg
U
152

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>
Underclothing answered 13/2, 2009 at 20:12 Comment(10)
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>Incubus
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 itBitner
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?Underclothing
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.Towboat
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.Ludwigg
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.Underclothing
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.Brumbaugh
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.Refrigerator
@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.Portraitist
What is meant by jQuery not supporting SSL? I see HTTPS being used for jQuery's CDN - see links on code.jquery.com.Nikko
M
19

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.

Midvictorian answered 13/2, 2009 at 19:58 Comment(1)
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.Avernus
P
14

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.

Purkey answered 13/2, 2009 at 19:47 Comment(3)
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...Underclothing
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.Authoritarian
unless your website is absolutely tiny, 18k will always be a tiny fraction of your traffic.Refrigerator
G
14

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>
Grille answered 13/2, 2009 at 19:57 Comment(5)
Using HTTPS because the site is HTTPS, so kinda have to.Towboat
All your content is https based, or only some of it?Underclothing
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.Dwayne
The site where the code came from is completely SSL--extremely secure contact information.Towboat
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.Refrigerator
S
8

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.

Smothers answered 13/2, 2009 at 23:7 Comment(6)
I put user experience (fast load times) right up there with less dependencies.Underclothing
@Smothers 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 slowBitner
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? ;-)Underclothing
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 sameSmothers
nah, we aren't being harsh, just some good old fashion ribbing... ;-)Underclothing
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.Refrigerator
A
6

Pros: Host on Google has benefits

  • Probably faster (their servers are more optimised)
  • They handle the caching correctly - 1 year (we struggle to be allowed to make the changes to get the headers right on our servers)
  • Users who have already had a link to the Google-hosted version on another domain already have the file in their cache

Cons:

  • Some browsers may see it as XSS cross-domain and disallow the file.
  • Particularly users running the NoScript plugin for Firefox

I wonder if you can INCLUDE from Google, and then check the presence of some Global variable, or somesuch, and if absence load from your server?

Authoritarian answered 13/2, 2009 at 20:36 Comment(1)
It is Firefox's cons, not Google's ,.)Hindrance
D
6

There are a few issues here. Firstly, the async load method you specified:

<script type="text/javascript" src="https://www.google.com/jsapi"></script>
<script type="text/javascript">
  google.load('jquery', '1.3.1');
  google.setOnLoadCallback(function() {
    // do stuff
  });
</script>

has a couple of issues. Script tags pause the page load while they are retrieved (if necessary). Now if they're slow to load this is bad but jQuery is small. The real problem with the above method is that because the jquery.js load happens independently for many pages, they will finish loading and render before jquery has loaded so any jquery styling you do will be a visible change for the user.

The other way is:

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

Try some simple examples like, have a simple table and change the background of the cells to yellow with the setOnLoadCallback() method vs $(document).ready() with a static jquery.min.js load. The second method will have no noticeable flicker. The first will. Personally I think that's not a good user experience.

As an example run this:

<html>
<head>
  <title>Layout</title>
  <style type="text/css">
    .odd { background-color: yellow; }
  </style>
</head>
<body>
<table>
  <tr><th>One</th><th>Two</th></tr>
  <tr><td>Three</td><td>Four</td></tr>
  <tr><td>Five</td><td>Six</td></tr>
  <tr><td>Seven</td><td>Nine</td></tr>
  <tr><td>Nine</td><td>Ten</td></tr>
</table> 
<script src="http://www.google.com/jsapi"></script>
<script>
  google.load("jquery", "1.3.1");
  google.setOnLoadCallback(function() {
    $(function() {
      $("tr:odd").addClass("odd");
    });
  });
</script>
</body>
</html>

You (should) see the table appear and then the rows go yellow.

The second problem with the google.load() method is that it only hosts a limited range of files. This is a problem for jquery since it is extremely plug-in dependent. If you try and include a jquery plugin with a <script src="..."> tag and google.load() the plug-in will probably fail with messages of "jQuery is not defined" because it hasn't loaded yet. I don't really see a way around this.

The third problem (with either method) is that they are one external load. Assuming you have some plugins and your own Javascript code you're up to a minimum of two external requests to load your Javascript. You're probably better off getting jquery, all relevant plug-ins and your own code and putting it into one minified file.

From Should You Use Google's Ajax Libraries API for Hosting?:

As to load times, you're actually loading two scripts - the jsapi script and the mootools script (the compressed version from above). So that is two connections, rather than one. In my experience, I found that the load time was actually 2-3 times slower than loading from my own personal shared server, even though it was coming from Google, and my version of the compressed file was a couple of K larger than Google's. This, even after the file had loaded and (presumably) cached. So for me, since the bandwidth doesn't matter much, isn't going to matter.

Lastly you have the potential problem of a paranoid browser flagging the request as some sort of XSS attempt. It's not typically a problem with default settings but on corporate networks where the user may not have control over which browser they use let alone the security settings you may have a problem.

So in the end I can't really see me using the Google AJAX API for jQuery at least (the more "complete" APIs are a different story in some ways) much except to post examples here.

Dwayne answered 13/2, 2009 at 22:10 Comment(1)
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.Towboat
C
4

In addition to people who advices to host it on own server, I'd proposed to keep it on separate domain (e.g. static.website.com) to allow browsers to load it into separate from other content thread. This tip also works for all static stuff, say images and css.

Colvert answered 13/2, 2009 at 20:22 Comment(0)
F
4

I have to vote -1 for the libraries hosted on Google. They are collecting data, google analytics style, with their wrappers around these libraries. At a minimum, I don't want a client browser doing more than I'm asking it to do, much less anything else on the page. At worse, this is Google's "new version" of not being evil -- using unobtrusive javascript to gather more usage data.

Note: if they've changed this practice, super. But the last time I considered using their hosted libraries, I monitored the outbound http traffic on my site, and the periodic calls out to google servers were not something I expected to see.

Furmenty answered 13/2, 2009 at 20:30 Comment(4)
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...Underclothing
But its Cached for 1 year - are we even sending a 304 "File changed" to Google in the meantime?Authoritarian
Yeah, I've seen those periodic calls back to Google as well (Safari's activity manager has a nice list).Towboat
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.Furmenty
M
3

I might be old-school about this, but I still frown on hotlinking. Maybe Google is the exception, but in general, it's really just good manners to host the files on your own server.

Mulish answered 13/2, 2009 at 19:47 Comment(2)
What do you mean by "good manners?" Google encourages you to link to their server. It's pumped out by Google's incredible infrastructure.Pickaninny
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/ajaxlibsBitner
H
3

I will add this as a reason to locally host these files.

Recently a node in Southern California on TWC has not been able to resolve the ajax.googleapis.com domain (for users with IPv4) only so we are not getting the external files. This has been intermittant up until yesterday (now it is persistant.) Because it was intermittant, I was having tons of problems troubleshooting SaaS user issues. Spent countless hours trying to track why some users were having no issues with the software, and others were tanking. In my usual debugging process I'm not in the habit of asking a user if they have IPv6 turned off.

I stumbled on the issue because I myself was using this particular "route" to the file and also am using only IPV4. I discovered the issue with developers tools telling me jquery wasn't loading, then started doing traceroutes etc... to find the real issue.

After this, I will most likely never go back to externally hosted files because: google doesn't have to go down for this to become a problem, and... any one of these nodes can be compromised with DNS hijacking and deliver malicious js instead of the actual file. Always thought I was safe in that a google domain would never go down, now I know any node in between a user and the host can be a fail point.

Honeysucker answered 26/6, 2015 at 19:44 Comment(0)
H
2

I just include the latest version from the jQuery site: http://code.jquery.com/jquery-latest.pack.js It suits my needs and I never have to worry about updating.

EDIT:For a major web app, certainly control it; download it and serve it yourself. But for my personal site, I could not care less. Things don't magically disappear, they are usually deprecated first. I keep up with it enough to know what to change for future releases.

Henandchickens answered 13/2, 2009 at 19:47 Comment(4)
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.Mcminn
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.Woolson
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.Underclothing
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...)Loam
A
2

Here some useful resource, hope can help you to chose your CDN. MS has recently add a new domain for delivery Libraries trough their CDN.

Old Format: http://ajax.microsoft.com/ajax/jQuery/jquery-1.5.1.js New Format: http://ajax.aspnetcdn.com/ajax/jQuery/jquery-1.5.1.js

This should not send all cookies for microsoft.com. http://www.asp.net/ajaxlibrary/cdn.ashx#Using_jQuery_from_the_CDN_11

Here some statistics about most popular technology used on the web across all technology. http://trends.builtwith.com/

Hope can help you to choose.

Admeasure answered 29/3, 2011 at 11:54 Comment(0)
D
1

If I am responsible for the 'live' site I better be aware of everything that is going on and into my site. For that reason I host the jquery-min version myself either on the same server or a static/external server but either way a location where only I (or my program/proxy) can update the library after having verified/tested every change

Dissipation answered 13/2, 2009 at 21:50 Comment(2)
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??Authoritarian
Google should never change the file if you ask for a specific version.Towboat
B
0

In head:

  (function() {
    var jsapi = document.createElement('script'); jsapi.type = 'text/javascript'; jsapi.async = true;
    jsapi.src = ('https:' == document.location.protocol ? 'https://' : 'http://') + 'www.google.com/jsapi?key=YOUR KEY';
    (document.getElementsByTagName('head')[0] || document.getElementsByTagName('head')[0]).appendChild(jsapi);
  })();

End of Body:

<script type="text/javascript">
google.load("jquery", "version");
</script>
Bookplate answered 16/2, 2010 at 12:28 Comment(0)
S
0

I host it with my other js files on my own server, and, that's that point, combine and minify them (with django-compresser, here, but that's not the point) to be served as just one js file, with everything the site needs put into it. You'll need to serve your own js files anyway, so I see no reason to not add the extra jquery bytes there too - some more kbs are much more cheaper to transfer, than more requests to be made. You are not dependent to anyone, and as soon as your minified js is cached, you're super fast as well.

On first load, a CDN based solution might win, because you must load the additional jquery kilobytes from your own server (but, without an additional request). I doubt the difference is noticable, though. And then, on a first load with cleared cache, your own hosted solution will probably always be much faster, because of more requests (and DNS lookups) needed, to fetch the CDN jquery.

I wonder how this point is almost never mentioned, and how CDNs seem to take over the world :)

Suttles answered 21/11, 2017 at 15:14 Comment(0)

© 2022 - 2024 — McMap. All rights reserved.