Mahali ambapo proksi ya kubana inaweza kuokoa bandwidth
Weka upunguzaji wa maudhui kabla ya kiungo cha mteja kilichowekewa kikomo na zingatia ubora wa picha, ukandamizaji uliopo na uonekano wa HTTPS.
Weka upunguzaji wa maudhui kabla ya kiungo kilichowekewa kikomo kwenye njia ya majibu:
website → proxy transforms response → slow or metered link → browserIkiwa mwili wote umekwisha kupita kiungo hicho, upunguzaji wa baadaye hauwezi kurejesha baiti hizo. Kigeuzi cha mbali chenye mto wa juu wenye kasi zaidi kinaweza kutumikia lengo tofauti na proksi ya ndani kando ya kivinjari.
Ziproxy inaonyesha mbinu hii: mradi wake unaeleza proksi ya HTTP isiyo na akiba ambayo hukandamiza maudhui yanayofanana na maandishi kwa gzip na inaweza kutoa picha ndogo zenye ubora wa chini.
| Njia ya majibu | Upunguzaji unaowezekana |
|---|---|
| Usimbaji wa gzip | Bila hasara; kivinjari husimbua data asilia |
| Ukandamizaji upya wa picha | Unaweza kutupa maelezo na usifae wakati picha kamili ni muhimu |
| Maudhui yaliyokwisha kandamizwa kwa ufanisi | Nafasi ndogo ya upunguzaji zaidi |
| HTTPS CONNECT ya kawaida | TLS isiyo wazi huzuia ubadilishaji wa HTML au picha bila mpango mwingine wa kuaminika wa kufikia maandishi wazi |
Uchakataji na hatua ya ziada pia huchukua muda, kwa hivyo baiti chache hazihakikishi kukamilika kwa haraka. Akiba hutumia tena jibu lililohifadhiwa linalofaa; ukandamizaji unaweza kubadilisha jibu lililopatikana hivi karibuni bila kulihifadhi.
Mahali ambapo maudhui ya HTTP yanaonekana, heshimu Cache-Control: no-transform. Sera ya majibu ya no-transform husimamia utunzaji wa maudhui unaotii; ni tofauti na usimbaji fiche wa usafirishaji. Kadiria faida kutoka kwa maudhui halisi na njia ya usimbaji fiche, sio kutoka kwa onyesho la zamani la picha za maandishi wazi.