I have had this question niggling at the curious bit of my mind for a while now and I thought I'd ask your collective expertise for an answer to this question.
To elaborate on the title, say I have this:
alert("Some JS outside ");
Outside the <head></head> tags of my HTML file. My question is whether it's ok to do this or not, and how much it is used like this.
My instincts tell me it's ok - I reckon browsers look through all HTML for <script> tags and interpret it when they see it, so it should be ok, but I'm not all that great with how browsers work.
I'm looking for a definitive (or as close as possible to definitive) answer here - is it fine to do, or not?
EDIT: To save me posting this a bunch of times, I'll say it once here. Thanks very much for all your input people. Up votes to you all! I will have to re-train myself to put JS at the bottom of pages - now that I think about it it's blindingly obvious that scripts at the bottom of the page is way better than the top. Thanks for your help everyone.
Best place for your script tags is before your closing body tag.
<html>
<head>
<title>Example</title>
</head>
<body>
Your Content
<script type="text/javascript" src="yourScriptHere.js"></script>
<script type="text/javascript">//Inline scripts etc.</script>
</body>
</html>
That said they can be other places without a problem however the reason you want them at the end is that you want to ensure the page has loaded before execution and you also do not want to stall client download progress making them wait on large scripts.
Yes, <script> blocks outside the <head> are fine.
In fact many encourage placing them at the end of the <body>. Placing them just before </body>, defers fetching/loading until after the page content...to speed up the render.
From the W3C HTML4 spec:
The SCRIPT element places a script within a document. This element may appear any number of times in the HEAD or BODY of an HTML document.
Yes. Its OK. Infact, very often it is necessary. In many cases, you may have some long-loading (read: large download) javascript that is not critical to the page, so you want the rest of your page content to load first, so you put the <script> for that javascript at the bottom of the <body> section.
A script in the body of your document will be executed when it is encountered. If it's a function, then "executing it" simply means defining the function, i.e. adding it to the list of known functions. But if it's not a function, if it's a block of stand-alone statements, they will be executed where encountered.
For example, if you wrote:
<html><head>... whatever ...</head>
<p>Foo
<script>
document.write("bar")
</script>
<p>Plugh
</html>
The browser will display:
Foobar
Plugh
This may or may not be what you want.
Related
I have a simple Javascript function that can be placed anywhere within HTML document. So I put it right below the closing , for example:
<html>
<body>
Some text.
<script>
document.getElementsByTagName('body')[0].innerHTML='hello';
</script>
</body>
</html>
My question is - would it make sense (from page load speed point of view) to load this script via the addEventListener("load") function instead? Ie. if I use this code below - which would be preferred? I understand that when Javascript is on the bottom of the page, it won't 'block' page rendering anyway, so using the addEventListener may only slow the execution down?
<html>
<body>
Some text.
<script>
window.addEventListener("load",function()
{document.getElementsByTagName('body')[0].innerHTML='hello';},
false);
</script>
</body>
</html>
Scripts should generally not be placed directly in the HTML like that, because they block further HTML parsing until they're executed. While it's not a problem if you have only one script, what if you have two, or three, or more, and some of them might take more than a handful of ms to parse?
Still, assuming that blocking isn't an issue, there's no real difference on way or the other, from the UX point of view.
Scripts, being information about how to interact with the content, but aren't actually content themselves, belong in the <head> IMO. If you don't like wrapping everything in a load listener, you can use the defer attribute to automatically run the script once the whole HTML has been parsed: <script src="..." defer>.
Apologies for the dumb sounding question, but I need the experts to clarify.
Out of the three places to put JavaScript, head, $(document).ready, or body, where would the best place be to put some ajax that uses a lot of $GET functions?
For instance I am using a JavaScript function called execute_send() but I am unsure where the best place to put it would be. Below is the error:
Problem at line 67 character 22: 'execute_send' was used before it was defined.
function execute_send() {
Also how does the placement affect the page loading time?
In general, unless for some reason you need it elsewhere, put all of your JS last in the body. The browser won't continue until it's parsed your JS, so it is nice to let the page load first. See http://developer.yahoo.com/performance/rules.html
As an example of when you might actually want to put JS in the head: You might have some A/B testing code that you want to run before the page even renders - in that case, the code should go in the head, because you really do want it to run as soon as possible.
As #Thom Blake said, in general the best place is at the bottom of the <body> (+1 for that) - but I'll expand on that a bit:
The reason for this is that as the browser loads the page, it has to stop loading and parse the JavaScript when it encounters it. So if you have all your scripts in the <head> for instance, there will be a delay in loading all the content in the <body>
Note that this is a delay in loading - separate from the actual execution of the script. Something like $(document).ready() deals with when the script is executed, not with when it is loaded.
Generally, all this matters because you want a web page to feel as responsive as possible, so a best practice list for JavaScript will usually be along these lines:
Place all your scripts at the bottom of the <body> so that the loading of non-JS resources, such as images, is not delayed.
Combine your scripts into a single file, so that the server has to make fewer requests for resources (you'll see this referred to as "minimizing HTTP requests")
Minify you scripts, to reduce their total size, which speeds up loading times
Put any code reliant on the DOM (eg click handlers, HTML manipulation, etc) inside $(document).ready() (or the equivalent method for the JS library in use on the page).
Same subject : whats-pros-and-cons-putting-javascript-in-head-and-putting-just-before-the-body
In the past, i experienced some jquery problems has it was not 'loader' when initialising .. this is why we decided to insert it in the <head>.
In some situations it's not easy to move scripts to the bottom. If, for example, the script uses document.write to insert part of the page's content, it can't be moved lower in the page. There might also be scoping issues. In many cases, there are ways to workaround these situations.
For the rest of javascripts, all before the closing </body> tag.
To explain the 'Why page will load faster' : It wont.
Browsers are single threaded, so it’s understandable that while a script is executing the browser is unable to start other downloads. But there’s no reason that while the script is downloading the browser can’t start downloading other resources. And that’s exactly what newer browsers, including Internet Explorer 8, Safari 4, and Chrome 2, have done.
The difference is visible has your ressources within the <body> tag will load/show sequencialy. When the browser gets to load <script src=...js> the complete file has to be loader before the browser can fetch another ressource. So, it's an illusion, because the browser will load/di more 'visible' content before 'javascripts'.
To visualise the whole thing : firebug > Net (tab)
As stated before, $(document).ready is not a place. (For jQuery, $(document).ready simply ensures that the DOM is fully loaded (ready to manipulate) before any script is executed.) You would place your JavaScript in the <head> or the <body>.
However, putting all of your JavaScript includes and JavaScripts at the bottom of the <body> section is best for loading performance. "Progressive Rendering" and "Parallel Downloading" are blocked for everything below the scripts. If your scripts are the last thing on the page, you're not blocking anything.
This article explains it in more depth.
Example:
<html>
<head>
<!-- MY HEAD CONTENT - LOAD ALL CSS -->
</head>
<body>
<!-- MY HTML CODE -->
<!-- START javascript -->
<script type="text/javascript" src="/ajax/jquery/jquery-1.6.2.min.js"></script>
<script type="text/javascript" src="/ajax/jquery/plugins/jquery.random_plugin.js"></script>
<script type="text/javascript" src="/includes/some_other_scripts.js"></script>
<script type="text/javascript" language="JavaScript">
//<![CDATA[
$(document).ready(function(){
// my jQuery/JavaScript code
});
//]]>
</script><!-- END javascript -->
</body>
</html>
NOTE: I am in no way advocating multiple heads within a page
I'm using Apache Tiles and I have a few tiles that include their own heads. The result of the Tiles renders into an HTML page with multiple heads.
My questions:
How is the resulting page handled in IE and Chrome? [It renders and appears successful]
WITH APACHE TILES What is the best practice for dealing with/avoiding multiple heads [for CSS/Javascript] without having to demand all pages use the same JS and CSS files.
For Example with Question Two:
Lets say you have the following pages: home, profile, and gallery listing. Gallery listing has fancy JQuery+YUI+... and more styles. For most users, they would only be interested in the home and profile pages, so why slow them down with loading the JS and CSS files associated with Gallery.
This is what is generated
<html>
<head>
<title>The Template's Title</title>
</head>
<body>
<head> <script src="javascriptfile.js"/></head> Tile One Content
<head> <script src="javascriptfile2.js"/></head> Title Two Content
</body>
</html>
The generated contents is running the script in javascriptfile.js, and javascriptfile2. What I'm asking in the first question: is the extra heads ignored, and the contents considers? are they combined into the html/head level? Is it possible to include CSS files in the second or later head? Will this create an error with a stricter DTD?
Well, in modern Chrome, it's at least possible to know what happens. Chrome uses the HTML5 parser algorithm which describes exactly how invalid mark-up is processed. The gory details are at http://dev.w3.org/html5/spec/tree-construction.html#parsing-main-inbody
What happens in your example is that the first <head> in <body> is discarded. Then the <script src="javascriptfile.js"/> tag is processed, which is a start tag, not a self-closing tag, so everything that follows, including everything that looks like a tag, becomes a text child of the script element. Nothing is displayed and no script is run. If <script src="javascriptfile.js"/> is replaced by <script src="javascriptfile.js"></script>, and ditto for <script src="javascriptfile2.js"/>, the head start and end tags are silent discarded, and the script elements are not moved. "Tile One Content Title Two Content" is displayed and the scripts are run. The DTD makes no difference at all.
IE is somewhat trickier to know, as before IE10, it doesn't use the HTML5 parser algorithm and therefore it's exact behaviour is a mystery. However, a cursory experiment appears to show that it has the same behaviour as described above.
Although some legacy browsers move elements that can only appear in the head - such as <link> - into the head, other browsers do not, and no such behaviour can be relied upon.
All in all, best steer well clear of such constructs.
I don't know about practices for Apache Tiles.
What is the purpose of doing something so egregiously invalid? And why you're asking this seems very unclear.
Not only should you only have ONE <head></head> section on a page, under no circumstances is the <head></head> to be nested anywhere inside the <body></body> section.
This practice makes absolutely no sense whatsoever....
(Side-note: Certain browsers ignore or move invalid tags when the DOM is constructed which will defeat your entire purpose of doing this.)
EDIT (based on comments):
For anyone interested in including <script> tags within the <body>, you can read more about the specific details in my answer here...
Will linking javascript files in the body rather than in the header cause a problem?
You don't really need extra heads to include additional css/js. You can 'inline' the whole <style type="text/css">...</style> part and it will render fine. Will it validate? No. But will run fine.
How is the resulting page handled in IE and Chrome? [It renders and appears successful]
I don't know and I really don't want to know.
What is the best practice for dealing with multiple heads [for CSS/Javascript] without having to demand all pages use the same JS and CSS.
Don't do it :-)
Is there a reason you can't just include the JS files in the body / head without the extra tags?
Or add the css / js files in the 'normal' head section of the document (where it should be).
Well atleast you want the CSS files to be loaded as soon as the page starts loading. JS files can (sometimes) be loaded at the end of the HTML.
For example if the JS files need to have a completely loaded DOM (for e.g. accessing DOM elements).
Note
Sorry this isn't really an answer to your question, however what you are doing just looks way bad. :) And is almost certainly not needed / there will be a better solution for it.
If you have JS code which is intended to run as part of loading/building the page, where in the HTML should this go? For instance modifying a <div> or adding some links.
Should this be put in the <body>, interspersed with HTML? Or should it be between the <head> and <body> elements? What order do things happen in - the order they are in the page or does HTML all happen before (non-<head>) JS is run?
If you have JS code which is intended to run as part of loading/building the page, where in the HTML should this go?
Just before the closing </body> tag is emerging as the best practice barring a specific requirement for it to be elsewhere (which there can sometimes be). It's the recommendation of the YUI folks, for instance, but it's not just them.
What order do things happen in - the order they are in the page or does HTML all happen before (non-) JS is run?
When a script tag is encountered, unless you use the defer or async attribute (and the browser supports them), all HTML parsing comes to a screeching halt and the script is downloaded and handed to the JavaScript interpreter. When the JavaScript interpreter finishes processing the script, the HTML parser can continue. It has to do this because the JavaScript can insert tokens into the HTML stream via document.write. This is also why you can load a script file and then load a second script file that relies on the first, and know that they'll get loaded in the right order. It's also why you can't access elements that are further down in the HTML stream from a script higher up in it unless you defer your code somehow (window.onload or the "DOM loaded" events many libraries support, such as jQuery's ready or Prototype's dom:loaded).
An upshot of this is that the typical practice of putting script tags in the head actually slows down the apparent load time of the page, unless those script tags need to be there for some reason. Hence the recommendation to put them just before the closing </body> tag.
There's a "gotcha" you have to watch for, though: If you have parts of the page that you want to respond to with JavaScript if the user has it enabled, loading your script at the very end leaves a brief but real race condition lying around: The user can interact with the page while your script is being downloaded. There are a variety of ways of handling that. My favorite is to detect whether JavaScript is enabled with inline script (not a separate file) in the head element and, if so, to put in a document-level handler for things where possible (you can do this with click events, for instance) which basically queues up or disables the click during that very brief period of time. That way, if JavaScript is enabled, you'll avoid the race condition, but if it isn't, any unobtrusive fallback you have in place will work.
The whole HTML file is executed in the order it is written, that means
<html>
<div id="ID"></div>
<script type="text/javascript">
document.getElementById('ID').innerHTML = "HELLO";
</script>
</html>
changes the contents of the div, wherease
<html>
<script type="text/javascript">
document.getElementById('ID').innerHTML = "HELLO";
</script>
<div id="ID"></div>
</html>
does not, because the JS code is executed before the div has loaded.
EDIT: If you want the JS to run after the page has loaded use window.onload or document.body.onload or
<body onload="...">
Alternatively if you're using a JS library such as jQuery, you can use
$(document).ready(function() {
...
});
Put them as functions in its own .js file which you include by <script src> at end of HTML <head> or <body>. If any of them needs to be executed during document load, call it using window.onload or whatever load function the JS library/framework offers, if you are using any.
As to the exact location, putting them in end of <head> allows them to be downloaded before the HTML page is been shown in browser and putting them in end of <body> allows the page to be shown a tad sooner because downloading the scripts will block the page rendering, thus it's a better speed experience.
However, IMO, it's a bit more robust to have the scripts downloaded before the page is rendered whenever you have some page elements which cannot be used without JS. In case of an impatient user this would otherwise lead to unusable elements.
I'd put it in a separate .js file and wrap the code so it is executed after the DOM is loaded. If you use a framework like jQuery or Prototype this should be easy.
For best performance place your JavaScript files at the BOTTOM of the HTML page you are serving.
To ensure that everything is set when you try to use it, execute only after the DOM is ready (there are multiple variations of this, my advice: Use a JavaScript Library).
You can put a script tag in the head, body, between the two, and more. You can put it most places but see this for a more in depth look.
I was reading a tutorial and the author mentioned to include JavaScript files near the closing body tag (</body>) in HTML.
For what type of functionality should I not declare/define JavaScript include in the head section? It makes sense to me include JavaScript like Google Analytics near the closing body tag. Where should I be careful in defining JavaScript include near the closing body tag?
It will often be argued that for speed purposes you should put script tags right at the end of the document (before the closing body tag). While this will result in the fastest page load, it has some serious downsides.
Firstly, a common idiom with Webpage development is to have a header file, a footer file and your content in the middle. To keep unnecessary JavaScript code to a minimum, you'll often want to put code snippets in individual pages.
If you include jQuery, for example, at the end of the document, your jQuery code snippets (like document ready stuff) must happen after that. That can be awkward from a development point of view.
Secondly, in my experience, because the page load is faster, you can end up noticing certain effects being applied because the page has already loaded by the time they are applied.
For example, if you put a table in a document and right before the body close tag put:
$(function() {
$("tr:nth-child(odd)").addClass("odd");
});
with appropriate styling, that effect being applied will often be visible. Personally I think that makes for a bad user experience potentially. I think often you're better off having the page load slightly slower (by putting scripts at the top) if you don't get disconcerting visual effects.
I generally advocate effective caching strategies so you only have to download JavaScript files when they change, as in Supercharging JavaScript in PHP (but the principles apply to any language, not just PHP) and still putting scripts at the top. It's far more convenient.
By putting them in the <head/> you force the browser to download the files before it can render a page. That causes the perceived load time to slow down.
By placing them in the footer, right before the closing body tag, the browser will not load them until it reaches that point in the parsing of the HTML. That means that the scripts will run later in the page load process but will not block the asset download and rendering process.
Which works best is up to you and how you develop your code.
The Yahoo YSlow tool has advice on this:
The problem caused by scripts is that
they block parallel downloads. The
HTTP/1.1 specification suggests that
browsers download no more than two
components in parallel per hostname.
If you serve your images from multiple
hostnames, you can get more than two
downloads to occur in parallel. While
a script is downloading, however, the
browser won't start any other
downloads, even on different
hostnames.
In some situations it's not easy to
move scripts to the bottom. If, for
example, the script uses
document.write to insert part of the
page's content, it can't be moved
lower in the page. There might also be
scoping issues. In many cases, there
are ways to workaround these
situations.
An alternative suggestion that often
comes up is to use deferred scripts.
The DEFER attribute indicates that the
script does not contain
document.write, and is a clue to
browsers that they can continue
rendering. Unfortunately, Firefox
doesn't support the DEFER attribute.
In Internet Explorer, the script may
be deferred, but not as much as
desired. If a script can be deferred,
it can also be moved to the bottom of
the page. That will make your web
pages load faster.
Google pagespeed have some nice explanation on how to parallelize downloading of scripts.
Still their advice is to put them in the head of your page.
Script tags should generally be in the head section. The exceptions are when they do significant immediate processing that should be delayed until as late as possible in the page load to avoid interfering with the page coming up, as with Google Analytics, or when the script tag's actual placement is a part of its behavior.
The reason for declaring near the end is that your page can begin drawing before having to wait to fetch the .js.
Ergo, stuff you would want at the end would have no effect on the page rendering, and vice versa.
I like to load a small js file in the head, that handles (1) anything that happens before the page is rendered and (2) the loading of other script files after the page loads, or as needed.
The Place of the <script> Element
The script elements block progressive page downloads.
Browsers download several components at a time, but when they encounter an external script, they stop further downloads until the script file is downloaded, parsed, and executed.
This hurts the overall page time, especially if it happens several times during a page load.
To minimize the blocking effect, you can place the script element toward the end of
the page, right before the closing tag.
This way there will be no other resources for the script to block.
The rest of the page components will be downloaded and already engaging the user.
The worst antipattern is to use separate files in the head of the document:
<!doctype html>
<html>
<head>
<title>My App</title>
<!-- ANTIPATTERN -->
<script src="jquery.js"></script>
<script src="jquery.quickselect.js"></script>
<script src="jquery.lightbox.js"></script>
<script src="myapp.js"></script>
</head>
<body>
...
</body>
</html>
A better option is to combine all the files:
<!doctype html>
<html>
<head>
<title>My App</title>
<script src="all_20100426.js"></script>
</head>
<body>
...
</body>
</html>
And the best option is to put the combined script at the very end of the page:
<!doctype html>
<html>
<head>
<title>My App</title>
</head>
<body>
...
<script src="all_20100426.js"></script>
</body>
“JavaScript Patterns, by Stoyan Stefanov
(O’Reilly). Copyright 2010 Yahoo!, Inc., 9780596806750.”
You should put JavaScript right before </body>. Ideally, your HTML should function without JavaScript, so it should be one of the last things loaded.
Bear in mind that you should use CSS to hide elements and not JavaScript. This avoids seeing elements appear and disappear as the page loads.
You may also come across the following problem...
Problem
In this scenario, I'm going to use PHP as an example.
Your footer.php file may currently look like this:
<script src="jquery.js"></script>
<script src="custom.js"></script>
</body>
</html>
But what happens on the rare occasions you want to add some <script> exclusively for one page? You wouldn't be able to put it after footer.php because you wouldn't be in the <body> tag anymore, but you can't put it before, because then you'll be missing the jquery.js from your code.
Solution
Have a footer-start.php file:
<script src="jquery.js"></script>
<script src="custom.js"></script>
And a footer-end.php file:
</body>
</html>
And have your footer.php be simply:
<?php
require 'footer-start.php';
require 'footer-end.php';
Then, on the rare occasions that you need to use a custom <script> for one page, do this:
<?php require 'footer-start.php'; ?>
<script>...</script>
<?php require 'footer-end.php'; ?>
Doing it this way means you don't have to change all your previous code where footer.php is referenced.
I believe it's better to place script tags just before the closing body tag. Because:
Elements are blocked from rendering if they are below the script.
In Internet Explorer 6 and Internet Explorer 7, resources in the page are blocked from downloading if they are below the script.
It is from this article. Also Yahoo's performance rule 6 is Move scripts to the bottom.
You should do it near </body>. The reason is simple: If you place it into the head area, the files must be loaded before the body area can be. For that time, the user just sees a white screen.
But it depends on your website. I would load frameworks like mootools in the head area, other functions for events or AJAX or something should be loaded near </body>.
The only reason for putting it near the end of the body, AFAIK, is to be able to execute the JavaScript after the web browser has parsed your HTML document. E.g. if your JavaScript deals with "all elements named hello", the browser needs to read the entire document before executing your JavaScript. Makes sense, right?
In e.g. jQuery, you can put your JavaScript anywhere in your document and use:
$(document).ready(function () {
// Your code here
});
...to make sure the entire document has been loaded into the DOM before executing the inner function. Of course, this can be done with normal JavaScript as well, but be careful not to break compatibility with some browsers, because their needs tend to differ a lot.