Yet, with all the power and insight these tools give, it still feels like it’s best-kept-secret kind of thing that such tools even exist. I never hear anyone talking or writing about them. But I fire them up probably at least once a month to keep an eye on my various sites.

But the hush-hush of Google’s toolset makes it more exciting to highlight a really cool addition announced today, the new Site Performance tool. True, it’s still in development and very early on, but it already is showing the promise to give great new insights into how your site is performing out in the wild.

We all got the hint a few weeks ago that Google is planning to start considering page-load speed in its indexing algorithm. It would seem to be somewhat “evil” for the world’s largest search engine to start holding page-load speed against everyone’s sites without being part of the solution. So it shouldn’t be a surprise that the G would begin releasing various “tools” to help the rest of us actually make our sites load faster.

Bye, bye, birdie!

Yesterday, the Google Analytics team released a long-overdue update to their suggested snippet for including “ga.js” in pages. They wisely ditched the horrid “document.write()” approach that has been the standard for the longest time, in favor of this new asynchronous loading technique. The reason? Quite obviously, this now will unblock the loading of GA from page loads, thus preventing Google from being at fault for slower load times!

Side Note: the suggested code that Google has released has been shown not to be safe with all page structures in some browsers, including (ironically!) Chrome, and Opera. The problem is a faulty assumption that “document.documentElement.firstChild” will always return a reference to the HEAD element to append the <script> to. As this documentElement.childNodes test page from @kangax shows (if loading in Chrome or Opera, for instance), it’s (too) easy to accidentally create your page in such a way that this assumption will fail. So, be careful before you jump to switching to Google’s new snippet. (hint: use LABjs instead. Simpler, easier, and much more reliable!)

But, snarkiness aside, the new “Site Performance” tool proves its worth when it shows you a graph of your page’s estimated average load speeds over the last several months, along with a few basic statistics. It also incorporates a number of Google’s PageSpeed rules and suggestions for how to reduce factors that are slowing down your page loads.

This information is a really great place to start when trying to attack the performance issues your site may have. In fact, it may help you identify issues you didn’t even know existed!

Where’s the visuals?

Imagine my elation when I pulled up one of my larger, more traffic’d sites in the tool and saw this graph:

Site page-load performance improvements over last few months

I went from an average of over 3.5 seconds per page load back in August down to a current average of less than 0.3 seconds, which the tool claims is better than 98% of sites! Oh, and btw, this site loads over 105k of JS, images, and CSS, so this isn’t some puny text-only site getting that kind of loading speed. It’s a testament to the results you can get if you start caring about page-load optimization on many fronts.

But you know the biggest and most obvious change I made back in July and August on the site in question? That’s right, you guessed it — that’s when I first installed early versions of LABjs for all the site’s scripts. And over time, I’ve not only improved the efficiency and capabilities of LABjs, but I’ve also refined more and more how I work to address page load speeds. To be fair, optimizing script loading was only one of many strategies I used, including CSS spriting and combining/concat’ing of JS files to reduce the number of HTTP requests.

But it’s plainly evident that LABjs was a critical part of this process!

No matter what you feel about dynamic script loaders and if they are useful or not, it’s clear that all of us have to get more serious about improving our page-load performances if we don’t want to get left in the Google-index dust. I just believe that script loading is an easy and hugely impactful place to start that process. Remember: optimize, optimize, optimize.

Just kidding, you’re probably just now starting to hear about it. But let me tell you, it is the next big thing. I mean, when was the last time someone found a way to completely revamp the plain ol’ boring <script> tag and give it new life!?

All levity aside, LABjs stands for Loading And Blocking JavaScript. It’s a general purpose script loader that aims to be able to effectively load any script resource(s), from any location, into any page, at any time. It loads them all as parallel as the browser will allow, but maintains execution order when you express the need to do so in the usage of the API, for keeping dependencies safe.

LABjs’ primary goal is to replace the “<script> tag soup” in your pages (you know, all that garbage that clutters up your <head> or the end of your <body>) with a simple and expressive API that gives you complete control over the loading and executing behavior of your scripts.

LABjs 1.0, just released yesterday, now sports the “preloading” feature, which is the culmination of several months of collaborative efforts with Steve Souders to bring the best of his script loading work from his most recent book Even Faster Web Sites (EFWS) together with the expressive power of LABjs. We hope the new release represents the best of both worlds, and a really strong, solid solution for loading JavaScript resources into your pages.

What is “preloading” for?

The primary idea behind the “preloading” feature is to “look ahead” in the chain of LABjs API calls and start loading all (or, strictly, as many as the browser will allow at a time) scripts at once, but doing so in a “preloading” way much like was common years back with preloading images into the cache via JavaScript techniques.

Since the scripts are only preloaded, and not actually executed, LABjs is free to control the execution order of the scripts, which allows it to preserve proper execution order if you use the API functions to express the need to “wait()” for dependencies.

So, how does this improve loading of my page?

In addition to making the scripts load in parallel with each other (as much as possible), the scripts also load in parallel with the rest of the page’s resources. This means that virtually all page resources will load at nearly the same time, rather than waiting for one to finish before the next starts, as is common in many current browsers’ implementations of <script> tag behavior.

FF3, loading scripts serially with each other and page resources. 16.84s

Notice how the 3 script files load in succession, and only after they complete do the images start to download (at least those download in parallel!). 16.84 seconds to download serially.

FF3.5, loading scripts in parallel with each other, but still blocking page resources. 10.69s

FF3.5 introduced a nice new behavior in that they will download scripts in parallel, but still maintain execution order. So, in this diagram, we see that the scripts are parallel to each other, but still they block other page resources. Down to 10.69 seconds loading all resources.

LABjs, loading scripts in parallel with each other and other page resources. 6.24s

This diagram shows the loading behavior of LABjs in virtually all browsers, modern and not-so-modern. Notice that not only are scripts loaded in parallel to each other (while still maintaining execution order when necessary), but in parallel with other page resources as well. This means that you can use a much larger slice of the browser’s bandwidth to grab page resources as quickly as possible, speeding up the loading of the page by significant amounts (generally 2x to 3x speed increase).

In this example, we went from 16.84s down to 6.24s. That’s a 2.7x speed increase. Now that’s something to get excited about!

Are there any negative side effects?

LABjs (and other dynamic script loaders like it) are so good at getting page resources and scripts to load more quickly, it unintentionally creates a lesser seen phenomenon in web user-experience that I am calling “FUBC” (flash of un-behaviored content) — pronounce it “fubik” — which is a takeoff of the more commonly known FOUC (flash of un-styled content).

FUBC means that it is possible that your raw (but still CSS styled) content may arrive to a page and even be displayed momentarily before your JavaScript has had a chance to kick in and attach behaviors or modify it. For some sites, the changes made by JavaScript behaviors are subtle and most users won’t notice. But for other sites, the “flash” between the two views of the content is much more drastic and jarring.

Because this can be a potentially disruptive user-experience, I suggest the following simple steps to address the FUBC phenomenon:

1. In your main CSS of your page, hide (display:none or visibility:hidden) all content which will have drastic re-rendering by your JavaScript.
2. In your JavaScript, make sure to re-display/unhide the content once it has been styled by your code.
3. To take care of users who do not have JavaScript enabled, put a <noscript> block in the <head> of your page that unhides any
   content hidden by your main CSS — essentially, undo the CSS hiding of content, since there won’t otherwise be any JavaScript to do so.

By taking these 3 simple steps, you will effectively address the disruptive FUBC user-experience for JavaScript-enabled users, while still preserving proper display for the non-JavaScript crowd.

Anything else?

There are a couple of minor caveats where LABjs may not be appropriate for your site or scripts. One specifically you should be aware of is the implications of LABjs with DOM-ready and frameworks like jQuery.

But overall, there are just so many reasons to use LABjs. Why not give it a shot, see if helps your page load speed?

I’m ready! So how do I use LABjs?

To start, simply find your nearest “<script> tag soup” in a page, and replace it with $LAB API calls, like this:

Old and busted:

<script src="framework.js"></script>
<script src="plugin.framework.js"></script>
<script src="myplugin.framework.js"></script>
<script src="init.js"></script>

New hotness:

$LAB
.script("framework.js").wait()
.script("plugin.framework.js")
.script("myplugin.framework.js").wait()
.script("init.js");

In the above example, all scripts load in parallel (by default). “framework.js” needs to execute first, before the others. But “plugin.framework.js” and “myplugin.framework.js” have no dependencies between them, so their execution order is not important (first-come, first-served). “init.js” needs to wait for all 3 scripts to execute before it runs.

The LABjs API has a number of other options and alternate usage patterns, so check out the Documentation and the Test Suite for more information.

Responsibility

I firmly believe it is all our responsibility to do what we can to make the web a better place to live. One of the best ways we can do that is to reduce the amount of time it takes to load friggin’ web pages! So get to it, go download LABjs right away and give your site a makeover in the <script> tag department!