کجا یک پراکسی فشرده‌ساز می‌تواند در پهنای باند صرفه‌جویی کند
کاهش محتوا را پیش از پیوند محدود مشتری قرار دهید و کیفیت تصویر، فشرده‌سازی موجود و قابلیت دیده‌شدن HTTPS را در نظر بگیرید.
کاهش محتوا را پیش از پیوند محدود در مسیر پاسخ قرار دهید:
website → proxy transforms response → slow or metered link → browserاگر پیکره کامل از پیش از آن پیوند گذشته باشد، کوچک‌کردن بعدی نمی‌تواند آن بایت‌ها را بازگرداند. یک تبدیل‌گر راه دور با مسیر بالادست سریع‌تر می‌تواند هدفی متفاوت از یک پراکسی محلی در کنار مرورگر داشته باشد.
Ziproxy این رویکرد را نشان می‌دهد: پروژه آن یک پراکسی HTTP بدون حافظه نهان را توصیف می‌کند که محتوای متنی را با gzip فشرده می‌کند و می‌تواند تصاویر کوچک‌تر با کیفیت پایین‌تر تولید کند.
| مسیر پاسخ | کاهش احتمالی |
|---|---|
| کدگذاری gzip | بدون اتلاف؛ مرورگر داده اصلی را رمزگشایی می‌کند |
| فشرده‌سازی دوباره تصویر | می‌تواند جزئیات را از دست بدهد و هنگامی که تصاویر دقیق اهمیت دارند نامناسب باشد |
| محتوایی که از پیش به‌کارآمدی فشرده شده است | فضای کمتر برای کاهش بیشتر |
| HTTPS CONNECT معمولی | TLS مات بدون ترتیب دیگرِ مورد اعتماد برای دسترسی به متن ساده، تبدیل HTML یا تصویر را ناممکن می‌کند |
پردازش و گام اضافی نیز زمان می‌برند، بنابراین بایت کمتر تضمین‌کننده پایان سریع‌تر نیست. حافظه نهان از پاسخ ذخیره‌شده واجد شرایط دوباره استفاده می‌کند؛ فشرده‌سازی می‌تواند پاسخ تازه دریافت‌شده را بدون ذخیره آن تبدیل کند.
جایی که محتوای HTTP دیده می‌شود، Cache-Control: no-transform را رعایت کنید. سیاست پاسخ no-transform شیوه مدیریت محتوای منطبق را تعیین می‌کند؛ از رمزنگاری انتقال جدا است. مزایا را بر پایه محتوای واقعی و مسیر رمزنگاری برآورد کنید، نه نمایش قدیمی تصاویر در متن ساده.