RE: Support for compression in XHR?

Usually only content that is compressible (primarily text-based) is compressed, since in the usual case web pages are served as a series of distinct HTTP requests for the base page (the original request URI), followed by requests for stylesheets, and other media assets (e.g. images, animation, video). Compression is applied to each request individually per server config (and of course the accept-encoding header of the client request).

Only in the case of a multipart response is there usually the chance to attempt compression on something that doesn't benefit from it. But in that case the server can also be configured to avoid compression since it's likely that the multipart package contains uncompressible page assets.

Further, in the mobile case, multipart responses are not common since it defeats local cache efficiency in reducing over-the-air traffic, and only improves the apparent latency for complex pages with a lot of assets (not a best practice for mobile anyway).

Best regards,
Bryan Sullivan | AT&T

-----Original Message-----
From: David Storey [mailto:dstorey@opera.com] 
Sent: Tuesday, September 09, 2008 4:12 PM
To: Dominique Hazael-Massieux
Cc: Sullivan, Bryan; public-bpwg
Subject: Re: Support for compression in XHR?


On 9 Sep 2008, at 22:54, Dominique Hazael-Massieux wrote:

>
> Le mardi 09 septembre 2008 à 10:13 -0700, Sullivan, Bryan a écrit :
>> I think you mean in " in what circumstances should you send back
>> gzipped content " that "you" is the server.
>
> Indeed.
>
>> In that case, the decision on whether to use compression or not is an
>> application issue.
>
> I disagree.
>
>> There are various generic/valuable reasons to compress (e.g. to save
>> bandwidth/cost/latency) but in the end it usually just comes down to
>> server configuration (most HTTP servers are configured to
>> automatically serve HTTP compressed content) and client support (most
>> HTTP stacks support HTTP compression and should announce this).
>
> That is true when serving static pages, but when building pages
> dynamically, in most cases the decision to serve content as gzipped or
> not is back into the application's court (e.g. using
> ob_start("ob_gzhandler") in PHP); this can also be achieved using e.g.
> filters provided by some servers.
>
> Regardless of whether this is set in the server configuration or in  
> the
> application code, surely this is relevant to the "delivery of Web
> applications on mobile devices", and thus to the Mobile Web  
> Application
> Best Practices, isn't it?
>
> In particular, given that it is not obvious that it is beneficial
> performance-wise to compress any content, even if the client supports
> it, I think we ought to research and document in which cases it is
> usually beneficial.
>
> Cases where it is likely not beneficial:
> * small files (since it will take CPU and memory to uncompress a file
> that might be hardly smaller than the original file)
> * HTML pages where gzipping might get in the way of progressive
> rendering (although I'm not absolutely sure)
> * on high bandwidth networks, the gain in downloading time might be
> lower than the time needed to uncompress (e.g. I think ungzipping 30 K
> takes 1s on a Palm, which means that sending a 30K file gzipped to a
> Palm is not worth it on a network of more than 240 Kb/s)

I'd also imagine it isn't beneficial when over x% of a page weight is  
either images, sound or video files, as they are usually as  
efficiently compressed as possible anyway.  If there is little text/ 
mark up content in relation to media files the overhead is likely more  
than the benefit.  I assume more CPU means more battery too?

I'm not sure about situations where the content will already be  
compressed, such as when using Opera Mini or another browser with a  
client-server approach.  That wont make any difference in this case as  
the server will handle everything - In Opera Mini's case sending OBML  
back to the client.
>
>
> Dom
>
>
>

David Storey

Chief Web Opener,
Product Manager Opera Dragonfly,
Consumer Product Manager Opera Core,
W3C Mobile Web Best Practices Working Group member

Consumer Product Management & Developer Relations
Opera Software ASA
Oslo, Norway

Mobile: +47 94 22 02 32
E-Mail: dstorey@opera.com
Blog: http://my.opera.com/dstorey

Received on Wednesday, 10 September 2008 13:32:46 UTC