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.
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.