RE: "Going fast on the Mobile Web" - input for MWABP?

I suppose one might considered it a good practice for an origin server to make use of the Accept-Encoding header as defined in RFC 2616 [1]. I have some doubts as to the benefits, which I'd like to share.

This header permits the client to declare its acceptance of 'gzip' and 'compress' streams, though I believe the former would be the more prevalent. The default encoding is 'identity', meaning that no compression or re-encoding is performed.

Unfortunately, clients have a tendency to mis-state their ability to accept encodings. For example, they may support gzip but not include that in the header, or they may use "*" in the header, which implies every encoding is accepted even if that is not truly the case.

Generally, if gzip is mentioned in the header, the client can be reasonably expected to accept such a compressed stream (gzipped as per RFC 1952, not the raw deflate format as per RFC 1951).

However, unless you are going beyond the normal standards of Web browsers and introducing such things as header compression, page-update deltas and other such interaction optimisation techniques, the benefits from gzipping a mobile payload are marginal. The additional processing overhead may not justify such marginal benefit.

This is particularly the case when delivering a rich presentation. A mobile page will be relatively simple in terms of its text content, and (hopefully) not too complex with respect to scripting (if present), and there will probably be a few images too. The image payload of a rich presentation will be the significant majority, and if JPEG is used, this majority portion of the data is already compressed.

Assuming you are delivering a rich presentation to a reasonably well implemented browser on a sufficiently capable device, it should be able to cache much of the (compressed) image data, significantly improving the mobile experience through subsequent reductions in delivery and latency. Not to mention the reduction in power usage because the network connection is not being used, and the device is not repeating a write to memory (which uses more power than reading).

Therefore, I think it should be obvious that the most beneficial approach would be to apply caching headers properly to images. This will have by far the greatest improvement in the mobile Web experience, and should be much less a problem to introduce than gzip (which, as I said, probably has only marginal benefit).

Fortunately, the best practice of using cache headers properly is already documented, so I think that should be enough.

I'm not saying that making use of gzip is irrelevant, just that it might not be as relevant as some people may think.

---Rotan.


[1] http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.3




-----Original Message-----
From: public-bpwg-request@w3.org [mailto:public-bpwg-request@w3.org] On Behalf Of Dominique Hazael-Massieux
Sent: 01 July 2008 09:38
To: public-bpwg
Subject: "Going fast on the Mobile Web" - input for MWABP?


Hi,

I have been researching whether we should recommend using gzip-ping
content or not in the Mobile Web Application Best Practices - I'm hoping
I'll have some concrete findings to share at some point, but I'm not
quite there yet.

In the meantime, I stumbled upon this presentation from Cloud Four
called "Going Fast on the Mobile Web":
http://www.slideshare.net/grigs/going-fast-on-the-mobile-web

where, based on some of the research they made on their own, they make
the following (paraphrased) recommendations (starting slide 41):
 1. use gzip compression
 2. Fewer included resources
 3. use aggressive caching 
 4. minimize file sizes 
 5. simple and valid markup 
 6. reduce DNS lookup
 7. avoid redirects
 8. limit cookies - in particular limit them to a domain different from
static resources (so that they don't weigh down the outgoing requests)

I think we cover already 2,3,4,5, 7 in BP1 and MWABP; 1 is still being
researched (and the data they provide didn't seem that conclusive to me,
FWIW); I'm not sure how much of 6 and 8 we've covered.

They also have further recommendations for post-iPhone devices (but
without much details):
 1. optimize JS performance
 2. Reduce DOM elements
 3. Javascript at bottom of page
 4. CSS in the head tag
 5. Lazy load components
 6. Use GET unless you need POST
 7. use JSON instead of XML
 8. Use hardware accelerated effects
I think we (at least try to) cover 1 and possibly 2; not sure what
advantage 3 provides; 4 is unclear too, but if they mean "include the
style directly in the page", I seem to remember we discuss it; not sure
what 5 is about, 6 would need some caviar about the semantics of GET vs
POST, I think we cover 7, and I'm not sure what 8 is supposed to cover.

Maybe the editors will find ideas of best practices to extract from the
above?

Regards,

Dom

Received on Tuesday, 1 July 2008 11:24:55 UTC