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

Received on Tuesday, 9 September 2008 21:12:30 UTC