Где компресијски прокси може да уштеди пропусни опсег
Поставите смањење садржаја пре ограничене клијентске везе и узмите у обзир квалитет слика, постојећу компресију и видљивост 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 уређује сагласно руковање садржајем; одвојена је од транспортног шифровање. Процените користи према стварном садржају и путу шифровања, а не према старој демонстрацији слика у отвореном тексту.