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 Tuesday, 9 September 2008 20:55:31 UTC