Hol takaríthat meg sávszélességet egy tömörítő proxy
Helyezze a tartalomcsökkentést a korlátozott klienshivatkozás elé, és vegye figyelembe a képminőséget, a meglévő tömörítést és a HTTPS láthatóságát.
Helyezze a tartalomcsökkentést a válaszútvonal korlátozott hivatkozása elé:
website → proxy transforms response → slow or metered link → browserHa a teljes törzs már áthaladt ezen a hivatkozáson, az utólagos kicsinyítés nem hozza vissza azokat a bájtokat. Egy távoli átalakító gyorsabb feltöltési útvonallal más célt szolgálhat, mint a böngésző melletti helyi proxy.
A Ziproxy szemlélteti a megközelítést: projektje egy nem gyorsítótárazó HTTP-proxyt ír le, amely gzip-pel tömöríti a szövegszerű tartalmat, és képes kisebb, alacsonyabb minőségű képeket előállítani.
| Válaszútvonal | Lehetséges csökkentés |
|---|---|
| Gzip kódolás | Veszteségmentes; a böngésző dekódolja az eredeti adatokat |
| Képek újratömörítése | Elvethet részleteket, és alkalmatlan lehet, amikor pontos képek számítanak |
| Már hatékonyan tömörített tartalom | Kevesebb hely a további csökkentéshez |
| Közönséges HTTPS CONNECT | Az átláthatatlan TLS megakadályozza a HTML vagy képek átalakítását egy másik megbízható, nyílt szöveghez való hozzáférési megoldás nélkül |
A feldolgozás és az extra ugrás időt is igényel, tehát a kevesebb bájt nem garantál gyorsabb befejezést. A gyorsítótárazás újrahasznál egy alkalmas tárolt választ; a tömörítés átalakíthat egy frissen letöltött választ anélkül, hogy tárolná.
Ahol a HTTP-tartalom látható, tartsa be a Cache-Control: no-transform szabályt. A no-transform válaszszabály irányítja a megfelelő tartalomkezelést; elkülönül a szállítási titkosítástól. A hasznot a tényleges tartalom és titkosítási útvonal alapján becsülje meg, ne egy régi, nyílt szövegű képes bemutató alapján.