Если у вас есть сервер с большим, чем на вашей машине, лимитом трафика, а вы много скачиваете на свою локальную машину, то для экономии трафика при загрузках используйте coproxy. Файл будет качаться сервером и передаваться сжатым на клиент, где будет декомпрессироваться. Все подробности в README в архиве.
Лучше бы делал проксю которая вообще весь трафик жмёт, навроде того что в мобильной Опере, но для любого браузера. Такое норм на сильно лимитных тарифах, чисто выйти в интернет почитать без видео, или в роуминге
Вот тут люто поркчую, открытый аналог оперы мини, пригодился бы, тут аналоговнет. Только суть не только в сжатии трафика, и к любому браузеру прикрутить такое вряд ли получится, т.к. у оперы мини по сути браузерный движок на сервере работает (и tls там же терминируется, кстати), а клиенту передаётся уже итоговый отрендеренный результат в оптимизированном виде (со своим форматом разметки), такой вот тонкий клиент. Короче, надо запилить что-то типа browsh, где браузерный движок работает на сервере, а клиенту даётся итоговый результат, но только не в консольке, а с нормальными шрифтами (пусть из стандартной поставки) и картинками (опционально - пожатыми). Надо это даже не столько для экономии трафика, сколько чтобы не грузить и исполнять у себя сотни мегабайт js и прочий современный веб-содом, которому надо последний процессор, и десятки ГБ памяти для одного браузера. А просто сжатие было, например, в opera mobile, которая работала локально (на presto ещё), и она даже что-то жала (когда https не было повсеместно), но опера-мини была эффективней, и по потреблению трафика в том числе. Кстати и у гугла тоже было такое для мобильного хромога, можешь погуглить “Data Compression Proxy”, его к другим браузерам (десктопным) прикручивали, но опять же, по тем же причинам до оперы-мини такому далеко, да и с https в любом случае сошло на нет.
Мне лень было реализовывать SOCKS и заботиться о большем кол-ве вещей, ибо это не запрос-ответ HTTP. Большая часть трафика в Интернете — HTTP, что у меня и реализовано. Если сайт редиректает HTTP на HTTPS, то будет прекрасно работать всё, но надо именно URL с HTTP использовать, ибо иначе я не смогу понять, какой сайт запрашивает клиент.
Тем более, сжатия даже в том случае, если сайт редиректает HTTP на HTTPS, можно добиться только на 7-м уровне.
В современном вебе почти весь трафик уже передается сжатым, веб-серверы отдают данные сжатые gzip/deflate, deflate нынче даже в websocket поддерживается, веб-кодерам ничего не нужно делать, потому как это фишка сервера и включается параметром.
Мобильная опера времен JavaME погоняла DOM под мобильные устройства с малым объемом памяти и пережимала картинки в шакальное качество, и наверное даже делала Server-Side Rendering чтоб не перекладывать на дохлое мобильное устройство исполнение JS для отображения сайта. Короч, опера делала много всякой работы.
Ну так вот с этим самым функционалом и было бы неплохо. Разве что server-side рендеринг лишний по причине достаточной мощности устройств. А пережимание в шакала весьма было бы неплохо, с религулировкой количества шакалов в изображении