Mailing List Archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [tlug] Acid drop on mobile?



Simon Cozens writes:
 > Stephen J. Turnbull wrote:

 > > Simon, you know better than that.  For details, see Curt's posts.
 > 
 > I know all about mod_gzip, and use it on the server which perlbal proxies 
 > to. But I don't see your point - you seem to be disagreeing with me; my 
 > assertion was that whitespace compresses well. Does that mean that you are 
 > suggesting that whitespace doesn't compress well?

No, I'm suggesting that how well whitespace compresses is only a small
part of the story.  It's the old chestnut about optimization:  To get
O(n^2) to go to alpha*O(n^2), use an optimizing compiler.  To get
O(n^2) to go to O(n), use a better algorithm.  To get O(n^2) to go to
O(1), use a big ole table. :-)

People who are concerned about packet charges are going to want to go
belt and suspenders on compression.  How well whitespace gzips is only
relevant if what goes over the wire(less)? is gzipped.  The browser
may say "moshiwakenai!! no can do!", or the gateway may say "fsck,
fsck, I can handle it but keitai-kun can't (and anyway I make more
money)".  So doing your compression in layers is a good idea.

1.  Start with hand-crafted HTML, well-formatted for editing.

2.  Substitute inline stylesheets (but only if unique to the page or
you don't expect a second request from the browser or you know that
the browser doesn't cache) and other content for links and @includes.

3.  Squeeze out whitespace, remove redundant attributes, translate
human-readable classes and IDs to short identifiers, etc.

4.  Optionally minimize tags and stuff like that if you know the
browsers can handle it.

5.  gzip it.

Of those, 1-3 are sure wins even in practice, 4 is guaranteed by the
standard but you may be dealing with IE or software grown in a Kyushu
mushroom farm (and may be expensive for the browser to render, so it
may be a tradeoff), and counting on 5 strikes me as risk-loving.

 > Minifying (in the absence of any gzip considerations) is of course a good 
 > idea. But minifying and then gzip, which is what the OP seemed to be using 
 > Acid Drop to do,

AIUI that's just what Acid Drop does by default.

 > is not necessarily a useful use of CPU.

"Business model, business model, who's got the business model?"
People serving enough keitais and PDAs to care about CPU cycles spent
in compressing content going over the wire are not in it for the fun
of it.  CPU is cheap compared to packet charges, especially if the
result can be cached server-side.



Home | Main Index | Thread Index

Home Page Mailing List Linux and Japan TLUG Members Links