Why it is ok for our JavaScript snippet to be at the top of the page

Document created by Dave Murphy Employee on Jul 20, 2017
Version 1Show Document
  • View in full screen mode

We really care about web performance. We promise.

However, we sometimes get challenged on this when we tell people to put our snippet at the top of thier page.

 

Those that are familiar with web performance have likely heard about the original '14 rules' for making your site faster. Those that haven't, be sure to check them out! http://stevesouders.com/hpws/rules.php

 

Rule #6: Put Scripts at the Bottom 

 

Why does this rule exist?

In the days when browsers had little support for parallel downloads, we became very sensitive to resources that ‘blocked’ other assets on our pages. JavaScript was the worst, as the download (biggest issue) and execution time (in the case of our snippet, not measurable) blocked. Even CSS blocked in some browsers. The answer in the early days of webperf was to ‘move it to the bottom’. A great rule that still works today for non-critical resources.

 

The problem was that synchronization of JavaScript was still important. As it is with boomerang.js, the library we just for real user measurement. Many JS libraries are depended upon for rendering or content, or in the case of boomerang – the measurement of performance and/or metrics that needs to happen before the window.onload event.

 

As we got smarter, we looked at ways that we could work around the download issue. We can now ensure that downloading of JS does not block, and the more modern browsers started expanding support for more parallel downloads.

 

These posts talks about non-blocking script techniques – which allows you to download the script in a non-blocking way (the foundation for the best practice used today).

2008: http://www.yuiblog.com/blog/2008/07/22/non-blocking-scripts/

2009: http://www.stevesouders.com/blog/2009/04/27/loading-scripts-without-blocking/

 

This post came along, which talked about the difference between ‘defer’ and ‘async'

2010: http://calendar.perfplanet.com/2010/the-truth-about-non-blocking-javascript/

And we improved even more on the ‘perfect snippet’:

2011: http://calendar.perfplanet.com/2011/the-art-and-craft-of-the-async-snippet/

 

However, we still were blocking the window.onload event from firing. 

Facebook (and our own Philip Tellis) worked together to address this:

2012: https://www.facebook.com/note.php?note_id=10151176218703920

2013: http://calendar.perfplanet.com/2012/the-non-blocking-script-loader-pattern/ <— A truly asynchronous loader which does not block onLoad is born

 

The last entry covers the technique we use for loading our mPulse snippet. This is the preferred method that is recognized throughout the web performance community. 

 

Please post any questions or thoughts!

Attachments

    Outcomes