Here we have a library from Mobify (https://hacks.mozilla.org/2013/03/capturing-improving-performance-of-the-adaptive-web/
) that allows you to "capture" the HTML in the document before the browser parses it. You get a chance to manipulate the content to indicate which image assets should get loaded by the browser.
It's clear that there is a real problem in browsers today that the Mobify team is trying to solve: browsers do not understand which image assets are actually going to be needed for responsive pages, so they tend to try to download all of the assets, which is obviously wasteful and also harmful for performance.
But the solution provided here is actually much worse than just loading all the image assets. Here's what the capturing API does:
1. inject a plaintext tag very early in the document:
// Prevent the browser from downloading website resources
3. once the capture code loads, parses, and executes, create a child HTMLDocument which is used to parse everything after the plaintext tag in a new document context
4. invoke a callback in the main application that manipulates the document to enable/disable certain DOM elements
5. once the child HTMLDocument manipulation is complete, replace the main document's contents with this modified child document's contents
6. now the browser finally gets a chance to render some content to the screen
Let's dig a little deeper into what this means from a page load performance perspective. How much delay have we introduced to rendering the page as a result of loading the document this way? If we assume a mobile network round trip of 250 milliseconds and that we are loading mobify from a CDN, that's 750ms (DNS, TCP, request/response) blocking time before the browser even receives the first byte of mobify. Then it has to parse and execute mobify which will be non-zero time on a mobile device (let''s say 100ms), then it has to parse the document's contents in the child document (let's say another 100ms), then it has to copy the modified document's contents back to the main document (let's say another 100ms). So far we're already up over 1 second.
But it's actually even worse than this. None of the mobify code can execute until the main HTML has been fully downloaded. If the HTML document is large-ish (say, 10s of kB compressed), we're looking at incurring multiple additional round trips due to TCP congestion window growth before we even begin executing the mobify code. Let's say we incur 2 window growth round trips, for an additional 500ms.
Once this is all done, the stylesheet after the plaintext tag can finally begin downloading. That'll incur another round trip or 2, maybe more if we have to grow the TCP congestion window while downloading it.
Once this is done, after 2+ seconds on a mobile network, the browser can finally start rendering some content to the screen. It's hard to look at this as a performance win.
I am glad that the Mobify team is trying to improve responsive image efficiency, but solutions like this really need to live in the browser. The browser has so much more insight into the state of the document via its lookahead downloader, its ability to parse and render HTML in a streaming fashion, etc. It also doesn't have to download its parser from a web server (obviously), so none of those network delays are incurred by the browser's parser.
Update: to demonstrate the performance cost of using this solution on a high-latency (e.g. mobile) connection, here are two example pages, one that includes a single image, and another that includes the same image but loads the Mobify capture framework first. This isn't a real responsive page; the point of this demo is to show how much delay is added to fetching any of the assets on your page when you use Mobify capture.
First, the simple page:http://www.modspdy.com/nocapture_example.html
And now the same page loading Mobify capture first:http://www.modspdy.com/capture_example.html
Now, webpagetest results for each, using Chrome desktop on a high latency network (250ms round trip):
Simple page (without Mobify capture):http://www.webpagetest.org/result/130405_5N_THC/1/details/
the image asset starts downloading at 810ms.
And the page with Mobify Capture:http://www.webpagetest.org/result/130405_RK_TFB/1/details/
the image asset starts downloading at 2.57 seconds.
So we see that there is a roughly 1.75 second latency penalty as a result of using Mobify capture for this network configuration.