Къде компресиращ прокси може да спести трафик
Поставете намаляването на съдържанието преди ограничената клиентска връзка и отчитайте качеството на изображенията, съществуващата компресия и видимостта на HTTPS.
Поставете намаляването на съдържанието преди ограничената връзка по пътя на отговора:
website → proxy transforms response → slow or metered link → browserАко цялото тяло вече е преминало тази връзка, смаляването след това не може да върне тези байтове. Отдалечен преобразувател с по-бърз възходящ канал може да служи на друга цел от локален прокси до браузъра.
Ziproxy илюстрира подхода: проектът описва HTTP прокси без кеширане, което компресира с gzip текстово съдържание и може да създава по-малки изображения с по-ниско качество.
| Път на отговора | Възможно намаляване |
|---|---|
| Gzip кодиране | Без загуби; браузърът декодира оригиналните данни |
| Повторно компресиране на изображения | Може да изгуби детайли и да е неподходящо, когато точните изображения са важни |
| Вече ефективно компресирано съдържание | По-малко място за допълнително намаляване |
| Обикновен HTTPS CONNECT | Непрозрачният TLS предотвратява преобразуването на HTML или изображения без друга доверена схема за достъп до открит текст |
Обработката и допълнителният преход също отнемат време, така че по-малко байтове не гарантират по-бързо завършване. Кеширането използва отново подходящ запазен отговор; компресията може да преобразува новополучен отговор, без да го запазва.
Където съдържанието по HTTP е видимо, спазвайте Cache-Control: no-transform. Политиката на отговор no-transform управлява съобразната обработка на съдържание; тя е отделна от шифроването на транспорта. Оценявайте ползите от действителното съдържание и пътя на шифроване, а не от стара демонстрация с изображения в открит текст.