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