views:

110

answers:

2

I've been doing a little JavaScript (well, more like jQuery) for a while now and one thing I've always been confused about is where I should put my scripts, in the <head> tag or in the <body> tag.

If anyone could clarify this issue, that'd be great. An example of what should go where would be perfect.

+7  A: 

Best practices from google and yahoo say that, for performance, javascript should always be put in an external file, and linked to your page with a <script> tag located at the bottom of the html, just before the closing of the <body> element.

This allows the browser to render the entire page right away, instead of stopping to evaluate javascript.

Eduardo Scoz
The problem with this is that a "functionless" page is rendered. BTW, is it a coincidence that we both have the same rep? (1666)
George Edison
Re: 'functionless': your page should still work without JS. And it will probably only be a 1/2 second to a second between page render and JS evaluation (hopefully).
Ryan Doherty
This was what I was wondering about. If for some reason I put my JavaScript in my `<head>` tag, would it have a difference compared to me putting it at the beginning of a `<body>` tag?
NessDan
No, you can load script from either the body or head elements. Just be careful because the sooner you load the script, the sooner it'll block your page from loading.
Eduardo Scoz
+6  A: 

You mentioned three places:

  1. In tags;

  2. In the HTML; and

  3. In an external file.

Let me address each of those.

Best practice is to have common Javascript in one or more external files and the less files the better since each JS file loaded will block loading of the page until that JS file is loaded.

The word "common" is extremely important. What that means is you don't want to put page-specific Javascript code in that external file for caching reasons. Let's say you have a site with 1000 pages. Each page has JS code specific to it. That could either be 1000 different files or one really big file that executes a lot of unnecessary code (eg looking for IDs that aren't on that particular page but are on one of the 999 others). Neither of these outcomes is good.

The first gives you little caching boost. The second can have horrific page load times.

So what you do is put all common functions in one JS file where that JS file only contains functions. In each HTML page you call the JS functions needed for that page.

Ideally your JS files are cached effectively too. Best practice is to use a far futures HTTP Expires header and a version number so the JS file is only loaded once by each browser no matter how many pages they visit. When you change the file you change the version number and it forces a reload. Using mtime (last modified time of the JS file) is a common scheme, giving URLs like:

<script type="text/javascript" src="/js/script.js?1233454455"></script>

where that mtime is automatically generated. Your Web server is configured to serve JS files with an appropriate Expires header.

So that mixes external files and in-page scripts in (imho) the best way possible.

The last place you mentioned was in the tag. Here it depends somewhat on what JS libraries and frameworks you use. I'm a huge fan of jQuery, which encourages unobtrusive Javascript. That means you (hopefully) don't put any Javascript in your markup at all. So instead of:

<a href="#" onclick="doStuff(); return false;">do stuff</a>

you do:

<a href="#" id="dostuff">do stuff</a>

with Javascript:

$(function() {
  $("#dostuff").click(doStuff);
});
cletus
You mean `$('#dostuff').click(doStuff);` based on your HTML. =) Thanks for a great description!
Jeff Rupert
@Jeff I do indeed! Fixed, thanks for that.
cletus
I've actually done more work with PHP then JS and when you described in the beginning, the act of keeping important functions in a single file, it reminded me of how I organize my PHP functions - like that!When I write my jQuery code, it's never inside of my tags. My real question was pretty much where should I keep my `<script src="file.js">` tags in the code.
NessDan