W3C home > Mailing lists > Public > public-bpwg@w3.org > September 2008

RE: Support for compression in XHR?

From: Dominique Hazael-Massieux <dom@w3.org>
Date: Wed, 10 Sep 2008 15:47:58 +0200
To: "Sullivan, Bryan" <BS3131@att.com>
Cc: public-bpwg <public-bpwg@w3.org>
Message-Id: <1221054478.19890.307.camel@localhost>

Le mercredi 10 septembre 2008 à 06:31 -0700, Sullivan, Bryan a écrit :
> 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.

Right, with the caveat "The Working Group is researching the conditions
under which compression should be recommended on mobile devices and is
looking for feedback on this topic."

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

My early research showed that under 1K, the benefits of compression are
in most real cases negligible. I think 2K is probably a good threshold.

> (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.

In practice, that isn't true though - most mobile browser simply don't
validate (or check well-formedness) before rendering the page. And in
fact, one of the arguments that is raised against XHTML (served as
application/xhtml+xml, i.e. supposedly parsed as XML) is that it
prevents (or should prevent) progressive rendering.

> (3) Not compressing based upon the speed of the serving network is an
> interesting optimization, but testing should validate the benefit,

FWIW, I did some rough testing that I reported upon a few weeks ago:
http://www.w3.org/2008/06/gzip-mobile/results.php (which I'm afraid is
not very easily interpretable)

I agree that it is a difficult to make optimization on a
request-per-request basis, but surely we could tell developers that if
most of their users come from such a network then they should do this,
or this if on another type of network. I don't expect that advice to be
practical for every developer out there, but hopefully sufficiently
practical to a fair number of developers even though.

But maybe this is going into too low-level details for the document
we're developing; I personally think we ought to do that analysis work,
since it seems to be not obvious that compress-by-default is necessarily
a good thing.

Received on Wednesday, 10 September 2008 13:49:19 UTC

This archive was generated by hypermail 2.4.0 : Friday, 25 March 2022 10:09:52 UTC