Jquery - link or host?

Steve

Just wondering what is considered better practice nowadays.

Hotlink to jquery vs host latest version locally?

I have a site about to go live soon (I don't do much web dev) in which I'm using a fair bit of jqurey and jquery easing to animate stuff in various places and I've used a hotlink to load the jq script.

<script src="https://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.min.js" type="text/javascript"></script>
/*..........*/
<script src="styles/jquery.easing.1.3.js" type="text/javascript"></script>

Is this opening the site up to future bugs when jq updates itself or is it safe?

Should I just host a 'known' version and rest assured that it will work?

Thanks for any help.

Giblet

Never hotlink the latest version, bugs have been introduced before and will again for sure. Using a CDN for a particular version is worth doing (which is what you're doing above) just use a protocol relative link ie: src="//ajax.googleapis.com..." etc. Place it at the end of your body element. Also, make sure you don't depend on it either, just in case it doesn't load and some other script throws errors.

Creamy Goodness

have the best of both worlds using the html5 boilerplate method of loading jquery. it first attempts to load from a CDN if that fails it falls back to a local copy of the same version of jquery.

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

http://html5boilerplate.com/

COYW

Personally, I always take the latest stable version and host it locally. As others have said, I would be worried about bugs in latest versions.

stevenmu

I thought/assumed that if you linked to a specific version that it would not change. If for e.g. you linked to version 1.7.1, and then a bug/whatever was discovered in it that they would create version 1.7.2 and leave 1.7.1 untouched?

GetWithIt

^
Me also

Giblet

It depends on the folder
http://ajax.googleapis.com/ajax/libs/jquery/1/jquery.min.js
Is always the latest,
http://ajax.googleapis.com/ajax/libs/jquery/1.7.1/jquery.js
Would be 1.7.1
http://ajax.googleapis.com/ajax/libs/jquery/1.6.2/jquery.min.js
Would be 1.6.2

Steve

Thanks for the replies, good advice there

So, the question arises, why hotlink at all?? does it load faster than hosting a known working version? what's the reason for it?

@Giblet, good point there about depending on it, site navigation is hampered if it fails to load so need to think about a fallback for when that happens.

@creamy, thanks for that link, will have a read. I'm coding in xhtml using Expression web 4 - I'm sorta new to this web dev stuff and trying to avoid html5 for now as EW doesn't really understand it yet - it's been forcing my hand though trying to include video content that will work on all browsers. I frikkin hate IE :mad:.

Giblet

A CDN would probably be faster than your own host in a lot of cases, it could also be cached already for some users (as other websites use the same file), plus, free bandwidth!

Also, <video> supports fallback content

Creamy Goodness

Steve wrote: »

So, the question arises, why hotlink at all?? does it load faster than hosting a known working version? what's the reason for it?

As Gib said, imagine facebook use google's CDN for jquery as you do. there's a pretty good chance that visitors to your site will have that version of jquery cached locally which in turn will speed up your page load times.

Steve wrote: »

@creamy, thanks for that link, will have a read. I'm coding in xhtml using Expression web 4 - I'm sorta new to this web dev stuff and trying to avoid html5 for now as EW doesn't really understand it yet - it's been forcing my hand though trying to include video content that will work on all browsers. I frikkin hate IE :mad:.

I definitely a good read, whilst it emcompasses a lot of html5, a lot of it is just best practices that are fully supported in html 4, for examples: resource protocol unaware i.e. //google.ie instead of http:// and loading all js at bottom of page to allow your content to load quicker.

stevenmu

I think it has changed in the latest browsers, but older browsers have pretty tight limits on the amount of concurrent connections they will make to one server. Hosting your resources across multiple servers lets them use more concurrent connections giving better download times.

Steve

Creamy Goodness wrote: »

and loading all js at bottom of page to allow your content to load quicker.

Forgive my ignorance here - I'm using the jquery function [HTML]$(document).ready(function(){......
[/HTML]
in <head> to initialise the plugins (a lightbox, carousel and nav bar script).. Are you saying these would be better at the bottom of each page? if so, where? last item before </body> or </html> ?

@stevenmu, I'm no expert, but,from what I've read there's still only two connections per overall page load which is why iframes are still slower than single page content.

I've figured out the <video> thing by loading a html5 page in an iframe - its a pain having to replicate each vid to mp4/ogg/webm with a mp4 quicktime <object><embed> as a final fallback but it seems to work in any browser & mobile device I have access to (besides blackberry - it plays but doesn't scale correctly - not losing sleep there yet).

Thanks again for all the pointers

Giblet

Those scripts aren't running until your page loads, they just take up time before the body content loads, so move your script elements to just before the closing </body> tag, including any $(document).ready stuff. It's not running until then anyway!

There are times when you will need stuff at the top of the page, but that's only when you need some settings to be set before the content loads, and this is usually the domain of feature detection, which usually only requires documentElement

Creamy Goodness

Steve wrote: »

Forgive my ignorance here - I'm using the jquery function [HTML]$(document).ready(function(){......
[/HTML]
in <head> to initialise the plugins (a lightbox, carousel and nav bar script).. Are you saying these would be better at the bottom of each page? if so, where? last item before </body> or </html> ?

@stevenmu, I'm no expert, but,from what I've read there's still only two connections per overall page load which is why iframes are still slower than single page content.

I've figured out the <video> thing by loading a html5 page in an iframe - its a pain having to replicate each vid to mp4/ogg/webm with a mp4 quicktime <object><embed> as a final fallback but it seems to work in any browser & mobile device I have access to (besides blackberry - it plays but doesn't scale correctly - not losing sleep there yet).

Thanks again for all the pointers

Again Giblet has gotten in before me (he's up too early to be a real programmer :pac:), but imagine a scenario where you have a 500Kb piece of code in a $(document).ready() and you load it in the <head>, the browser will download this first before anything in your <body> now it's not really such a big deal when everyone has fast connections on desktop but with the increase of smartphones and mobile internet connections have kind of become patchy again (try loading a site when on edge data connection). If the 500Kb of a $(document).ready() is near the bottom of your </body> then all your <body> content will load before the jquery is downloaded.

Placebo

brief summary of the 3 reasons for hosting it from google
http://encosia.com/3-reasons-why-you-should-let-google-host-jquery-for-you/

also you can use window.load instead of document.ready if you are concerned about your body content loading first, quick explanation: http://4loc.wordpress.com/2009/04/28/documentready-vs-windowload/