Mailing List Archive
tlug.jp Mailing List tlug archive tlug Mailing List Archive
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]Re: [tlug] Acid drop on mobile?
- Date: Sat, 16 Feb 2008 02:27:08 +0900
- From: "Stephen J. Turnbull" <stephen@example.com>
- Subject: Re: [tlug] Acid drop on mobile?
- References: <47B4DAC2.3050308@articlass.org> <20080215041454.GC1392@lucky.cynic.net> <b4d277190802142218i3f0078ebg2dc09f5acee12e0a@mail.gmail.com> <871w7e7jzb.fsf@uwakimon.sk.tsukuba.ac.jp> <47B5495C.5060301@simon-cozens.org> <87y79m5zan.fsf@uwakimon.sk.tsukuba.ac.jp> <47B59FD3.9030303@simon-cozens.org>
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.
- References:
- [tlug] Acid drop on mobile?
- From: Dave M G
- Re: [tlug] Acid drop on mobile?
- From: Curt Sampson
- Re: [tlug] Acid drop on mobile?
- From: Edmund Edgar
- Re: [tlug] Acid drop on mobile?
- From: Stephen J. Turnbull
- Re: [tlug] Acid drop on mobile?
- From: Simon Cozens
- Re: [tlug] Acid drop on mobile?
- From: Stephen J. Turnbull
- Re: [tlug] Acid drop on mobile?
- From: Simon Cozens
Home | Main Index | Thread Index
- Prev by Date: Re: [tlug] Acid drop on mobile?
- Next by Date: Re: [tlug] (OT) Anyone know of a used sun server shop in Akihabara?
- Previous by thread: Re: [tlug] Acid drop on mobile?
- Next by thread: Re: [tlug] Acid drop on mobile?
- Index(es):
Home Page Mailing List Linux and Japan TLUG Members Links