Prevent JavaScript Elements from Breaking Page Layout when Following Yahoo Performance Tip #6: Place Scripts at the Bottom
Published Monday, November 12, 2007 @ 11:56 pm • 11 Responses
By now, everyone is familiar with the Yahoo Developer Network’s 14 “best-practices” for speeding up your website. Certainly, many (if not all) of these performance optimization tips are ideal for high-traffic sites such as Yahoo or Google, but not all of them are recommended for smaller sites such as Perishable Press. Nonetheless, throughout the current site renovation project, I have attempted to implement as many of these practices as possible. At the time of this writing, I somehow have managed to score an average 77% (whoopee!) via the YSlow extension for Firebug.
Of the handful of these tips that I am able (or willing) to follow, number 6 — move scripts to the bottom — is definitely one of the easiest. The reason for doing this is at least twofold:
[…] it’s better to move scripts from the top to as low in the page as possible. One reason is to enable progressive rendering, but another is to achieve greater download parallelization.
— Yahoo! Developer Network
Many people mistakenly assume that the <script> element (and associated contents) must be located squarely in the document <head>, however, this simply isn’t true. As outlined in the official HTML 4.01 Document Type Definition and also in the official XHTML 1.1 Document Type Definition, the <script> element is allowed:
- anywhere within the body element
- within any block-level element
- within any inline element
- within the head element
- virtually anywhere
Thus, the YDN advice of placing <script> elements at the bottom of the page is 100% standards-compliant. Indeed, after relocating my scripts to the bottom of the document body, my pages continue to validate with flying colors. I can’t honestly say that I have noticed any significant improvements in speed (e.g., page loading time, rendering time, etc.), but I do understand the logic behind this particular performance tip and will continue with its implementation, which, unfortunately, is not always 100% hassle-free..
Preventing script elements from breaking page layout
When script elements are placed in the document head, page layout is not effected in any browser. You can put a hundred of ‘em up there without affecting the visual presentation of underlying (X)HTML and/or CSS. Move any number of script elements to the bottom of the body element, however, and the page may render incorrectly in several popular browsers.
Apparently, Internet Explorer 7 and Opera 9 incorrectly attribute a literal height to script tags located outside of the head. In other words, rather than ignoring the scripts tags, these browsers are applying some sort of height property to each of them, thereby altering the intended layout of neighboring regions of the page. — Not good.
After relocating my scripts here at Perishable Press as follows:
.
.
.
<div id="footer">
<h6>All Contents Copyright © <?php echo date('Y'); ?> Perishable Press</h6>
</div>
</div>
<script src="http://perishablepress.com/press/wp-includes/js/perishable.js" type="text/javascript"></script>
<script src="http://perishablepress.com/mint/?js" type="text/javascript"></script>
<script src="http://www.google-analytics.com/urchin.js" type="text/javascript"></script>
<script type="text/javascript">
_uacct = "UA-123456-1";
urchinTracker();
</script>
</body>
</html>..I noticed that my footer was no longer appearing as tightly as usual in Internet Explorer 7 or Opera 9.2:
![[ Screenshot: broken footer positioning in IE 7 ]](http://perishablepress.com/press/wp-content/images/2007/script-tags/ie-incorrect.gif "a rather 'loose' footer as seen in IE 7")
![[ Screenshot: broken footer positioning in Opera 9.2 ]](http://perishablepress.com/press/wp-content/images/2007/script-tags/opera-incorrect.gif "a rather 'loose' footer as seen in Opera 9.2")
Here is how the footer should appear in a perfect world, where everybody uses the latest version of Firefox:
![[ Screenshot: proper footer positioning in Firefox 2.0 ]](http://perishablepress.com/press/wp-content/images/2007/script-tags/firefox-either.gif "a 'tight-ass' footer as seen in Firefox 2.0")
Fortunately, the solution to this (admittedly minor) presentational dilemma is rather simple: hide the script elements via CSS. Using a combination of display:none; and visibility:hidden; declarations applied to a container <div>, we may easily and swiftly restore our desired page layout. Using the following CSS:
.hide { display: none; visibility: hidden; }..with a script-enclosing <div> container as follows:
.
.
.
<div id="footer">
<h6>All Contents Copyright © <?php echo date('Y'); ?> Perishable Press • <a href="#top" title="Return to top of page">Up</a></h6>
</div>
</div>
<div class="hide">
<script src="http://perishablepress.com/press/wp-includes/js/perishable.js" type="text/javascript"></script>
<script src="http://perishablepress.com/mint/?js" type="text/javascript"></script>
<script src="http://www.google-analytics.com/urchin.js" type="text/javascript"></script>
<script type="text/javascript">
_uacct = "UA-123456-1";
urchinTracker();
</script>
</div>
</body>
</html>..results in a completely hidden set of “optimally placed” script elements. Both IE 7 and Opera 9.2 (and therefore, I assume, virtually all major, modern browsers) will cease to apply dimensional properties to this “hidden” set of scripts. The bad news is that we must use additional, non-semantic markup in order to hide the scripts — CSS properties (i.e., display:none;) applied directly via class attributes will not work. For example, something like this proves entirely ineffective:
<script class="hide" src="http://perishablepress.com/press/wp-includes/js/perishable.js" type="text/javascript"></script>
<script class="hide" src="http://perishablepress.com/mint/?js" type="text/javascript"></script>
<script class="hide" src="http://www.google-analytics.com/urchin.js" type="text/javascript"></script>
<script class="hide" type="text/javascript">
_uacct = "UA-123456-1";
urchinTracker();
</script>The good news, however, is that wrapping the <script> elements in a non-displayed, hidden <div> does not interfere with the functionality of the JavaScript enclosed therein. This had to be the case, of course, or I never would have spent my evening writing this article ;)
And finally, for those of you who are curious, here is what my current footer looks like in Internet Explorer and Opera now that I have employed the simple technique described above:
![[ Screenshot: restored footer positioning in IE 7 ]](http://perishablepress.com/press/wp-content/images/2007/script-tags/ie-correct.gif "restored footer layout as seen in IE 7")
![[ Screenshot: restored footer positioning in Opera 9.2 ]](http://perishablepress.com/press/wp-content/images/2007/script-tags/opera-correct.gif "restored footer layout as seen in Opera 9.2")
And, of course, Firefox remains solid, displaying the original page layout precisely as intended:
That’s all for now — thanks for reading ;)
About this article
Related articles
Dialogue
11 Responses Jump to comment form
November 13, 2007 at 6:36 am
Wow, i score 95 at the Yslow thing ! I just miss the #2 point which is adressed to professional websites.
Your post has made me go back into optimisation, and I’ve come to some new solutions that allow the compression and caching of my content (on a mutualised server, without zlib, and with very few possibilities for the user).
November 13, 2007 at 12:23 pm
Well, if you need help, I think I’ve come to something really effective.
Try to load a page of my weblog for example. It should be quit fast. Then try to reload it…
(use FireBug for more objectivity)
November 17, 2007 at 2:53 pm
I’ll write about it on my weblog, so you may read it there somewhen soon.
I’m affraid it will be in french, but the main idea will be understandable I guess (and services like Reverso do a good job translating fr —> eng).
Anyway, if you need more information then, you can just mail me :-)
November 18, 2007 at 9:02 am
I don’t have the courage to translate all that into english, so here is the Google english version of my article
I find it pretty nice.
March 4, 2008 at 9:05 am
I’ve never noticed this before — thanks for the heads-up!
Another small advantage of putting scripts at the end is that, since the DOM is mostly loaded at this point, you can start manipulating it immediately, thus eliminating the need for “onload” events can be delayed while waiting for images etc. to load. (This was a problem on a website I was working on.)
April 16, 2008 at 10:55 pm
yeah, definitely would not have thought of that. great info!
[ Comments are closed for this post. ]
If you have additional information, contact me.
← Previous post • Next post →
« Perishable Press Site Renovation Strategy • Easily Adaptable WordPress Loop Templates »
1 • Louis
November 13, 2007 at 3:41 am
That was some pretty interesting work, thanks.
In my experience, putting the Js at the bottom showed a real difference in terms of loading times.
I guess it’s a matter of weight of the Js (and when you have animations in particular).