压缩代理在哪里能节省带宽
把内容压缩放在受限的客户端链路之前，并考虑图片质量、已有压缩和 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 响应策略约束合规的内容处理；它与传输加密是两回事。应根据实际内容和加密路径来估计收益，而不是依据旧的明文图片演示。