JS end or start of Page

[The14thGOD]

I know the recent trend is putting JS at the bottom (just before the closing body tag) so that the page loads faster (user can access content faster, and functionality/quirks are loaded last). However, I've noticed that when I do this you tend to see a lot of "oh oh's." Aka a stack of images that goes down on the page that vanishes after the JS is loaded or other things of similar nature.

 

What's the best way to hide these "oh oh's"? I know you can do it in CSS but what if you don't have JS enabled. Then the user never knows it's there (anyone got a percentage of how many ppl actually have JS disabled and any sort of demographic?)

[KevinM1]

I know the recent trend is putting JS at the bottom (just before the closing body tag) so that the page loads faster (user can access content faster, and functionality/quirks are loaded last). However, I've noticed that when I do this you tend to see a lot of "oh oh's." Aka a stack of images that goes down on the page that vanishes after the JS is loaded or other things of similar nature.

 

What's the best way to hide these "oh oh's"? I know you can do it in CSS but what if you don't have JS enabled. Then the user never knows it's there (anyone got a percentage of how many ppl actually have JS disabled and any sort of demographic?)

 

To be honest, with modern browsers and computers, I wouldn't worry too much about speed.  Unless you have a very large, or loop-intensive script, it probably won't matter where you put it.

 

I, personally, like putting my code in the head and using either window.onload() or jQuery's ready() function to load it.  It helps foster unobtrusive design while ensuring everything in the document is loaded before I attempt to manipulate elements.  But, to each their own.

 

As far as the people without JavaScript are concerned, they're why the noscript tag exists.

[haku]

Actually nightslayr, the limitation on speed isn't a result of the user's PC or their browser, it's an HTTP limitation, that is a result of how the internet was designed. Putting external scripts at the bottom allows the browser to make javascript requests last, allowing the rest of the page to load smoothly. Putting at the start prevents any other HTTP requests until the script is downloaded. Read the first part of this link:

 

What Yahoo Developer has to say on the subject:

 

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.

 

http://developer.yahoo.com/performance/rules.html (the third or fourth point down)

 

To the OP - in such a case you can move your script further up the page. You can either add it just before the images in question are about to load, or just after. Both will result in a slight performance hit over putting it at the very bottom of your script, but will speed things up faster than putting them in your head.

[KevinM1]

Interesting.  I'm curious as to why that decision was made in the HTTP spec.  There has to be some technical reason for it, because at first blush it seems a bit restrictive/antiquated.

[haku]

Restricted and antiquated it is - just like the HTTP spec. It was never made with the current form of the internet in mind.

[KevinM1]

Restricted and antiquated it is - just like the HTTP spec. It was never made with the current form of the internet in mind.

 

Ah, there is that.