Sıxlaşdıran proksinin bant genişliyini harada qənaət edə biləcəyi
Məzmun azaltmasını məhdud müştəri bağlantısından əvvəl yerləşdirin və şəkil keyfiyyətini, mövcud sıxlaşdırmanı və HTTPS görünürlüyünü nəzərə alın.
Cavab yolunda məzmun azaltmasını məhdud bağlantıdan əvvəl yerləşdirin:
website → proxy transforms response → slow or metered link → browser
Əgər tam gövdə artıq həmin bağlantıdan keçibsə, onu sonradan kiçiltmək o baytları geri qaytara bilməz. Daha sürətli yuxarı axını olan uzaq çevirici brauzerin yanındakı yerli proksidən fərqli məqsədə xidmət edə bilər.
Ziproxy yanaşmanı göstərir: layihəsi mətn tipli məzmunu gzip edən və daha kiçik, aşağı keyfiyyətli şəkillər çıxara bilən keşləməyən HTTP proksisini təsvir edir.
| Cavab yolu | Potensial azalma |
|---|---|
| Gzip kodlaşdırması | İtkisiz; brauzer orijinal məlumatı deşifrə edir |
| Şəklin yenidən sıxlaşdırılması | Detalları itirə bilər və dəqiq şəkillər vacib olduqda uyğun olmaya bilər |
| Artıq səmərəli sıxlaşdırılmış məzmun | Əlavə azaltma üçün daha az yer |
| Adi HTTPS CONNECT | Qeyri-şəffaf TLS başqa etibarlı açıq mətn çıxışı tənzimlənməsi olmadan HTML və ya şəkil çevrilməsinin qarşısını alır |
Emal və əlavə keçid də vaxt aparır, ona görə daha az bayt daha sürətli tamamlanmaya zəmanət vermir. Keşləmə uyğun saxlanmış cavabı təkrar istifadə edir; sıxlaşdırma yeni alınmış cavabı saxlamadan çevirə bilər.
HTTP məzmunu görünən yerdə Cache-Control: no-transform qaydasına əməl edin. no-transform cavab siyasəti uyğun məzmun emalını tənzimləyir; bu, nəqliyyat şifrələməsindən ayrıdır. Faydaları faktiki məzmundan və şifrələmə yolundan təxmin edin, köhnə açıq mətn şəkil nümayişindən deyil.