Hacker News Reader

Comment by AceJohnny2 | Hacker News Reader

https://en.wikipedia.org/wiki/Netscape#Netscape_Internet_Ser...

> Netscape ISP is a dial-up Internet service once offered at US$9.95 per month. The company serves web pages in a compressed format to increase effective speeds up to 1300 kbit/s (average 500 kbit/s). The Internet service provider is now run by Verizon under the Netscape brand. The low-cost ISP was officially launched on January 8, 2004. Its main competitor is NetZero. Netscape ISP is no longer actively marketed, but for a time its advertising was aimed at a younger demographic, e.g., college students, and people just out of school, as an affordable way to gain access to the Internet.

View on HN

Reminds me of Opera Mini [1] utilizing Opera’s compression servers (which really helped with capped mobile data plans a few years back) or Google Web Light [2] which I have heard might be similar

[1] http://en.wikipedia.org/wiki/Opera_Mini

[2] https://en.wikipedia.org/wiki/Google_Web_Light

I used to be involved with an ISP-specific product which was basically a plain-old HTTP proxy that would ensure everything is compressed with gzip at max settings and which downscaled images.

For dial up, it worked well. For everything else the added latency that came with re-enconding reduced subjective connection speed considerably unless you were lucky to hit the server's cache.

It's unfortunate how many of these things won't work so well with SSL everywhere.

At one point I toyed with the idea of a setup that'd rely on keeping a cache reasonably coherent between two sides of a slow link, but it'd be most effective if it was shared, but it's a non-starter unless it's only shared between people who'd be happy with MITM'ing their SSL connections for the sake of getting more of their connections.

Basically if both sides have a decent sized cache, on a cache miss you can re-request the resource from the origin but instead of returning the full page compare it to the cache entries you know the other side also has and produce a diff, and return just the compressed diff. It also overcomes bad cache settings etc., as long as the slow link between the caches is the primary performance limit of course.

(To guard against the caches going out of sync, you can of course return a hash, and let the cache on the "client side" force a refresh if it does)

If I ever find myself on a really slow connection again, maybe I'll test it with a VPN to a VPS.

Opera Mini doesn't just compress web pages. They run Presto (their OG web engine) headless on the backend, pre-render the pages, and push THAT to the device. It doesn't just conserve bandwidth but also the CPU power.

Amazon Silk works the same way. I think it's the default browser for Kindle devices.

Reply on news.ycombinator.com