Ku mund të kursejë gjerësi bande një proxy kompresimi
Vendosni reduktimin e përmbajtjes përpara lidhjes së kufizuar të klientit dhe merrni parasysh cilësinë e imazheve, kompresimin ekzistues dhe dukshmërinë e HTTPS.
Vendosni reduktimin e përmbajtjes përpara lidhjes së kufizuar në rrugën e përgjigjes:
website → proxy transforms response → slow or metered link → browserNëse trupi i plotë e ka kaluar tashmë atë lidhje, zvogëlimi i mëvonshëm nuk mund t'i rikuperojë ato bajt. Një transformator në distancë me një lidhje dalëse më të shpejtë mund të shërbejë një qëllim tjetër nga një proxy lokal pranë shfletuesit.
Ziproxy e ilustron këtë qasje: projekti i tij përshkruan një proxy HTTP pa cache që kompreson me gzip përmbajtje të tipit tekst dhe mund të prodhojë imazhe më të vogla me cilësi më të ulët.
| Rruga e përgjigjes | Reduktimi i mundshëm |
|---|---|
| Kodimi gzip | Pa humbje; shfletuesi dekodon të dhënat origjinale |
| Rikompresimi i imazheve | Mund të hedhë poshtë detaje dhe të jetë i papërshtatshëm kur imazhet e sakta kanë rëndësi |
| Përmbajtje tashmë e kompresuar në mënyrë efikase | Më pak hapësirë për reduktim të mëtejshëm |
| HTTPS CONNECT i zakonshëm | TLS i errët pengon transformimin e HTML ose imazheve pa një marrëveshje tjetër të besueshme për akses në tekst të pastër |
Edhe përpunimi dhe kalimi shtesë kërkojnë kohë, kështu që më pak bajt nuk garantojnë përfundim më të shpejtë. Cache-i ripërdor një përgjigje të ruajtur të përshtatshme; kompresimi mund të transformojë një përgjigje të sapo marrë pa e ruajtur.
Ku përmbajtja HTTP është e dukshme, respektoni Cache-Control: no-transform. Politika e përgjigjes no-transform rregullon trajtimin konform të përmbajtjes; ajo është e ndarë nga enkriptimi i transportit. Vlerësoni përfitimet nga përmbajtja aktuale dhe rruga e enkriptimit, jo nga një demonstrim i vjetër me imazhe në tekst të pastër.