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

On Fri, Jun 22, 2012 at 5:10 PM, Roy T. Fielding <fielding@gbiv.com> wrote:

> 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.
>

I'm sorry if this offends - it wasn't intended as a dig against HTTP.

The point is that the #1 performance impact in this test was compression,
which optional in HTTP, and that optional features are not used as widely
as they could be.

Mike




>
>
> ....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
>> ****
>>
>> ** **
>>
>
>