Fast dialup HTML Compression


I have been checking out this new highspeed dialup stuff (NetZero and now Telus is offering it) and found a lot of not so impressive things about it. Most of it works by inserting a commercial compression server between the dialup router and the squid box and having customers install licensed decompress-on-the-fly software.
The server compresses html, mail, attachments and even jpg files. What makes me wonder is that jpg is lossy, and the system reduces quality to about 40% to compress the files further. There goes those nice photos you sent…
I tried a couple compress your html programs that shrunk the code about 10 or 12% max. It might compress Front Page by a lot more but so could any Grade 9 with wordpad…
Has anyone ever tried this service, and if so what do you think?


What is your indication that quality of image is reduced? Not all files compress the same. Take a handful of different file type and throw them into a zipfile, then use Winzip and look at the “Ratioâ€


I was looking for some sort of option for the poor suckers in rural areas stuck on concentrator lines. Typical connections are 26400.
I don’t like the concept that evry time you send or recieve an attachment, it’s lossy compressed. The consumer doesn’t know that…

Reps from a ‘certain phone company’ are calling around trying to sign people up and about a dozen have come into my service with some really bad stories (they were led to believe they could download music faster, that there were no restrictions on connection time and worse, they found out after getting the phone bill they were calling a toll number to connect!)

I do some pretty tight coding anyway, but without compromising the quality of images our index page only compresses from 7900 bytes to 7300 bytes. That’s not going to translate into 5 to 6X normal speed, probably couldn’t even tell the difference!


Is this really the case? Is it looking into each packet, seeing if it’s a part of an SMTP or POP3 stream, and compressing like that?

I’m sure they probably do weird JPEG stuff in http traffic, but I doubt they would do that for stuff that isn’t embedded in a webpage.

I’d think it was just looking at each chunk of traffic and trying to compress. It should be content-neutral, and should be lossless.

I mean, you can’t run a lossy compression on text, so why do you think they would run one on JPEGs? What if you renamed your JPEG as a *.exe file? you think they’d run a lossy compression on that? No. So ask yourself how they identify an attachment’s contents. They don’t. They just compress at the network or transport layers.


That was the explanations quoted in the white papers. You know that jpegs won’t compress. The compressions server takes imbedded jpeg and mail attached jpg and converts it to lower quality for smaller file size.
If your page contained (like mine) linked jpg I don’t know if that’s included in the process. I know that java feeds won’t be affected as they don’t seem to cache in squid.
It seems like a bonus technology (reduced traffic charges, faster transfer times) but with so much of the traffic being already compressed file types, I wondered if there is a real consumer benefit?
I’ve contacted one outfit and if the stuff is a couple thou or less I would install it as a premium service, but I was looking for some actual testimonials from end users. I kind of wonder if there’s a “seven second download saving” offset by some guys Pentium 133/32MB needing 30 seconds to process it thing. The makers are actually promoting to ISPs on the bandwidth saving/added revenue stream basis and saying little else.

I think like this: If you mix Pablum with the baby’s bottle, the kid can drink it a lot faster if you water it down thinner. I always regarded AOL/MSN as the pablum of the internet


This is an interesting note that is sort of related.

I’m using a VPN (Virtual Private Network) to connect to a remote server for file sharing. I can go into Windows performance monitor and see the Compression Rate and current KB/sec. I put the KB/sec of the network card and VPN connection and the compression rate all side by side. I then started accessing a large Excel file. The network card transfer rate peeks out at 30KB/Sec, but the VPN reports up in the 80Kb/Sec range. The compression peeks at 53%.

Interesting, no?


i once compress a .dmg file… but only after eating my Peanut Butter Cookies…