RE: Support for compression in XHR?

Dom,
Re
>  >  In that case, the decision on whether to use compression or not is an
>  > application issue.
>  
>  I disagree.
What I mean is that the application on the server (or the underlying server config, which is part of application execution environment) decides to compress based upon what the client says it supports and the value of compression in the response. This may not be an overt decision (the server config may just result in compression of any text-based content type). But as you point out it may be also an explicit act of the application in the way it uses the server platform, e.g. PHP.

Re " surely this is relevant to the "delivery of Web applications on mobile devices", and thus to the Mobile Web Application Best Practices ", I agree and that's why it is already present in the Mobile Web Applications Best Practices.

Re the use cases you mention in which compression could be avoided:

(1) Small files is the strongest case, and should be easy to code for (?). What would be a good lower threshold to recommend?

(2) Progressive-rendered pages are unlikely I think in the mobile case (if what you mean is a large page that is partially presented before the rest is received) since I think (at least for XHTML) the whole base page is needed (to be validated) before anything is presented. Page assets (images etc) are typically retrieved using separate requests so they don't factor into any consideration for compressing the base page.

(3) Not compressing based upon the speed of the serving network is an interesting optimization, but testing should validate the benefit, and the information about the serving network may not be available unless the client platform provides some API to get it (e.g. through DCCI or a specific web runtime API), and the client sends this info in some standardized header (not yet defined) or other method in a request. 

In general I think it's valuable to compress any text-based content with the possible exception (1) above.

Best regards,
Bryan Sullivan | AT&T
-----Original Message-----
From: Dominique Hazael-Massieux [mailto:dom@w3.org] 
Sent: Tuesday, September 09, 2008 3:54 PM
To: Sullivan, Bryan
Cc: public-bpwg
Subject: RE: Support for compression in XHR?

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)

Dom

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