RE: Support for compression in XHR?

Le mercredi 10 septembre 2008 à 15:22 -0700, Sullivan, Bryan a écrit :
> OK, given that there are some variant opinions (on technical grounds)
> between the value of HTML and XHTML markup, and this is complicated by
> the reality of mobile browser implementations, there still is the
> practical limitation that a page that is so large as to require
> progressive rendering probably would not result in a good user
> experience anyway. 

I think that's a bit too strong a statement: on a GRPS network where you
typically get a ~3 kB/s bandwidth, this means that a 10kB page (which I
don't think can argued to be very large, esp. in the context of mobile
web application) will take 3s to download - having the first part of the
page shown after 1s instead of 3 certainly improves the user experience.

Taking the example of a larger page (30kB), which I don't think is
either extraordinary in the case of a mobile web application, we can see
that the decision to compress (assuming a compressed size of ~10kB) or
not is not trivial:
 * on a GPRS network, 30kB would take 10s to download, while dowloading
10 kB will take only 3s; that said, the uncompressed page would start
showing almost immediately, while the compressed page (I believe)
wouldn't show anything before these 3s are completed
 * on a Wifi network, 30kB would take hardly more time than the
compressed version, and decompressing 10K would add ~1/3s to the display
of the page on a mobile with limited CPU - so compression is not likely
beneficial

My current thinking is that compressing CSS and Javascript files above
2kB is almost always beneficial (since they are not affected by
progressive rendering), but I'm not sure recommending compression for
HTML/XHTML is necessarily a good idea.

Dom

Received on Thursday, 11 September 2008 07:26:00 UTC