Hosting Your Own JavaScript Scripts Files (Other Than Jquery) on Fast Free Cdns Like Google

Which is better: public javascript CDN or self-hosted combined javascript?

If using only 1-2 libraries, a good practice is too include the CDN version, with a fallback to local version. This is the practice that most HTML boilerplates/frameworks use .e.g .

http://html5boilerplate.com/

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.8.3/jquery.min.js"></script>
<script>window.jQuery || document.write('<script src="//myserver/js/libs/jquery-1.8.3.min.js"><\/script>')</script>

However,you are using a lot of libraries, so there might be dependencies, and specific ordering of them on the page, and some of them might not be present on standard CDNs,so you will have to anyway include some of your javascripts from your server.
Hence for your case, a better bet would be to use good combining/versioning of all your javascript code into 1-2 files .e.g one for libraries(usually not touched), and one for your own custom code(cache busted when you make changes to it).

Lightweight JS Library vs Google-hosted CDN

jQuery is not heavy as compared to any other javascript library at present looking at the amount of features and browsers it supports.

You can consider this factor while selecting the plugins to be used on the page because they are written by various users and some may right it intelligently considering this factor or some may just right it for the sake.

Yes, if you use CDN like Google for jQuery it is most likely that the library must be cached by the browser and also Google has number of servers based on location so you don't have to worry about it.

Is using a CDN for jQuery (or other static files/scripts) really a good idea?

Two part answer:

  • You shouldn't be seeing 304s
  • But is it a good idea?

You Shouldn't Be Seeing 304s

I understand that when I visit many sites using, say, jQuery from Google's CDN, it will have to "download" the script only once for a very long time, but my browser still tries to connect to the Google's server, and ask for the script file, and then receive 304 not modified status code.

It shouldn't, not if it's respecting the Cache-Control header:

Cache-Control:public, max-age=31536000

...which says from the date on the resource, the browser can cache it for up to a year. No need for any HTTP request at all (and that's what I see in Chrome unless I force it, no request at all, just a note saying "from cache"; fired up Firefox and made sure Firebug was on for all pages, came to StackOverflow for the first time in a long time with Firefox [which I only use for testing], and sure enough, it didn't issue any request for jquery at all).

E.g., maybe it takes 200ms for a 304 response, but if your browser is caching correctly, it'll be 0ms for a load-from-cache.

The full set of relevant headers I see on a forced request are:

Cache-Control:public, max-age=31536000
Date:Wed, 17 Aug 2011 21:56:52 GMT
Expires:Thu, 16 Aug 2012 21:56:52 GMT
Last-Modified:Fri, 01 Apr 2011 21:23:55 GMT

...so my browser shouldn't have to request that path again for nearly a year.

See @Dave Ward's comment below: To get max caching results, use the full release number, e.g.:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js'></script>
<!-- very specific ---^^^^^ -->

rather than

<script src="//ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js'></script>
<!-- very generic ----^ -->

Okay, but is it a good idea?

That's entirely up to you. Even with a fallback like this:

<script src="//ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js'></script>
<script>
if (typeof jQuery === "undefined") {
document.write("<scr" + "ipt src='/my/local/jquery.js'></scr" + "ipt>");
}
</script>

...or similar, the UX if the CDN is down is going to be awful. The browser is going to spin for ages trying to connect to it. That kind of fallback will only help if the CDN quickly replies with a failure, which is unlikely.

This means if Google's CDN goes down, you would have to quickly adjust what you're serving to use your local copy instead. So defending against that becomes a monitoring exercise (of Google's servers; don't overdo it or they'll be displeased) with a failover at the server level to start serving pages with a local path. (Or a Microsoft path, on the theory that Google and Microsoft probably aren't sharing underlying CDN technology, given how well they get along.)

For me, the answer for most sites is probably: Go ahead and use the CDN, react if and when Google's CDN for libraries goes down. The flip side is: If you're happy with your overall page load performance loading it from your server, little harm in doing that until or unless traffic is high enough that you're looking to eke every last bit of performance out of things. But lots (and lots and lots) of sites rely on Google's CDN, if it goes down, your site will be far from alone in failing...

Should I use a hosted version of JQuery? Which one?

One advantage would be that a user may already have it cached since another site also linked to a 3rd party.

I've been using google for this and haven't experienced any problems with it so far.
You can easily load jQuery using:

<script type="text/javascript" src="http://www.google.com/jsapi"></script>
<script type="text/javascript">
google.load("jquery", "1.4");
</script>

Streaming jquery(JS files) from a CDN (Google)

Consider that a jQuery script downloaded from the google CDN might well already be cached on a visitor's browser, since it has consistent headers and cache control no matter where it is downloaded from. Hence, on average most users will only have to download your site-specific javascript scripts. Also, CDN generally have faster response times than single servers, since they respond from a server nearest to your location.

There is no cut and dry answer to your question, as both approaches offer good performance on modern connections. You should profile your system under duress and see what solution offers the best results (and if such optimization is even needed).



Related Topics



Leave a reply



Submit