圧縮プロキシが帯域を節約できる場所
コンテンツ削減を制約のあるクライアント回線の手前に置き、画像品質、既存の圧縮、HTTPS の可視性を考慮します。
応答経路上で、制約のある回線の手前にコンテンツ削減を置きます：
website → proxy transforms response → slow or metered link → browser本文全体がすでにその回線を通過していれば、後から縮小してもそのバイトは取り戻せません。上流がより速い遠隔の変換器は、ブラウザの隣にあるローカルプロキシとは別の目的に役立ちます。
Ziproxy はこの手法を示しています。そのプロジェクトは、テキストに類する内容を gzip で圧縮し、より小さく低品質の画像を生成できる、キャッシュしない HTTP プロキシを説明しています。
| 応答経路 | 削減の可能性 |
|---|---|
| gzip 符号化 | 可逆であり、ブラウザが元のデータを復号します |
| 画像の再圧縮 | 細部を捨てることがあり、正確な画像が重要な場合には適しません |
| すでに効率的に圧縮された内容 | さらなる削減の余地が少なくなります |
| 通常の HTTPS CONNECT | 不透明な TLS は、別の信頼された平文アクセスの取り決めがない限り HTML や画像の変換を妨げます |
処理と余分なホップにも時間がかかるため、バイト数が少なくても完了が速くなるとは限りません。キャッシュは適格な保存済み応答を再利用します。圧縮は、新たに取得した応答を保存せずに変換できます。
HTTP コンテンツが見える場所では Cache-Control: no-transform を守ってください。no-transform 応答ポリシーは準拠したコンテンツ処理を定めます。これは転送時の暗号化とは別です。利点は実際のコンテンツと暗号化経路から見積もるべきで、昔の平文画像の実演からではありません。