- From: Dominique Hazael-Massieux <dom@w3.org>
- Date: Tue, 01 Jul 2008 13:40:55 +0200
- To: Rotan Hanrahan <rotan.hanrahan@mobileaware.com>
- Cc: public-bpwg <public-bpwg@w3.org>
Le mardi 01 juillet 2008 à 07:24 -0400, Rotan Hanrahan a écrit : > 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. I think that while this is most likely true for mobile web pages, when considering mobile web applications, the equation becomes a bit more complicated - you may actually be hitting large javascript files, or large data set retrieved through AJAX operations. I think there are 2 key questions to consider when deciding whether something should be sent gzipped or not (if the browser supports it, obviously): * the amount of time saved by downloading less data must be superior to the amount of time taken to decompress the data; the first depends on the compression rate and the bandwidth considered, the second on the performance of the CPU. I'm still trying to collect data on these parameters to see if there are good thumb rules we could give in the MWABP * resources that are served compressed cannot be rendered progressively (i.e. as data come in through the pipes), creating a perceived latency from the user perspective, so should probably be avoided for technologies that can use progressive rendering; typically, gzipping a javascript file is likely more interesting than gzipping a big HTML file, since that would prevent the browser from starting to render it before it completed the download More data on this later, hopefully. Dom
Received on Tuesday, 1 July 2008 11:42:18 UTC