Ajaxian » Performance

RequireJS: Asynchronous JavaScript loading

Dion Almaer — Thu, 18 Mar 2010 11:15:12 +0000

A certain someone was talking to me about how they find it interesting that node.js, the JavaScript server framework du jour which loves all things async, starts life with a bunch of synchronous require() calls. Now, this is actually quite fine since the startup of the server is not the issue at hand.

However, if you are running require()-esque loader code in the browser you want to avoid blocking calls else Steve Souders will come over and beat you up.

I have seen a couple of interesting items in this area:

RequireJS

James Burke of Mozilla Messaging has spent a lot of time in the depths of dojo.require(). He has taken another look at the problem and RequireJS a solution that offers:

some sort of #include/import/require
ability to load nested dependencies
ease of use for developer but then backed by an optimization tool that helps deployment

He walks through the problem and why other solutions like LABjs, CommonJS require, and Dojo itself don't cover all of his bases.

The end result is:

PLAIN TEXT

JAVASCRIPT:

// code that runs asynchronously when the library is loaded
require(["some/script.js"], function() {
//This function is called after some/script.js has loaded.
});
// defining the module and dependencies
require.def(
// The name of this module
"types/Manager",
// The array of dependencies
["types/Employee"],
// The function to execute when all dependencies have loaded. The arguments
// to this function are the array of dependencies mentioned above.
function (Employee) {
function Manager () {
this.reports = [];
}
// This will now work
Manager.prototype = new Employee();
// return the Manager constructor function so it can be used by other modules.
return Manager;
}
);

Google Analytics "async add to []" Pattern

When talking to Davis Frank of Pivotal about some Google Analytics code, he pointed me to details about the new GA asynchronous loader that we very excitedly blogged about since GA was such a blocking offender on the Web.

Part of the asynchronous API is that you, the developer create an array, and use the push() method to put commands on a queue. This means that you can start pushing commands immediately.

Then, when the GA code loads asynchronously, it takes over that array and wraps those standard methods. Now it can take the commands and fire them back to GA and push() can do more. Freaking brilliant.

HTML Minification

Dion Almaer — Wed, 10 Mar 2010 11:14:51 +0000

Good old Kangax has been playing with HTML minification and has shared his new tool in an early stage.

What does it do?

Kangax has forked John Resig's HTML parser which parses the HTML and sends that into the Minifier. This has rules that do things like whitespace optimization, comment removal, and collapsing boolean attributes (e.g. disabled="true" -> disabled).

He also has a linter going:

While working on minifier, I realized that oftentimes the most wasteful part of the markup is not white space, comments or boolean attributes, but inline styles, scripts, presentational or deprecated elements and attributes. None of these can be simply stripped, as that could affect state of the document and is just too obtrusive. What can be done, however, is reporting of these occurences to the user. HTMLLint is even a smaller script, whose job is exactly that—to log any deprecated or presentational elements/attributes encountered during parsing. Additionally, it detects event attributes (e.g. onclick, onmouseover, etc.). The rationale for this is that moving contents of event attributes to external script allows to take advantage of resource caching.

Firefox gets hardware acceleration in early stage

Dion Almaer — Fri, 05 Mar 2010 11:25:43 +0000

Bass Schouten is a cool name, and the Mozillan has presented Direct2D hardware acceleration.

You have to grab Firefox nightly, do the about:config / gfx.font_rendering.directwrite.enabled game, but then you get to see it in action.

IE9 showed off how they will support hardware rendering, and I am sure we will see more at MIX, but it is very cool to see this across the board.

CSS Transforms/Transitions/Animations are going to feel like butter in 2010!

New performance case studies… starting with the Digg widget

Dion Almaer — Mon, 01 Mar 2010 11:53:06 +0000

Would we all like Steve to sit down with us on our project and do a performance case study? Well, we may not get that, but we are getting to at least sit in on others.

Steve has kicked off his long awaited series that runs performance case studies on third party content. I have been talking to Steve about this for a couple of years, so it is great to see it. It is a sensitive topic as you never want to show up a team when you are just trying to help and educate.

First on the block? The Digg widget.

Steve goes into detail and finds a lot of short comings. You could probably guess some of the bad actors. Mr. document.write() appears for example. We get the problems, and proposed solutions to the issue. Steve also tries to note what a user of third party content can do regardless of if the third party guys fix their issues (put in iframe!).

Here are the most important performance issues along with recommended solutions.

9 HTTP requests, 52 kB transferred over the wire, and 107 kB of JavaScript (uncompressed) is a lot of content for a single widget.
Recommendations:

Concatenate these three scripts: JS_Libraries, widgetjsvars, and omnidiggthis. (eliminates 2 HTTP requests)

Run Page Speed’s “Defer loading JavaScript” feature and see how much of the JavaScript is not used. If it’s sizable, delete it. (This feature is currently broken in the latest version of Page Speed, but a fix is imminent.) (eliminates ?? kB)

Optimize the images – widget-logo.png and get-widget.png can both be reduced by ~3 kB. (eliminates ~6 kB)

Sprite widget-logo.png and shade-com.png. (eliminates 1 HTTP request)

The widget’s scripts block the main page’s content from downloading. Looking at the waterfall chart, the main page includes the image “digg-waterfall.png” (row 10). Notice how this image doesn’t start downloading until after all the scripts for the Digg widget are received.
Recommendations:

Instead of loading the scripts using document.write, load them without blocking other downloads. The scripts are already suffering from race condition behavior, as evidenced by this comment from widgetjsvars:

1: if (!digg || !digg.$) setTimeout(function() { diggwb(obj); }, 200); //hack for IE not loading scripts that are included via document.write until it decides too

So it probably isn’t too much work to avoid race conditions when making all the scripts load asynchronously.

The widget’s stylesheet blocks the main page from rendering in IE.
Recommendations:

Instead of loading the stylesheet using document.write, load it via JavaScript as described in 5d dynamic stylesheets.

Four of the resources aren’t cached long enough.
Recommendations:

Two scripts aren’t cacheable because they have an expiration date in the past. widgetjs is part of the snippet, so it can’t have a long expiration date, but something like an hour or a day would be better than a date in the past. widgetjsvars could have a far future expiration date since its URL is specified in widgetjs.

The three images are only cacheable for a day. They should have a far future expires header since the image filename can be change if it’s modified.

There are approximately 30 inefficient CSS selectors. Because this stylesheet is part of the main page, the selectors will cause the overall page to render more slowly when these selectors are applied to the elements in the main page.
Recommendations:

Reduce the performance impact by simplifying these CSS selectors.

Four of the resources have ETags which reduces their cacheability.
Recommendations:

Configure the ETags for widget.css, widget-logo.png, get-widget.png, and shade-com.png.

This is just the first example. What else would you like to see Steve tackle?

Mozilla JägerMonkey: Method based JIT + Trace based JIT = speed

Dion Almaer — Sat, 27 Feb 2010 05:05:58 +0000

David Anderson: "TraceMonkey has rocket boosters, so it runs really fast when the boosters are on, but the boosters can’t always be turned on."

Opera's new JIT compiler Carakan is doing well as we just posted. What is Mozilla doing with TraceMonkey? A lot.

Mozilla JägerMonkey adds method based JIT (of V8 and Nitro fame) to keep the boosters on.

We learn more from David Mandelin and David Anderson.

Steve’s Browser Performance Wishlist

Dion Almaer — Mon, 22 Feb 2010 11:12:05 +0000

Steve Souders has put together a browser performance wishlist that answers the question "What are the most important changes browsers could make to improve performance?"

He also notes a couple of new ideas that he is very much behind:

SPDY

SPDY is a proposal from Google for making three major improvements to HTTP: compressed headers, multiplexed requests, and prioritized responses. Initial studies showed 25 top sites were loaded 55% faster. Server and client implementations are available, and some other organizations and individuals have completed server and client implementations. The protocol draft has been published for review.

FRAG

The idea behind this “document fragment” tag is that it be used to wrap 3rd party content – ads, widgets, and analytics. 3rd party content can have a severe impact on the containing page’s performance due to additional HTTP requests, scripts that block rendering and downloads, and added DOM nodes. Many of these factors can be mitigated by putting the 3rd party content inside an iframe embedded in the top level HTML document. But iframes have constraints and drawbacks – they typically introduce another HTTP request for the iframe’s HTML document, not all 3rd party code snippets will work inside an iframe without changes (e.g., references to “document” in JavaScript might need to reference the parent document), and some snippets (expando ads, suggest) can’t float over the main page’s elements. Another path to mitigate these issues is to load the JavaScript asynchronously, but many of these widgets use document.write and so must be evaluated synchronously.

A compromise is to place 3rd party content in the top level HTML document wrapped in a FRAG block. This approach degrades nicely – older browsers would ignore the FRAG tag and handle these snippets the same way they do today. Newer browsers would parse the HTML in a separate document fragment. The FRAG content would not block the rendering of the top level document. Snippets containing document.write would work without blocking the top level document. This idea just started getting discussed in January 2010. Much more use case analysis and discussion is needed, culminating in a proposed specification. (Credit to Alex Russell for the idea and name.)

Souders blasts off 5 in a row

Dion Almaer — Sun, 14 Feb 2010 15:32:52 +0000

Steve Souders has done a weekly set of posts on browser quirks that have caught his eye. Here's the roundup:

Missing schema double download

Internet Explorer 7 & 8 will download stylesheets twice if the http(s) protocol is missing. Interestingly, I rarely see anyone use "//stevesouders.com/images/book-84x110.jpg" but here is a case to watch out for it.

document.write scripts block in Firefox

Scripts loaded using document.write block other downloads in Firefox. Unfortunately, document.write was invented. That problem was made a bzillion times worse when ads decided to use document.write to insert scripts into the content publisher’s page. It’s one line of code:

PLAIN TEXT

JAVASCRIPT:

document.write('

media=print stylesheets

Stylesheets set with media=”print” still block rendering in Internet Explorer.

I’m surprised browsers haven’t gotten to the point where they skip downloading stylesheets for a different media type than the current one. I’ve asked some web devs but no one can think of a good reason for doing this. In the meantime, even if you have stylesheets with media="print" you might want to follow the advice of Page Speed and YSlow and put them in the document HEAD. Or you could try loading them dynamically.

dynamic stylesheets

You can avoid blocking rendering in IE if you load stylesheets using DHTML and setTimeout.

A few weeks ago I had a meeting with a company that makes a popular widget. One technique they used to reduce their widget’s impact on the main page was to load a stylesheet dynamically, something like this:

PLAIN TEXT

JAVASCRIPT:

var link = document.createElement('link');

link.rel = 'stylesheet';

link.type = 'text/css';

link.href = '/main.css';

document.getElementsByTagName('head')[0].appendChild(link);

Most of my attention for the past year has been on loading scripts dynamically to avoid blocking downloads. I haven’t focused on loading stylesheets dynamically. When it comes to stylesheets, blocking downloads isn’t an issue – stylesheets don’t block downloads (except in Firefox 2.0). The thing to worry about when downloading stylesheets is that IE blocks rendering until all stylesheets are downloaded1, and other browsers might experience a Flash Of Unstyled Content (FOUC).

Speculative background images

Chrome and Safari start downloading background images before all styles are available. If a background image style gets overwritten this may cause wasteful downloads.

When my office-mate, Steve Lamm, pointed out this behavior to me, my first reaction was “that’s wasteful!” I love prefetching, but I’m not a big fan of most prefetching implementations because they’re too aggressive – they err too far on the side of downloading resources that never get used. After my initial reaction, I thought about this some more. How frequently would this speculative background image downloading be wasteful? I went on a search and couldn’t find any popular web site that overwrote the background-image style. Not one. I’m not saying pages like this don’t exist, I’m just saying it’s very atypical.

On the other hand, this speculative downloading of background images can really help performance and the user’s perception of page speed.

DOMTiming interface being implemented in Chromium and Firefox

Dion Almaer — Fri, 12 Feb 2010 11:23:17 +0000

When testing our applications for performance, how do we go about timing various parts and pieces? Normally we are forced to manually get Date.now / new Date().getTime() times and futz around. It isn't possible to get at timing info for important lifecycle events (e.g. can only start timing once JS is loaded.

This is where the Web Timing API comes into play, which seems to be in the early process of implementation in Chromium and Firefox.

With the API there is access to window.timing and element.timing.

An example of using the global window.timing:

PLAIN TEXT

JAVASCRIPT:

var navigation = timing[0];
if (navigation.document.load> 0) {
var page_load_time = navigation.document.load - navigation.navigationStart;
if (navigation.navigationType == navigation.NAVIGATION_LINK) {
console.log (page_load_time);
}
}

Within a timing result you have access to a slew of information:

PLAIN TEXT

JAVASCRIPT:

interface DOMTiming {
readonly attribute unsigned longlong fetchStart;
readonly attribute unsigned longlong domainLookupStart;
readonly attribute unsigned longlong domainLookupEnd;
readonly attribute unsigned longlong connectStart;
readonly attribute unsigned longlong connectEnd;
readonly attribute unsigned longlong requestStart;
readonly attribute unsigned longlong requestEnd;
readonly attribute unsigned longlong responseStart;
readonly attribute unsigned longlong responseEnd;
readonly attribute unsigned longlong load;
readonly attribute unsigned longlong parseStart;
readonly attribute unsigned longlong parseEnd;
};

I am sure that Steve is happy :)

Canvas Benchmark

Dion Almaer — Thu, 28 Jan 2010 11:09:10 +0000

The Freeciv.net crew has benchmarked a path in their canvas game. It is one data point, and tests more than just Canvas itself because a lot of code is running in the game. Thus, it ends up testing the union of a particular JavaScript path and the rendering of the canvas.

Here are the results:

With Bespin we had slightly different results, and the bulk of the bottleneck was in the blitting of the canvas. Optimizations were made to canvas over the initial phase of Bespin so the various browsers would leap frog each other. Good times :)

Pure CSS bar charts as a simple API

Chris Heilmann — Fri, 15 Jan 2010 13:19:05 +0000

I am right now working on a high-traffic project that will run in a sandbox that doesn't allow me to pull third party JavaScript or use canvas/Flash. Yet I need to generate bar charts from a set of data.

The solution to me was to create the charts from HTML using CSS. There have been some solutions for this problem already but I wanted something very simple and easy to maintain. Hence all the markup I am using is this:

PLAIN TEXT

XML:

>
>>400>>
>>20>>
>>30>>
>>233>>
>

Instead of hard-coding any of the trickery necessary I wrote a PHP script to generate the HTML, the styles and do all the math. So all that is needed to render one of the charts is the following code:

PLAIN TEXT

PHP:

$values = '400,20,30,233,312,78,20,67';
$height = 100;
$width = 600;
$bargap = 0;
include('csscharts.php');
?>

Of course, this can also be turned into a web service - you can get the chart with the following URL:

http://icant.co.uk/csscharts/csscharts.php?values=400,20,30,233,312,78,20,67&height=100&width=600&bargap=0

And if you specify JSON as the format you get it with a callback to a function called csscharts:

http://icant.co.uk/csscharts/csscharts.php?values=400,20,30,233,312,78,20,67&format=json

PLAIN TEXT

JAVASCRIPT:

csscharts(
{
chart:
"
"
}
)

That way you can use it in JavaScript:

PLAIN TEXT

JAVASCRIPT:

You can see some demos here, get detailed info about the CSS trickery used and of course download the code on GitHub.

WebKit Inspector Audit View

Dion Almaer — Wed, 30 Dec 2009 11:35:09 +0000

The WebKit Inspector tool has a new tab, the Audits panel which aims to be like Google PageSpeed and YSlow! built right in.

A little crude, but good to see:

Performance of data URIs

Michael Mahemoff — Sun, 13 Dec 2009 00:46:25 +0000

Rob Flaherty has done a little experimenting with data URIs and performance. The study only looked at Firefox 3.5 with empty cache, but the results were interesting for the questions they raise as much as the answers the provide.

He used a CSS file with 31 images and converted them all to data URIs using Nick Zakas's CSSEmbed. For an extra variant, he used DURIS to extract the data URIs to a separate CSS file so that the basic CSS in becomes much smaller and therefore loads much faster.

All three scenarios yielded similar performance - with HTTPWatch, the times were 1.35s, 1.13s, and 1.13s. So the two data URI scenarios were only marginally better. But more interestingly, a commenter from South Africa chimed in with wildly different results (using Firebug): 4.04s, 1.44s, 1.92s. The implication is clear: latency can be a big factor in some cases, and round-tripping to fetch 31 images is going to bring that out.

Another interesting factor is perceived speed. This is, after all, arguably the most important thing when it comes to performance. Although the two data URI scenarios completed in the same speed, the second setup felt faster because it got the images out of the way and allowed the main stylesheet to load fast. The data URI images were then loaded in a stylesheet at the bottom of the page, after a script had been loaded.

The study also raises questions about data URI loading. A commenter posted a waterfall showing the data URI images take significantly longer to load than regular downloaded images. This is the kind of thing that needs more research and why the study is interesting because of the questions it raises.

Rob also posted a study recently on background-image performance in various browsers.

The End of Days for “View Source”?

Michael Mahemoff — Thu, 03 Dec 2009 15:40:20 +0000

"View Source is your friend", we've learned countless times as web developers. It's something special about web development that we can seamlessly lift the covers on anything we see and find out how the sausage is made. And it gets even better with great tools to interrogate the system in real-time. This capability has helped us evolve practices and patterns, and contributed to the production of many a fine browser extension and Greasemonkey script.

Our friend might sadly be going the way of the blink tag. View Source has always worked because the standard development model is to put up some static Javascript files on a server somewhere and serve them out. That model is changing though; performance is a very hot topic right now, and View Source is playing victim to that trend.

Google's Let's Make the Web Faster initiative is a case in point. Here is a multi-pronged attack on the performance issue, involving new protocols (SPDY), tools (PageSpeed), browser improvements (Chrome), on-demand loading (Closure), and - most pertinent - compression techniques (Closure again). And we ain't seen nothing yet; there's every reason to believe Google will soon be putting its money where its mouth is, by rewarding faster sites with higher rankings. (I guess I was alone in assuming they always did that.) While performance should always be a consideration for site owners, a dangling SEO carrot would no doubt convert the best of intentions into the most concrete of actions.

Site owners can't (much) control factors such as browser choice and browser efficiency, but they can get their own performance-fu in order, and code compression is low-hanging fruit. Looking at the top 20-ranked sites, filtering only English-language sites, I found the very top guys (Google, Facebook, Yahoo, YouTube, Windows Live) predominately using Javascript compression, with the others not using it much, if at all. I expect most of them to be using it in the next 12-24 months.

In addition to compression, there is also obfuscation. With Javascript being used for more complex tasks and replacing desktop functionality, more companies will be wondering about all that intellectual property sitting in plain view. (And let's not mention the security-by-obscurity fans, who will also go this route, however flawed their thinking.)

Is it all bad? No. There's a much healthier respect for plain old semantic HTML these days, which means HTML documents should be View Sourcier now than ever before. (CSS, not so much, with compression also likely to grow.) If I had to choose between one or the other, I'd take clear HTML over clear Javascript. Also, we will probably find the majority of sites in the long tail won't feel the need to do anything about their code (but the ones who do make efforts are probably the ones with the most interesting things to look at). Also, the aforementioned tools, which do things like XHR sniffing, will help us to understand from a "black box" perspective even if we can't peer into the code. Hopefully, there will also be more attention paid towards Javascript beautifiers as well, to make sense of compressed code.

I can't speculate on the waning of View Source without mentioning the tremendous counter-balancing act played out by Open Source. From the get-go, open source has played a vital role in Ajax, with individuals and companies releasing code for all sorts of reasons. Most of this is library and framework code, rather than production-ready applications, so we might lose something there, but we still have much to gain from the ever-growing corpus of code that's out there, free to be studied and incorporated into our own applications.

Google Analytics unblocks the Web w/ Async support

Dion Almaer — Wed, 02 Dec 2009 11:21:01 +0000

I heard a huge cheer from the Internet today and found that Google Analytics has launched async mode which finally unclogs our browsers from blocking.

Steve Souders must have had the loudest cheer, and wrote up his view:

The pain of loading JavaScript files is that they block the page from rendering and block other resources from downloading. There are workarounds to these problems. Chapter 4 of Even Faster Web Sites describes six techniques for Loading Scripts Without Blocking. One of those, the Script DOM Element approach, is the technique used in the new Google Analytics async pattern. Google Analytics’ ga.js file is a perfect example of a script that should be loaded asynchronously - it doesn’t add any content to the page, so we want to load it without blocking the images and stylesheets that give users what they really came to see.

Improved Uptime

What happens if a script takes a long time to load, or fails to load? Because scripts block rendering, users are left staring at an empty page. Google Analytics has an amazing infrastructure behind it, but any resource, especially from third parties, should be added cautiously. It’s great that the GA team is evangelizing a pattern that allows the web site to render while ga.js is being downloaded.

To get going, simply change your ga script code to follow the pattern:

PLAIN TEXT

JAVASCRIPT:

var _gaq = _gaq || [];
_gaq.push(['_setAccount', 'UA-XXXXX-X']);
_gaq.push(['_trackPageview']);
(function() {
var ga = document.createElement('script');
ga.src = ('https:' == document.location.protocol ?
'https://ssl' : 'http://www') +
'.google-analytics.com/ga.js';
ga.setAttribute('async', 'true');
document.documentElement.firstChild.appendChild(ga);
})();

It’s extremely cool to see this pattern being evangelized for such a major piece of the Internet. A few items of note:

Obviously, you have to replace “UA-XXXXX-X” with your ID.
Since ga.js is being loaded asynchronously, there has to be a way for web site owners to couple their desired GA functions with the code when it finishes loading. This is done by pushing commands onto the Google Analytics queue object, _gaq.
Once all your callback commands are queued up, the ga.js script gets loaded. This is wrapped inside an anonymous function to avoid any namespace conflicts.
Inside the anonymous function is where we see the Script DOM Element approach being used - with two nice improvements. A ’script’ element is created and its SRC is set to the appropriate ga.js URL. Looking ahead to support of asynchronous scripts in HTML5, the ‘async’ attribute is set to ‘true’. Very nice! The main benefit of this is it tells the browser that subsequent scripts can be executed immediately - they don’t have to wait for ga.js. The last line adds the script element to the DOM. This is what triggers the actual download of ga.js. In most of my code I do document.getElementsByTagName(”head”)[0].appendChild, but that fails if the document doesn’t have a head element. This is a more robust implementation.

Statsy – find those wasted bytes with a bookmarklet

Chris Heilmann — Mon, 30 Nov 2009 12:14:27 +0000

Stoyan Stefanov is all about the performance of web products. One small tool that gives you a bit of insight as to where you can optimize is a new bookmarklet he released today called statsy.

If you run statsy on a web site you get the following insights:

JS attributes (e.g. onclick) - this is the sum of all onclick, onmouseover and so on including the attribute names. So for example is 11 characters (bytes) of JavaScript attributes code

CSS style attributes - the sum of all style="..."

Inline JS - the sum of all the contents of all script tags (excluding the tag itself)

Inline CSS - sum of all