#7 This post is part of the Velocity countdown series. Stay tuned for the articles to come.
Some time ago Google talked about using a sort of lazy JavaScript evaluation which especially helps mobile devices. The idea was to comment out a chunk of JavaScript you don't need right away and serve it this way. Later, when you need it, you get the content of the commented code and eval() it. More here and here.
At the last Fronteers conference I had the pleasure of chatting with Sergey Chikuyonok, who is so great and (among other things) is responsible for coming up with zen coding and writing a bunch of deep articles on image optimization for Smashing Magazine. So he told me he experimented with similar lazy HTML evaluation and it proved to be incredibly helpful for mobile devices. Not only the overall experience is faster but the initial rendering happens sooner and we all know how important that is.
Sergey is a busy person and chances of him writing about his experiment in English seemed pretty low at the time, so I decided to do an experiment on my own and see what happens. Meanwhile he did write about it so I forgot all about my findings, but here they are now.
Long document
I took one big HTML document - The adventures of Sherlock Holmes, which is half a megabyte or about 200K gzipped. Page A is the document as-is, plus some JS for measurements.
Page B (lazy) is the same page but with about 95% of its content commented out. The remaining 5% is a whole chapter so there's plenty of time to deal with the rest while the user is reading. After onload and a 0-timeout I take the commented markup (conveniently placed in <div id="lazy-daze">) and strip the comments. Then take the "unwrapped" time after another 0-timeout to let the browser repaint the DOM and regain control.
The overall skeleton of the lazy page is like so:
<!doctype html>
<html>
<body>
<h1>THE ADVENTURES OF<br/>
SHERLOCK HOLMES</h1>
...
... to chat this little matter over with you.</p>
<div id="lazy-daze">
</div>
<script>
window.onload = function () {
setTimeout(function(){
var daze = document.getElementById('lazy-daze'),
inner = daze.innerHTML;
daze.innerHTML = inner.substring(4, inner.length - 4);
setTimeout(function(){
}, 0);
}, 0);
};
</script>
</body></html>
Experiment
All the files are here:
http://www.phpied.com/files/lazyhtml/
We have the plain normal document - http://www.phpied.com/files/lazyhtml/sherlock-plain.html
And the lazy one - http://www.phpied.com/files/lazyhtml/sherlock-lazy.html
In order to run the experiment you just go to
http://www.phpied.com/files/lazyhtml/start.html
And click "Go nuts". This will load each of the two documents 20 times and take a few time measurements. "Go nuts" again and you'll get 20 more data points.
The time measurements I take are:
- "plain" - unload to onload of the base version
- "lazy" - unload to onload of the lazy version NOT including unwrapping it. This should be quicker than the plain version
- "unwrapped" - unload to onload plus time to unwrap and rerender - this is expected to be bigger than "plain" because the browser has to render twice and is therefore doing more work
- DOM loaded "plain" - unload to DOMContentLoaded instead of onload
- DOM loaded "lazy"
Then I take the same 5 measurements but instead of starting at unload of the previous page, it starts at the top of the documents, as soon as a timestamp can be taken with JavaScript. This will exclude DNS, establishing connection, time to first byte...
Results
Here are the results from back when I did the experiment originally last year, using iPhone 2 (with iOS 3.2 or thereabouts)
I ran this experiment over Wifi and again over 3G.
First striking thing - it takes the about the same time to load the plain old page over Wifi and over 3G. For the smaller, "lazy" document, there is a difference, but there's virtually none for the plain base page. The guess here is that the rendering and its cost in terms of memory and CPU is far greater than the actual download time. In other words it takes longer to render than it does to download an HTML. At least in this class of phones. This guess is confirmed when you look at the time from the top of the documents, when the request overhead is removed:
With or without the request time - it's all pretty much the same.
The next striking thing - and how about that lazy document! It renders 3-4 times faster than the whole plain document. Not bad.
And one more surprise - lazy+unwrap time is less than the plain old document. Now that's interesting. It appears faster to split the task into two and do the whole double-rendering, which should've been slower because it's extra work. I guess that poor phone really chokes on the long document.
The same I found is true in Firefox, but almost the difference is negligible.
iPhone 4
I repeated the experiment tonight on iPhone 4 and wifi. And boy, is there a difference. What used to take 13 seconds is now under 3s.
The lazy + unwrap time is more than the plain time, which was to be expected.
Rendering that initial lazy document is still 2-3 times faster that waiting for the whole document.
The numbers:
- 2765 plain (2014 DOM)
- 1268 lazy
- 2995 lazy+unwrap
Ignoring the request overhead:
- 2200 plain (1421 DOM)
- 715 lazy
- 2423 lazy+unwrap
And one last run/observation - on the 3G and iPhone 4 there isn't much benefit of lazy-evaluation and empty cache. The request seems much more expensive. unload to onload 4.9s where document top to onload is 2.5. When the request overhead is out of the picture than lazy eval wins again - 1.7s compared to 2.5s
Parting words
- Lazy HTML FTW?
- Who the heck loads an entire book in a page?! Well it may happen. It may not be a whole book, but just a lot of markup. The entire book gzipped was 219K. A hefty document, but have you seen some of those news sites?
- Possible use case - blog comments. Lots and lots of blog comments. Or posts.
- If you're going to lazy-load something and get it with an ajax request, why not save yourself the request and ship with another chunk of html
- This was a simple layout task. Just a bunch of text. I'm guessing there could be much more complicated pages and layouts to render. And rendering is what takes the time it seems.
- Drawbacks a plenty because of the hidden content - accessibility, SEO.
Thoughts? Anyone want to run the test on Android or any other phone/device/tab/pad/whathaveyou? The guess is that the newer/powerful the device the smaller the difference. But it will be nice to know.
