Де стискальний проксі може заощадити пропускну здатність
Розмістіть скорочення вмісту перед обмеженим клієнтським каналом і враховуйте якість зображень, наявне стиснення та видимість 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 регулює належну обробку вмісту; вона окрема від шифрування транспорту. Оцінюйте вигоду за фактичним вмістом і шляхом шифрування, а не за старою демонстрацією зображень відкритим текстом.