http://wordpress.org/extend/plugins/use-google-libraries/
Google’s hosted versions are all compressed, minimized, everything.
They’ve basically taken it upon themselves to optimize the hell out of these javascript libraries for the fastest possible hosting of them, with far-future expires headers and everything else.
Google code can be blocked due to the US embargo against Iran
5% of the time it’s far faster to roll up your own JS file, jsmin it, and gzip compress it to your users.
check to see if jquery has loaded, if not load a local version?
do this:
Because script elements block rendering until they’ve loaded and been executed, you can assume if jQuery isn’t present in the subsequent script block that it has failed to load from Google and then react accordingly.
this reference:
http://ajax.googleapis.com/ajax/libs/jquery/1.4/jquery.min.js
Is not a reference to 1.4, but the latest 1.4.x release. Since it would defeat the point of a “latest†reference to cache it for a year without requiring a 304 check, they use shorter expires headers on those.
Using this reference:
http://ajax.googleapis.com/ajax/libs/jquery/1.4.0/jquery.min.js
Supplies the +1 year expires header as expected.
Paul Irish has more info on that here: http://paulirish.com/2009/caching-and-googles-ajax-libraries-api/
This is a great article but when I try this approach the intellisense will not work. Is there a work around to fix that?
Assuming your code is in .js includes, download the vsdoc and place this at the top of your includes:
///
For Intellisense inline in ASPX pages, you can use this trick:
It will never be rendered to the page, but Visual Studio will still parse the file for Intellisense.
http://nitoprograms.blogspot.com/2010/02/jquery-hosted-on-googles-cdn-with.html
http://encosia.com/2010/09/15/6953-reasons-why-i-still-let-google-host-jquery-for-me/#comment-39896
http://encosia.com/2008/12/10/3-reasons-why-you-should-let-google-host-jquery-for-you/
Tremendous thanks to you for providing such useful information, ESPECIALLY why NOT to use the http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js reference to the latest version, e.g.
· Short expires header likely makes the CDN likely less optimal than serving jQuery from your own site
· Giving a third party permission to transparently change one of your site’s fundamental dependencies without your approval or interaction when a jQuery update occurs
· Breaks the Internet-wide caching benefit between your site and others, i.e. not priming other browser caches
For example, at the time of writing, this reference returns jQuery 1.4.2:
http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js
And, this reference returns jQuery 1.3.2:
http://ajax.googleapis.com/ajax/libs/jquery/1.3/jquery.min.js
You should never do this in production.
In order to insure that references to a “latest version†remain current when jQuery is updated, these requests are necessarily served with a very short expires header. Not only does this break the Internet-wide caching benefit between your site and others, the “latest version†reference’s short expires header likely even makes the CDN less optimal than serving jQuery from your own site!
Worse, you’re giving a third party permission to transparently change one of your site’s fundamental dependencies without your approval or interaction when a jQuery update occurs. This is not a good idea.
A notable offender here is jQuery.com itself. The site currently references the Google CDN for jQuery, but unfortunately references the “latest†1.4 version instead of 1.4.2 specifically. Not only is that slower than necessary for repeat jQuery.com visitors, but imagine how many browser caches they could be priming if they were referencing 1.4.2 specifically!
http://encosia.com/2010/09/15/6953-reasons-why-i-still-let-google-host-jquery-for-me/#comment-39896http://encosia.com/2008/12/10/3-reasons-why-you-should-let-google-host-jquery-for-you/Tremendous thanks to you for providing such useful information, ESPECIALLY why NOT to use the http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js reference to the latest version, e.g.· Short expires header likely makes the CDN likely less optimal than serving jQuery from your own site· Giving a third party permission to transparently change one of your site’s fundamental dependencies without your approval or interaction when a jQuery update occurs· Breaks the Internet-wide caching benefit between your site and others, i.e. not priming other browser caches
For example, at the time of writing, this reference returns jQuery 1.4.2:http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.jsAnd, this reference returns jQuery 1.3.2:http://ajax.googleapis.com/ajax/libs/jquery/1.3/jquery.min.jsYou should never do this in production.In order to insure that references to a “latest version†remain current when jQuery is updated, these requests are necessarily served with a very short expires header. Not only does this break the Internet-wide caching benefit between your site and others, the “latest version†reference’s short expires header likely even makes the CDN less optimal than serving jQuery from your own site!Worse, you’re giving a third party permission to transparently change one of your site’s fundamental dependencies without your approval or interaction when a jQuery update occurs. This is not a good idea.A notable offender here is jQuery.com itself. The site currently references the Google CDN for jQuery, but unfortunately references the “latest†1.4 version instead of 1.4.2 specifically. Not only is that slower than necessary for repeat jQuery.com visitors, but imagine how many browser caches they could be priming if they were referencing 1.4.2 specifically!