Moving JS to the Bottom of the Page

Well I just tried this, and it's working pretty good - including stuff like suckerfish menus and jquery.corner.js

I thought most of the issues would be around stuff that happened at window.onload - maybe document.ready avoids all that, in which case, great!

edit: no actually I am getting some 'onload' with jquery corners - since it's adding elements to the DOM. But the saving in firefox spinning is massive.

The jquery code for this is essentially an onload (though implemented differently). Both onload and jquery's document.ready will run AFTER all the html DOM has been built.

So, in an ideal world, from a performance view, location of the $script in your template shouldn't matter at all.

The reason pages are often affected is probably because many modules use shortcut direct javascript queries not protected by onload or document.ready, so placing those "offending" scripts at the bottom of the page lets the dom get better established prior to that js running.

My results have been:

1) With well behaved modules that already use document.ready, you could have a small benefit on most pages.
2) With troublesome modules that SHOULD use document.ready, you will see a great benefit on most pages.
3) With bad modules that use 1st generation javascript like document.write, you can see errors or even failures.

ymmv: Caveat Emptor (or in my case Caveat Speller)

I decided to do some tests with regard to manipulating the DOM by including code in the Head and near the bottom of the page - keeping in mind the purpose of $(document).ready():

Testing method:

Configuration:

I created 200 nodes with the devel module. Each with 2000 characters displayed before the teaser break. I adjusted the default_nodes_main drupal variable to allow 200 nodes to be displayed on the home page. (Basically, I wanted to have a great deal of content rendered by the browser between the head of the document and the footer [approx 400k of HTML text])

Scripts:

I Create two js files. head.js and footer.js
Containing the following code:

head.js

Obviously not useful code in the real world - but it does DOM manipulation

footer.js

head.js was included inside the document < head >
footer.js was included just before the end of </ body >

Results (edited for readability):

footer NOT ready time: 02:31:25 23ms
head ready time:       02:31:25 26ms
footer ready time:     02:31:25 28ms

Reading the results:

Obviously the headNotReadyTime was called and executed first - but since it attempted to manipulate the DOM by adding something to the < body > which did not exist yet - it failed to work.
footerNotReadyTime was executed next - and by the time that code was called at the bottom of the page < body > existed and was able to add its time to the < body > tag.
headReadyTime was executed next - and since the DOM was 'ready' it was able to write its time.
footerReadyTime executed next - and it was able to write its time.

Followup:

All well and good - but I want to know how long it took between 'headNotReady' and 'footerNotReady' - so I modified the footer script to print the headNotReady time

(results edited and sorted for readability and logical sequence - actual results had head Not ready time printed last)

head Not ready time:   02:41:03 302ms
footer NOT ready time: 02:41:04 167ms
head ready time:       02:41:04 169ms 
footer ready time:     02:41:04 169ms 

And there it was - 0.8 second difference between the top and the bottom of a 400K page. This number represents the DOM loading time.

Conclusions:

If you want to manipulate the DOM - the DOM must obviously be loaded in order for you to manipulate it.
$(document).ready(function(){//DOM manipulation}) does what it is advertised to do. i.e. wait till the DOM is loaded.
But if you insert code at the bottom of the page outside of such a function the DOM is nearly completed its load and your code will do its trick (But, it is still best to wrap it in that function)
So -It turns out that if you want to manipulate the DOM it makes no significant difference whether the code that does the manipulation is included at the top or the bottom of the page.

However, if what you want to insert into the DOM requires calculation you might want to start those calculations at the TOP of the page OUTSIDE OF $(document).ready(function(){}); They will get a head start. Though I wonder what happens if the results aren't ready by the time your DOM manipulation code starts? I suppose you would either conditionally insert the value of your calculation OR you could put a 'sleep' in your code to keep trying until the value was available.

So - long story short - I've demonstrated that some code is perfectly fine at the bottom of the page. I've demonstrated that there maybe a reason to start some code at the top of the page.

BUT, I don't know how to test for what Yahoo says is a problem. i.e. What kind of js code introduced at the top of the page will slow down the page render? What kind of code would keep the page from loading progressively? What is the test case that would cause a slower page load by having js at the top.

Sorry, that was way longer a post than I had intended to make. I hope its of some value to someone. Let me know if you see a flaw in my test or if I have drawn any incorrect conclusions. OR if you have different conclusions please share.

andre

Thats true, I didnt mean that APC would help with this issue, just simply stating that I would target those big/easy performance enhancements before I would go sticking JS in a different location in the DOM.

vision media
350designs