Gdzie proxy kompresujące może oszczędzić przepustowość
Umieść redukcję treści przed ograniczonym łączem klienta i uwzględnij jakość obrazów, istniejącą kompresję oraz widoczność HTTPS.
Umieść redukcję treści przed ograniczonym łączem na ścieżce odpowiedzi:
website → proxy transforms response → slow or metered link → browserJeśli cała treść już przeszła przez to łącze, późniejsze zmniejszenie nie odzyska tych bajtów. Zdalny transformator z szybszym łączem nadrzędnym może służyć innemu celowi niż lokalne proxy obok przeglądarki.
Ziproxy ilustruje to podejście: jego projekt opisuje niebuforujące proxy HTTP, które kompresuje w gzip treści tekstowe i może tworzyć mniejsze obrazy o niższej jakości.
| Ścieżka odpowiedzi | Możliwe zmniejszenie |
|---|---|
| Kodowanie gzip | Bezstratne; przeglądarka dekoduje oryginalne dane |
| Ponowna kompresja obrazów | Może odrzucić szczegóły i być nieodpowiednia, gdy liczą się dokładne obrazy |
| Treść już wydajnie skompresowana | Mniej miejsca na dalsze zmniejszenie |
| Zwykłe HTTPS CONNECT | Nieprzezroczysty TLS uniemożliwia przekształcanie HTML lub obrazów bez innego zaufanego rozwiązania dostępu do tekstu jawnego |
Przetwarzanie i dodatkowy skok również zajmują czas, więc mniej bajtów nie gwarantuje szybszego zakończenia. Pamięć podręczna ponownie wykorzystuje odpowiednie zapisane odpowiedzi; kompresja może przekształcić świeżo pobraną odpowiedź bez jej zapisywania.
Gdzie treść HTTP jest widoczna, przestrzegaj Cache-Control: no-transform. Polityka odpowiedzi no-transform reguluje zgodne postępowanie z treścią; jest oddzielona od szyfrowania transportu. Oceniaj korzyści na podstawie rzeczywistej treści i ścieżki szyfrowania, a nie starej demonstracji obrazów w tekście jawnym.