W3C home > Mailing lists > Public > ietf-http-wg@w3.org > April to June 2012

Re: Performance implications of Bundling and Minification on HTTP/1.1

From: Roy T. Fielding <fielding@gbiv.com>
Date: Fri, 22 Jun 2012 17:10:43 -0700
Message-Id: <0E6EADDD-374D-4F1E-B608-E64D9B3929B1@gbiv.com>
Cc: Henrik Frystyk Nielsen <henrikn@microsoft.com>, HTTP Working Group <ietf-http-wg@w3.org>, Howard Dierking <howard@microsoft.com>
To: Mike Belshe <mike@belshe.com>
HTTP predates gzip and cookies. The notion that such a choice had anything to do with optional features is just silly. It is optional because it barely even worked in practice until 1999 and certainly wasn't feasible as a default until a few years after that as CPU capability increased.

....Roy


On Jun 22, 2012, at 3:55 PM, Mike Belshe <mike@belshe.com> wrote:

> 
> 
> On Fri, Jun 22, 2012 at 10:18 AM, Henrik Frystyk Nielsen <henrikn@microsoft.com> wrote:
> We just published a blog [1] analyzing the performance implications of content optimizations such as bundling and minification on the performance of web pages. The data shows that by applying bundling and minification along with compression and pipelining it is possible to get significant gains in the time it takes to get the content necessary to render a page as well as the overall time it takes to download the data.
> 
>  
> 
> Not only does optimizing the content save bytes but it also has savings in the number of requests and responses that need to be processed as well as faster render times due to being able to retrieve the HTML, CSS, and JS up front. In the test evaluated, the speedup was from 638 ms (uncompressed, unbundled, unminified, and not pipelined) down to 146 ms for the equivalent compressed, bundled, minified, and pipelined content. However, by just looking at the data necessary to lay out the page (HTML, CSS, and JS but not images), the time went from 631 ms to 126 ms with the images being finalized within the remaining timespan from 126 to 146 ms.
> 
>  
> 
> It is the hope that this data can contribute to providing a baseline for evaluating HTTP/2.0 proposals compared to how an efficient HTTP/1.x implementation can perform while leverage optimizations throughout the stack to provide better user experience.
> 
> 
> Thanks, Henrik.
> 
> One point this article proves to me is just why protocol features must be mandatory.  I hope HTTP/2.0 learns from this data.
> 
> To illustrate - look at how important gzip was in the performance measured here.  If we consider the maximum benefit in all of these test cases (reduced PLT from 638 to 146ms) - 93% of that benefit is accomplished with gzip alone (no pipelines, no bundles, no minification, no spdy, nothing!).
> 
> This is why so many protocol writers are adamantly against optional features.   If gzip were mandatory in HTTP/1.1, 93% of the benefit of this test would be achieved for everyone today.  Instead, enabled by optional compression, we know from other research** that ~1/3 of all compressable resources lack compression, and over SSL about half of compressable resources lack compression.  We'd be able to stop testing the uncompressed case for sure!
> 
> An interesting test would be to measure if pipelining, bundling, and minification without gzip can outperform gzip alone.  (spoiler alert - nope! :-)
> 
> Mike
> 
> ** https://developers.google.com/speed/articles/web-metrics
> 
> 
>  
> 
>  
> 
> Comments welcome!
> 
>  
> 
> Thanks,
> 
>  
> 
> Henrik
> 
>  
> 
> [1] http://blogs.msdn.com/b/henrikn/archive/2012/06/17/performance-implications-of-bundling-and-minification-on-http.aspx
> 
>  
> 
> 
Received on Saturday, 23 June 2012 00:13:32 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Saturday, 23 June 2012 00:13:41 GMT