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

On Sat, 23 Jun 2012 00:55:11 +0200, Mike Belshe <mike@belshe.com> wrote:

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

Also, some HTTP requests are rewritten by proxies and anti-virus  
applications to disable compression, so compression will be used even less.

> An interesting test would be to measure if pipelining, bundling, and
> minification without gzip can outperform gzip alone.  (spoiler alert -
> nope! :-)
>

A set of tests with different permutations of these techniques would  
indeed be interesting to see.

Minification is something that can only be done by the content provider,  
in the general case, as it requires knowledge about future use of a  
resource. For that reason I don't think you can use minification when  
creating a HTTP/1.1 baseline to compare HTTP/2.0 against.

Bundling is problematic in two ways. If you dynamically bundle the  
resources needed, you will end up with non-reusable resources, which works  
great in cold testing as Karl points out, but not over a longer session.  
If you statically bundle the resources, you benefit in a longer session,  
but cold testing is going to perform worse than without bundling. A push  
mechanism would solve this in the protocol layer, but has its own set of  
issues to solve.

Reference reordering is, like minification, destructive to the content and  
can not be done safely in the protocol layer. Both push and hinting solves  
this (again, with its issues to solve).

/Martin Nilsson

-- 
Using Opera's revolutionary email client: http://www.opera.com/mail/

Received on Saturday, 23 June 2012 00:14:14 UTC