Wszystkie współczesne przeglądarki obsługują kodowane gzip odpowiedzi. W rzeczywistości, jeśli spojrzysz na ich żądania, będą one miały nagłówek, który mówi coś w stylu Accept-Encoding: gzip, co jest sposobem na przekazanie serwerowi, że mogą obsługiwać spakowane przez gzip odpowiedzi.
Ważną częścią jest to, że serwer może zwrócić zarówno gzip, jak i nieskompresowane odpowiedzi w zależności od istnienia i wartości tego nagłówka. Jeśli klient nie wyśle nagłówka Accept-Encoding, nie należy go kompresować. Jeśli klient go wyśle, możesz opcjonalnie zakodować odpowiedź za pomocą programu gzip. Nie cała zawartość musi być skompresowana, ponieważ może być już skompresowana i marnujesz cykle procesora. Obrazy JPEG są zwykle dobrym tego przykładem. Najprawdopodobniej IIS podejmuje również inteligentną decyzję i kompresuje tylko to, co jest konieczne, gdy jest to konieczne.
Możesz sprawdzić, czy IIS robi to, co powinien, patrząc na nagłówki odpowiedzi wracające z serwera i szukając nagłówka Content-Encoding: gzip. To mówi klientowi lub przeglądarce, że treść jest zakodowana przy użyciu kompresji gzip i powinna odpowiednio rozpakować.
Wszystkie żądania oparte na przeglądarce (np. AJAX/jQuery, zwykłe żądania) zostaną automatycznie zdekompresowane bez dodatkowego wysiłku ze strony użytkownika. Przeglądarka jest klientem odpowiedzialnym za określenie, czy może obsłużyć gzip i doda nagłówek Accept-Encoding, jeśli tak się stanie. Twój kod JavaScript otrzyma nieskompresowaną wersję w twoim module obsługi odpowiedzi.
TL; DR: Włączenie go jest zazwyczaj dobrym pomysłem i nie trzeba wykonywać dodatkowej pracy.
Dziękuję za odpowiedź. Wspaniała odpowiedź. To mi bardzo pomaga :) – user5075511