Di Mana Proxy Kompresi Dapat Menghemat Bandwidth
Tempatkan pengurangan konten sebelum tautan klien yang terbatas dan perhitungkan kualitas gambar, kompresi yang sudah ada, dan visibilitas HTTPS.
Tempatkan pengurangan konten sebelum tautan terbatas pada jalur respons:
website → proxy transforms response → slow or metered link → browserJika seluruh isi sudah melewati tautan itu, memperkecilnya setelahnya tidak dapat memulihkan byte tersebut. Transformator jarak jauh dengan upstream lebih cepat dapat melayani tujuan berbeda dari proxy lokal di samping peramban.
Ziproxy mengilustrasikan pendekatan ini: proyeknya menjelaskan proxy HTTP tanpa cache yang meng-gzip konten seperti teks dan dapat menghasilkan gambar yang lebih kecil dengan kualitas lebih rendah.
| Jalur respons | Pengurangan potensial |
|---|---|
| Pengodean gzip | Tanpa kehilangan; peramban mendekode data asli |
| Kompresi ulang gambar | Dapat membuang detail dan tidak cocok ketika gambar yang tepat penting |
| Konten yang sudah terkompresi secara efisien | Lebih sedikit ruang untuk pengurangan lebih lanjut |
| HTTPS CONNECT biasa | TLS buram mencegah transformasi HTML atau gambar tanpa pengaturan akses teks polos lain yang tepercaya |
Pemrosesan dan lompatan tambahan juga memakan waktu, jadi byte yang lebih sedikit tidak menjamin penyelesaian lebih cepat. Cache menggunakan kembali respons tersimpan yang memenuhi syarat; kompresi dapat mentransformasi respons yang baru diambil tanpa menyimpannya.
Di mana konten HTTP terlihat, hormati Cache-Control: no-transform. Kebijakan respons no-transform mengatur penanganan konten yang patuh; ini terpisah dari enkripsi transport. Perkirakan manfaat dari konten sebenarnya dan jalur enkripsi, bukan dari demonstrasi lama gambar teks polos.