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.

[8/12/2010: I've posted a performance benchmark test to try and gather some numbers from the crowd-at-large on how single large concat'd files perform compared to chunking that big file into a couple of smaller files to download in parallel. I encourage you to go right now and click each of the buttons a few times, and then spread the link on to others. Concat Performance Benchmark Test #1]

By far the most prevalent question circulating right now in the wake of href="http://labjs.com">LABjs‘ initial public launch (IPL, I guess!?) is the understandable: “Why do I need a loader like LABjs for multiple files when I can just concat everything into one file?”

Fair enough, this is an important question to address. You shouldn’t just take my implied assumption at face value; we need to dig into this so you understand why I feel so strongly that LABjs offers something better than what you are probably currently doing on your sites.

The short answer is, BOTH! You should concat files together when possible, and you should load your file(s) with a loader like LABjs. If you only do one or the other, you have missed out on the bigger picture of page-load optimization.

YSlow/PageSpeed only value reducing HTTP requests

Before I get into specifics about why I think LABjs brings something new and beneficial to the table, let’s tackle what I consider to be an interesting but perhaps misleading “truth”. I am firmly in a minority camp in my skepticism that reduction of HTTP requests is the only answer to the question of how to load a site more efficiently — actually, to be more accurate, how to load a site’s JavaScript more efficiently.

I bet that you are recalling the YSlow rules and the tried-and-true practice that concat’ing all your JS files into one file for production is the surest way to speed up your page loads. And you’re probably doubting my credibility because I would question such a fundamental “truth” as HTTP request reduction.

It is true that, especially for the largest sites on the internet (millions of page-views per month and more), the sheer volume of HTTP requests from a typical page profile (dozens of images, multiple style sheets, half a dozen JS files, etc) quickly overloads internet connections, server load-balancers, the user’s device, and even the browser itself. And anything you can do to reduce that overload will go a long way toward helping the site load with acceptable performance.

Sites like Yahoo and Google have taught us the basic principles of HTTP request reduction as an effective way to cut down on the overall page loading delays. For instance, consider Spriting to combine images, CSS concatenation, and, yes, JavaScript concatenation. Some sites, like Digg, have even experimented with the extreme — inlining all page resources, even binary image data, into a single multi-part request! And just recently, we saw a proposal for Resource Packaging as another way to combine multiple types of data into single responses for HTTP request reduction.

If you run a site that has well over 50 million page views per month (I sure don’t!), you probably would assert that this is the easiest and most effective page-load optimization. And I’d be hard-pressed to go up against the brightest and the best at the world’s largest web properties to suggest that it’s not true, at least at their page-view volume.

What’s true is true. Period.

Here’s what I will suggest: maybe, just maybe, what’s true for Google at a hundred-million page views may not identically and exactly be true for the vast majority of us running sites in the tens-of-thousands page view realm. The “big boys” are up in rarefied air, and from there they certainly have the request volume to test, re-test, and “prove” these various rules of optimization. But in the same way that water behaves in strange, almost contradictory ways at extremes of hot or cold temperature, maybe the art of optimizing page loads isn’t as simple as “1 http request is always better than 2.”

Even for small sites (like the one you’re currently reading!), it’s still vitally important to reduce page load time and optimize for faster page views. So, I’ll readily and eagerly admit that a key strategy in that effort is for all of us to work to reduce our HTTP request loads.

OK, so you agree concat’ing is best?

Not so fast. Like I said, this issue is more complex than I think most of us are ready to admit. Too easily, we run the YSlow plugin tests on our site, and when we reduce HTTP requests by concat’ing our JS files, because it tells us to, not only does our perceived page-load times decrease, but our YSlow grade goes up! Success! We’ve proved the hypothesis, there’s nothing more to say, right?

I don’t think this in and of itself means you have achieved the pinnacle of page-load performance, you’ve simply taken the first of many steps toward nirvana.

In my opinion, loading your JavaScript in an efficient and optimized way cannot be boiled down into a simple set of “rules” — you can take such “truths” as good places to start, but you still have to refine the strategies to fit your particular site and audience. Indeed, this will start to look more like an art than a science, if done correctly.

I’m not so sure…

Maybe by this point, you’re still not convinced there’s more to the story, and you’re probably starting to feel like LABjs doesn’t really have that much to offer you.

Before you go, let me just say this: even if you only ever have one JavaScript file on your site, because concat’ing is the way to go for you, and you think that by putting a single <script> tag at the bottom of your page, you’ve achieved the ultimate JavaScript loading solution — there is still some benefit to using LABjs to load that one file.

Why? A regular <script> tag in the main HTML, even at the foot of your document, will always block the page’s loading completion, which means that users will still be “stuck” waiting for that file to complete before they can do anything with your page. Now, for some pages, you may really not want the users to do anything until the JavaScript fully processes everything, but most people agree that designing sites for progressive-enhancement is a positive thing.

So, if you can design your sites so that there’s something meaningful for the users to see or even do while they wait for the JS to kick in, they will probably be happier with your site than if you just make them wait. And that’s where LABjs comes in. Loading JavaScript dynamically unblocks the rest of the page’s resources (and DOM-ready!), freeing the user from the iron grip of the hanging “almost loaded but not yet” feeling that most sites force upon their users.

Include the small 4k of LABjs (via an inline <script> tag) into your page, and use it to load your single JavaScript file, and I believe your users will see an improved, even slightly, user-experience on page-load, as long as you’re careful about it.

OK, so maybe there is more to this loading thing

Keep reading if you’re ready to take the Red Pill and dive deeper down the rabbit hole.

(… more …)

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!

Essentially, the idea is that web developers could proactively create .ZIP files of various page resources (images, CSS, JS, etc), and include in their page a special <link> tag pointing to that “package”. Smart, elite browsers (like FF 3.7!?) would grab this resource package, unzip and cache the resources, and ostensibly then know how to skip trying to download them from their normal references in the rest of the HTML page. The idea is of course the all-important, oft-mentioned “reduce HTTP requests down to the most absolute minimum possible” rule that we all have blazened into our psyche.

Wait, you mean you don’t agree with HTTP request reduction?

On it’s surface, I don’t disagree with “minimize HTTP requests”. Certainly that’s a good and very important goal. If you needlessly create additional requests because you are ignorant or lazy and fail to employ even simple strategies (like image spriting, for instance), you are asking to crash your server(s) when your traffic increases.

But I believe there’s a paranoia spreading in the UI development and production community that the reduction of HTTP requests is penultimate and more important than any other strategy, to the exclusion of alternative perfectly reasonable practices for UI delivery optimization.

For instance, you hear people all the time say, “concat all your JavaScript into one file” for production. But is this really the right approach? I won’t go into the details here of why I disagree with this as a blanket approach, as I cover that fully in this post, but suffice it to say, I think we must balance HTTP request reduction paranoia against some other sanity checks.

So what’s wrong with resource packaging?

I have a number of issues with this idea. Let me lay them out for you:

In reality, what I’m most worried about is that this’ll be seen as the silver bullet and just deployed in widespread and often under-optimized ways, and will propogate what I think is a dangerous anti-pattern: People are so paranoid about HTTP request overhead (because let’s face it, we all think our site will get slashdot’d or hit digg.com homepage so we better be ultra-micro-optimized for millions of hits per minute!) that they’ll just default to putting everything in one resource package.

When that seems to work well in their dev environment, they’ll just roll that out and blindly think it’s ok. When you give people a dangerous amount of rope, it’s hard to not expect at least a good number of people will hang themselves with it.

Remember the good ol’ days, when people created full-page flash sites, and when you visited the site, you sat and mindlessly watched a preloader animation while megabytes of content were all loaded at once? Oh, that was fun. I miss those days.

No, wait! I don’t miss that at all. Actually, I love that now we as a collective community realize that a critical part of user-experience is initial page loading behavior. I love that Google is going to start ranking pages based on how well they load. This is a healthy, even if slightly uncomfortable, nudging in the right direction.

But worse yet, if abused (either intentionally or not), I think this pattern will have worse overall performance than if people had just left their sites as they currently are.

Compare this type of approach to say someone taking more targetted/focused approaches to UI optimization. For instance, you could use LABjs for loading scripts in parallel with each other and the rest of the page resources… or use spriting… or how about css concatenation?

Each of those techniques is more narrow in focus and has much less potential for going wrong when employed, in terms of both pattern and practice. But one big single “solution to rule them all” has both enough upside and downside that I fear it could go seriously off track if used wrongly.

Aren’t YOU just being paranoid or pessimistic about web developer ignorance?

In addition to the potential improper usage patterns, I also think there are tangible issues that the proposal and Souders’ post don’t address, at least not completely:

1. Relying on a technique which only works (in any forseeable future) in one (or a couple at best) browser(s) will promote yet another anti-pattern… optimizing for a subset of browsers and ignoring performance in other browsers.

   I know there’s lots of people out there who find it vogue to discard performance in IE and say “well, the deserve what they get for using a crappy browser.” But I don’t think that’s productive or realistic. Wouldn’t our time be better spent finding (and educating about!) new ways (like LABjs, spriting, css concatenation) to optimize the UI performance that will improve things in practically all browsers?

   Doesn’t that serve the web community better than just myopically focusing on one (admittedly growing) segment that uses a bleeding-edge browser version and implements a new feature idea before it’s even really a standard?

2. What about resources that are CDN’d? Sure, you host some of your resources locally, but hopefully you are moving toward putting more and more of your stuff remotely, out on the edge, via CDN’s. There’s no doubt this is a powerful technique, and is only going to increase in importance.

   And forget CDN’s (at least technically) for the moment. I’ve never once rolled out a site where I didn’t link to at least one or a couple of remote resources. For instance, I use Google Analytics on all my pages, I often use an AddThis social badge script (and images), Google Groups forms and images, etc, etc, etc. What should I do with all these non-local page resources?

   So do you really even have that many resources locally that it makes sense to package? And what if people employ another anti-pattern and start hosting and packaging locally what could have otherwise been better hosted remotely (CDN or not) and shared globally? Are we going to keep relying on browsers to get smarter and smarter, enough that now they can resolve all these local vs. remote/CDN versions of files in the Package Manifest for us and choose the correct ones?

   I get scared when I start thinking about the browser trying to be smarter than I am about how it optimizes UI delivery performance.

3. What about parallel downloading? If you load a single file and it’s 1 MB in size, the browser will likely download that thing byte-by-byte, serially. At least until we get to using BitTorrent for our page resources!

   But wait, what if you downloaded 3 files instead? It’d download in roughly 1/3 the time, right? That’s cool. Now, that math doesn’t stretch on forever… obviously there’s a point where the overhead of HTTP Requests starts to degrade the power of parallel downloading. But there’s got to be some balance, some sweet spot between 1 file and 100 files?

   And I bet that number varies from site to site. For some, maybe it’s 2. For others, maybe it’s 4. So this is one more variable that web deployment engineers have to experiment with and figure out the black magic of what’s best for their site. Again, I bet most will end up punting on multiple resource packages and will just use one file. I doubt this will be a good thing for most sites.

   Remember this (pessimism or realism): if figuring out what’s best is not intuitive, most won’t do it.

Here’s the bottom line: Resource Packaging sounds good in theory. But I suspect the practice of it will be quite flawed, and we’ll have yet another dimension of suckiness out in the UI delivery world that we’ll all have to wade through and educate on how to get it right.

Ding!

Wait, I just thought of something! While we’re at the business of packaging things up to reduce requests… how about we JUST deliver a zip file to the browser, which includes everything, even the HTML for the page?

In fact, does it even need to be a ZIP file? What about if we could figure out a special file format (which I’m sure wouldn’t ever get bogged down in proprietary rights/trademarks or disagreements over specification), and in that way we can make that single file really optimized (“compiled”), and the browser could just get really smart about “executing” our page for us? We’d achieve the all-imporant single-page, single HTTP-request “golden ratio”.

And for all those old, busted, non-conforming (non-bleeding-edge) browsers, we’ll just ask users to install a plugin to assist the browser in processing the page. People like plugins, right?

Oh, wait. Nope. We’ve tried that before. Many times. It was called Java. Then it was called Flash. Now it’s called Silverlight or JavaFX. And thankfully we’ve evolved to a higher level of consciousness. Or so I hope.

The talk covers a number of different strategies, each of which I will be covering in subsequent posts here. But I wanted to give a quick overview of what you can expect:

1. Build-time optimization: it’s important to utilize build-process optimizations to manage local scripts and dependency chains. Depending on your server architecture and frameworks, there are lots of different choices that you have here, but the key is have a system that can manage this intelligence for you, freeing you and the other developers on your team from having to maintain the techniques yourselves.
2. Load/run-time profiling: We’ve all heard the advice that the best way to get JavaScript resources onto the page is to only have one JavaScript file, meaning we should always concat all our individual files into one massive output file as it goes to the browser in production. But does this always make sense? I believe it only rarely does.

   There are a number of tools for profiling your site/application at load-time and at run-time, to decide what parts of your JavaScript are critical to load at the beginning, and what parts can be safely deferred until later and be lazy-loaded. Doing so not only speeds up the load time user-experience of your site/application, but it also often helps create better long(er)-term user-experience by more effectively utilizing the user’s browser cache. You can profile manually, or automatically, but you shouldn’t ever put a site or application into production without at least examining these strategies and trying a few different options.

3. Post-optimize your minified JavaScript: For a long time, it felt like the book was closed on minification/obfuscation. There’s only so much white-space you can remove from a JavaScript file, and only so many variable names you can shorten, before a script seems as small as it’s going to get. But, it would seem there are more chapters to be written, yet.

   Recent releases of projects like Google Closure prove that there’s a lot more ground to cover on what we can do to optimize and shorten our scripts. I also have a project called Mincir which is aimed at specifically running post-minification optimization steps on files to squeeze out more bytes. Smaller files means quicker loading and better user-experience. And that means happier users and happier developers.

4. Dynamic, on-demand, parallel loading of JavaScript: While the landscape of how the browsers handle the <script> tag is quite diverse and often ugly, there are ways to normalize this behavior cross-browser, and in the process allow all your JavaScript resources to load at the same time, in parallel with each other and the rest of the page assets. This is actually not that hard. But ensuring proper execution order, not only of loaded scripts, but also of coupled inline script executions, is where the magic happens.

   Luckily, a project of mine, called LABjs, does just such a thing. It’s a general purpose, flexible, and capable JavaScript loader, that allows you to load just about any script or group of scripts onto any page, at any time.

5. Load and cache “not-code”, execute “code” later: Sometimes, the best way to get JavaScript onto the page is not to load JavaScript at all. This may seem like a crazy statement, but you actually have some options as to how your “code” gets delivered to the page. For instance, you can transfer the code inside a multi-line comment block, or even as an escaped string literal assigned to a JavaScript variable. You may ask, why would I do such a crazy thing? Well, it turns out that there’s a significant amount of time spent processing JavaScript once it’s loaded onto a page.

   So, if on one page you want to “preload” a script into the cache for use on a subsequent page, like you have done with images for years, you pay a penalty for that script simply being added to your page. Unless of course it’s not really a script at that point. If it’s a comment or a string literal, then it is loaded and saved into the browser cache, but there’s almost no processing time on the page at that point. Later, on another page, you can recall this “not-code” from cache, and transform it into executable code.

   This type of technique is quite valid for desktop browsers, but is particularly helpful for mobile browsers where the biggest bottleneck is not actually usually the connection speed but the processing power of the mobile device in handling large amounts of not-used-yet code while rendering a page.

None of these techniques are in and of themselves a complete solution to this issue, nor are these ideas the final word on the topic. But it’s time we evolve how we load our JavaScript onto pages and move beyond the 1990’s version of the plain ol’ <script> tag. I hope this talk and these posts will get that ball rolling.