Skip to content

Wszystko o WordPressie, tworzeniu stron — i nie tylko

⚙️ Jak włączyć kompresję GZIP w WordPress: pełny przewodnik

⚙️ Jak włączyć kompresję GZIP w WordPress: pełny przewodnik

Strona ładuje się 4 sekundy i odwiedzający wychodzi. Brzmi znajomo? Najczęściej problem nie leży w hostingu ani w obrazkach. Strony po prostu ważą więcej, niż powinny, ponieważ serwer wysyła je „jak leżą", bez kompresji.

Kompresja GZIP zmniejsza rozmiar HTML, CSS i JavaScript o 60-80%, zanim dane polecą do przeglądarki. W przypadku WordPressa nie jest to ciężka wtyczka z mnóstwem ustawień, lecz jedna dyrektywa w konfiguracji albo zaznaczenie w panelu administracyjnym. Według danych W3Techs kompresję stosuje ponad 85% stron w internecie i jeśli Państwa strona nie jest wśród nich, tracą Państwo pozycje w wyszukiwarce i konwersję zupełnie niepotrzebnie.

Poniżej siedem skutecznych sposobów na włączenie GZIP: od ręcznej edycji.htaccess po kilka kliknięć we wtyczce. Na końcu pokażę, jak sprawdzić rezultat, i omówię częste pytania dotyczące zgodności z CDN, Brotli i pamięcią podręczną.

💡 Szybki przegląd:

  • Proszę dodać kod kompresji do .htaccess przez FTP
  • Proszę wpisać gzip on i gzip_types w nginx.conf
  • Proszę włączyć kompresję zaznaczeniem w W3 Total Cache lub WP Rocket
  • Proszę sprawdzić wynik w Chrome DevTools lub GiftOfSpeed

Czym jest kompresja GZIP i dlaczego jest potrzebna stronie WordPress

GZIP to algorytm kompresji działający na poziomie serwera: przed wysłaniem do przeglądarki „pakuje" pliki tekstowe do bardziej kompaktowej postaci. Przeglądarka rozpakowuje je w locie i renderuje stronę jak zwykle. Użytkownik nie zauważa różnicy, a ilość przesyłanych danych zmniejsza się wielokrotnie.

Schemat kompresji GZIP serwer przeglądarka

Co dokładnie jest kompresowane: kod HTML stron, arkusze stylów CSS, skrypty JavaScript, pliki XML, czcionki i SVG. GZIP nie dotyka obrazków, dla nich są osobne formaty kompresji (WebP, AVIF) i wtyczki optymalizacyjne.

Różnicę w liczbach łatwo zobaczyć w Chrome DevTools: ta sama strona przed kompresją i po niej różni się rozmiarem dwu-, trzykrotnie. Proszę pomnożyć to przez liczbę odwiedzających miesięcznie, a otrzymają Państwo poważną oszczędność transferu i czasu ładowania.

Ważny niuans: GZIP nie jest jedyną opcją. Współczesne serwery obsługują Brotli, algorytm Google, który kompresuje pliki tekstowe jeszcze o 15-25% lepiej niż GZIP. Ale Brotli nie jest dostępny na wszystkich hostingach, a GZIP działa wszędzie, włącznie z najstarszymi konfiguracjami. Dlatego zawsze warto zaczynać od GZIP, a Brotli włączać jako kolejny poziom, gdy baza jest gotowa.

Sposób 1: przez.htaccess na Apache

Najczęstszy scenariusz: strona działa na Apache i wszystko, czego potrzeba, to dopisać kilka linii do pliku .htaccess w katalogu głównym strony.

Gdzie znajduje się.htaccess. Proszę połączyć się z serwerem przez FTP (na przykład przez FileZilla) lub wejść do menedżera plików hostingu. W głównym folderze strony (tam, gdzie znajdują się wp-config.php oraz foldery wp-content, wp-admin) proszę znaleźć .htaccess. Proszę pobrać go na komputer, edytować będziemy lokalnie, aby w razie błędu szybko przywrócić poprzednią wersję.

Co dodać. Proszę otworzyć .htaccess w edytorze tekstowym (Notepad++, VS Code, Sublime Text) i dodać następujący blok PRZED liniami # BEGIN WordPress:

1<IfModule mod_deflate.c>
2 AddOutputFilterByType DEFLATE text/html text/css text/javascript
3 AddOutputFilterByType DEFLATE application/javascript application/x-javascript
4 AddOutputFilterByType DEFLATE application/rss+xml application/xml application/xhtml+xml
5 AddOutputFilterByType DEFLATE image/svg+xml image/x-icon
6 AddOutputFilterByType DEFLATE font/ttf font/otf font/opentype application/x-font-ttf
7 AddOutputFilterByType DEFLATE application/vnd.ms-fontobject
8
9 BrowserMatch ^Mozilla/4 gzip-only-text/html
10 BrowserMatch ^Mozilla/4.0[678] no-gzip
11 BrowserMatch bMSIE !no-gzip !gzip-only-text/html
12 Header append Vary User-Agent
13</IfModule>
Plik htaccess z kodem kompresji GZIP

Co tu się dzieje. Blok <IfModule mod_deflate.c> sprawdza, czy moduł mod_deflate jest włączony na serwerze (na większości hostingów jest włączony domyślnie). Dyrektywy AddOutputFilterByType DEFLATE wskazują, które typy plików kompresować. Linie BrowserMatch to obejście dla starych wersji Internet Explorera, zapobiegające błędom z gzip w IE6 i niższych. Header append Vary User-Agent nakazuje serwerom proxy uwzględniać przeglądarkę użytkownika podczas buforowania.

Proszę zapisać plik i wgrać go z powrotem na serwer z nadpisaniem. Wcześniej koniecznie proszę zrobić kopię zapasową oryginalnego .htaccess; jeśli strona przestanie działać, wystarczy przywrócić starą wersję i wszystko będzie działać jak wcześniej.

Jeśli po wgraniu strona wyświetliła błąd 500, proszę sprawdzić, czy w pliku nie ma zbędnych spacji lub znaków nowej linii przed <?php lub po znacznikach zamykających. Błąd w .htaccess całkowicie psuje stronę, dlatego zmiany lepiej wprowadzać pojedynczo i sprawdzać po każdej z nich.

Sposób 2: na serwerze NGINX

NGINX obsługuje kompresję inaczej niż Apache. Nie ma tu .htaccess, a wszystkie ustawienia wpisuje się w pliku nginx.conf lub w pliku konfiguracyjnym konkretnej strony (zazwyczaj w /etc/nginx/sites-available/).

Proszę dodać lub odkomentować następujące linie w sekcji http lub server:

1gzip on;
2gzip_vary on;
3gzip_min_length 1000;
4gzip_comp_level 6;
5gzip_types text/plain text/css text/javascript
6 application/javascript application/x-javascript
7 application/rss+xml application/xml application/xhtml+xml
8 image/svg+xml image/x-icon
9 font/ttf font/otf application/x-font-ttf
10 application/vnd.ms-fontobject;
11gzip_disable "MSIE [1-6]\.(?!.*SV1)";

Po zmianach proszę sprawdzić składnię konfiguracji poleceniem nginx -t i przeładować NGINX: sudo systemctl reload nginx.

Parametr gzip_comp_level 6 to kompromis między stopniem kompresji a obciążeniem procesora. Wartość 1 to minimalna kompresja, 9, maksymalna. W praktyce poziom 6 daje prawie taką samą oszczędność jak 9, ale zużywa zauważalnie mniej zasobów serwera.

Sposób 3: na serwerze IIS (Windows Server)

IIS to serwer webowy Microsoftu, używany na hostingach Windows. Włączenie kompresji odbywa się tu na dwa sposoby: przez interfejs graficzny lub wiersz poleceń.

Przez interfejs IIS. Proszę otworzyć IIS Manager. W sekcji „Komponenty" → „Usługi" proszę znaleźć „Kompresja". Proszę zaznaczyć pola „Włącz kompresję zawartości statycznej" i „Włącz kompresję zawartości dynamicznej". W panelu „Akcje" proszę kliknąć „Zastosuj".

Przez wiersz poleceń (jako administrator):

1:: Статическое сжатие
2appcmd set config /section:urlCompression /doStaticCompression:True
3
4:: Динамическое сжатие
5appcmd set config /section:urlCompression /doDynamicCompression:True

Kompresja statyczna buforuje już skompresowane wersje plików na dysku, co oszczędza czas procesora. Dynamiczna kompresuje odpowiedzi „w locie" i nadaje się do spersonalizowanych stron, ale obciąża procesor. W praktyce dla WordPressa włącza się oba tryby: statyka przejmuje CSS/JS, dynamika, HTML każdej strony.

Sposób 4: przez panel dostawcy hostingu

Większość współczesnych hostingów domyślnie włącza GZIP. Jeśli korzystają Państwo z cPanel, proszę wejść do sekcji „Optymalizacja strony" (Site Optimization) lub „Wydajność" (Performance) i poszukać przełącznika „Kompresja" lub „Compress content". Na Plesk ścieżka jest podobna: „Wydajność" → „Kompresja wyjścia".

Jeśli nie znaleźli Państwo przełącznika, proszę napisać do pomocy technicznej hostingu. To standardowe zapytanie, support odpowiada na nie w kilka minut i często włącza kompresję na poziomie serwera w ramach jednej odpowiedzi. Nie trzeba wyjaśniać, czym jest GZIP, wystarczy napisać „Proszę o włączenie kompresji GZIP dla mojej strony".

Sprawdzić, czy hosting już kompresuje strony, można przed jakimikolwiek zmianami; sposób opisano w sekcji „Jak sprawdzić, czy kompresja jest włączona" poniżej. Jeśli sprawdzenie wykaże, że GZIP działa, proszę pominąć wszystkie metody serwerowe i przejść do wtyczek tylko wtedy, gdy chcą Państwo zarządzać kompresją z panelu administracyjnego WordPressa.

Sposób 5: wtyczka W3 Total Cache

W3 Total Cache, jedna z najstarszych wtyczek do cache’owania w repozytorium WordPress, z milionem aktywnych instalacji i oceną 4,5 na WordPress.org. Kompresja GZIP jest w niej włączana osobnym checkboxem i nie wymaga zmian w plikach serwerowych.

Ustawienia kompresji HTTP w W3 Total Cache

Proszę zainstalować wtyczkę z repozytorium WordPress, przejść do Performance → Browser Cache i znaleźć sekcję „HTTP (gzip) compression". Należy zaznaczyć checkbox „Enable HTTP (gzip) compression" i zapisać ustawienia. Wtyczka sama doda potrzebne dyrektywy do .htaccess lub skonfiguruje reguły NGINX, w zależności od tego, na jakim serwerze działa strona.

  • Plusy: nie zmienia ręcznie plików serwerowych, milion instalacji potwierdza stabilność, kompatybilna z CDN i Brotli
  • Minusy: interfejs jest przeładowany opcjami, początkujący może łatwo zepsuć cache’owanie jednym nieodpowiednim checkboxem

Sposób 6: wtyczka WP Rocket

WP Rocket, premiumowa wtyczka do wydajności, która po aktywacji automatycznie dodaje reguły GZIP do .htaccess. Nie ma w niej żadnych ustawień kompresji, włącza się ona sama podczas instalacji.

  • Plusy: zero ręcznej pracy, kompresja włącza się automatycznie, wtyczka przy okazji rozwiązuje mnóstwo powiązanych zadań (cache’owanie, lazy loading, minifikacja)
  • Minusy: płatna (od 59 USD rocznie), dla samego GZIP przepłacanie jest nieuzasadnione

Jeśli mają już Państwo wykupioną wtyczkę WP Rocket do innych zadań, kompresja już działa. Jeśli zastanawiają się Państwo nad zakupem wtyczki wyłącznie dla GZIP, nie ma takiej potrzeby, .htaccess lub W3 Total Cache robią to samo za darmo.

Sposób 7: wtyczka WP Super Cache

WP Super Cache, bezpłatna wtyczka do cache'owania od Automattic (tych samych osób, które stoją za WordPress.com). Działa prościej niż W3 Total Cache: mniej ustawień, mniejsze ryzyko, że coś Pan/Pani zepsuje.

Ustawienia kompresji w WP Super Cache

Proszę zainstalować wtyczkę, przejść do Ustawienia → WP Super Cache → Zaawansowane (Advanced) i znaleźć opcję „Kompresuj strony, aby były szybciej dostarczane odwiedzającym". Proszę ją włączyć i zapisać.

  • Plusy: bezpłatna, prosty interfejs, stabilny kod od Automattic
  • Minusy: ustępuje W3 Total Cache pod względem funkcjonalności cache'owania, brak zaawansowanych ustawień typów kompresji

Jak działa kompresja GZIP w praktyce

Gdy przeglądarka żąda strony, wysyła nagłówek Accept-Encoding: gzip, deflate, br, co oznacza „rozumiem gzip, deflate i brotli, wyślij w dowolnym z tych formatów". Serwer widzi ten nagłówek, sprawdza, czy kompresja jest włączona dla żądanego typu pliku i jeśli tak, kompresuje odpowiedź oraz dodaje nagłówek Content-Encoding: gzip.

Przeglądarka otrzymuje skompresowane dane, rozpakowuje je w pamięci i renderuje stronę. Dla użytkownika wszystko dzieje się natychmiast, rozpakowanie gzip zajmuje ułamki milisekundy nawet na słabym urządzeniu mobilnym.

Mechanizm ten jest uniwersalny: działa tak samo dla Apache, NGINX, IIS i wszystkich wtyczek WordPress. Wtyczki nie wymyślają własnego sposobu kompresji, po prostu dodają te same dyrektywy serwera, które ręcznie wpisywaliśmy w pierwszych trzech sposobach.

Co pokazują Google PageSpeed Insights i GTmetrix

Oba serwisy, PageSpeed Insights i GTmetrix, sprawdzają obecność kompresji podczas każdego audytu i wyraźnie podświetlają problem, jeśli zasoby tekstowe są dostarczane bez GZIP.

Ostrzeżenie o kompresji w Google PageSpeed Insights

W PageSpeed Insights ostrzeżenie wygląda jak „Włącz kompresję tekstu" (Enable text compression) w sekcji „Możliwości" audytu. Lighthouse (silnik PageSpeed Insights) bezpośrednio szacuje potencjalną oszczędność w kilobajtach dla każdego nieskompresowanego zasobu. W GTmetrix analogiczne sprawdzenie to „Enable GZIP compression" w kategorii „Content".

Ważna kwestia: ani PageSpeed Insights, ani GTmetrix nie rozróżniają GZIP i Brotli na poziomie rekomendacji. Jeśli kompresja jest włączona którąkolwiek z tych metod, audyt pokaże zielony znacznik. Zatem do przejścia audytu wystarczy GZIP.

Jak sprawdzić, czy kompresja jest włączona

Trzy sposoby, od wizualnego do niskopoziomowego.

Sposób 1: Chrome DevTools. Proszę otworzyć stronę, nacisnąć F12, przejść do zakładki Network. Odświeżyć stronę, kliknąć dowolny wiersz i spojrzeć na zakładkę Headers. Proszę znaleźć wiersz Content-Encoding: gzip w sekcji Response Headers.

Nagłówek Content-Encoding gzip w Chrome DevTools

Tam również widać rzeczywisty i skompresowany rozmiar: w powyższym przykładzie strona ważyła 51,6 KB, a po kompresji 17,7 KB.

Porównanie rozmiaru pliku przed i po kompresji w Chrome DevTools

Sposób 2: testery online. GiftOfSpeed GZIP Test (giftofspeed.com/gzip-test) lub Check GZIP Compression (checkgzipcompression.net), wkleja Pan/Pani URL i otrzymuje werdykt oraz procent kompresji. Szybciej niż DevTools, jeśli trzeba sprawdzić cudzą stronę lub kilka stron pod rząd.

Sposób 3: curl z wiersza poleceń. Jeśli korzysta Pan/Pani z Linux/macOS lub WSL na Windows:

1curl -I -H &quot;Accept-Encoding: gzip&quot; https://вашсайт.com | grep Content-Encoding

Odpowiedź Content-Encoding: gzip oznacza, że kompresja działa. Pusta odpowiedź, że nie.

Krótkie wyjaśnienie wideo

Aby zamknąć temat od strony wizualnej, oto krótkie wideo pokazujące cały proces włączania GZIP przez .htaccess i weryfikację wyniku w Chrome DevTools:

⁉️🤔 Często zadawane pytania

Czy kompresja GZIP spowalnia serwer?

Wręcz przeciwnie. Tak, procesor zużywa zasoby na kompresję, ale jest to mikroskopijne obciążenie w porównaniu z zyskiem ze zmniejszenia ilości przesyłanych danych. Przy poziomie kompresji 6 (standardowy kompromis) procesor radzi sobie w ciągu milisekund. Jedyny scenariusz, w którym kompresja mogłaby być odczuwalna, to bardzo słaby VPS z 512 MB pamięci i tysiącami jednoczesnych odwiedzających. Ale w takiej sytuacji ma Pan/Pani poważniejsze problemy niż GZIP. W praktyce kompresja nie spowalnia serwera: typowa strona WordPress jest kompresowana w 2-5 milisekund, a oszczędność na transmisji danych przez sieć wynosi dziesiątki i setki milisekund dla każdego odwiedzającego. Kompresja jest zawsze korzystniejsza niż jej brak.

GZIP czy Brotli, co wybrać w 2026?

Proszę zacząć od GZIP, działa na każdym hostingu i jest obsługiwany przez wszystkie przeglądarki bez wyjątku. Brotli kompresuje zauważalnie lepiej, ale wymaga HTTPS (nie jest to problem w 2026) i wsparcia ze strony serwera. Jeśli hosting lub CDN (Cloudflare, BunnyCDN) obsługują Brotli, proszę włączyć je jako uzupełnienie GZIP. Większość nowoczesnych stron używa obu: serwer dostarcza Brotli tym przeglądarkom, które go rozumieją, a GZIP wszystkim pozostałym.

Czy kompresja GZIP jest kompatybilna z CDN?

W pełni. Sieci CDN, takie jak Cloudflare czy BunnyCDN, same kompresują treść na swoich serwerach brzegowych, często w Brotli, nawet jeśli Pana/Pani hosting go nie obsługuje. Jeśli strona jest już za Cloudflare, proszę sprawdzić, czy w sekcji „Speed" → „Optimization" włączona jest opcja „Brotli". W tym scenariuszu konfiguracja GZIP na poziomie serwera i tak jest przydatna jako fallback dla bezpośrednich żądań do serwera origin.

Mam wtyczkę do cache'owania, czy muszę osobno włączać GZIP?

To zależy od wtyczki. WP Rocket włącza GZIP automatycznie, W3 Total Cache osobnym checkboxem, WP Super Cache osobnym checkboxem. Proszę sprawdzić ustawienia swojej wtyczki, prawie wszystkie wtyczki do cache'owania mają opcję kompresji, ale nie wszystkie włączają ją domyślnie. Proszę nie polegać na założeniu „powinno działać", tylko zweryfikować to przez DevTools po konfiguracji.

Czy można kompresować strony przez functions.php?

Technicznie tak, przez funkcję PHP ob_start('ob_gzhandler'), ale nie zalecamy tego. Ta metoda kompresuje wyjście PHP i nie dotyczy plików statycznych (CSS, JS), które stanowią główną część ruchu. Kompresja serwerowa (Apache/NGINX) działa dla wszystkich typów plików i nie obciąża procesora PHP. Proszę pozostawić kompresję PHP na te rzadkie przypadki, gdy dostęp do konfiguracji serwera jest fizycznie niemożliwy.

Podsumowanie: co i kiedy włączać

GZIP to nie opcja typu „włącz i zapomnij", ale podstawowa higiena strony WordPress. Jeśli nie wie Pan/Pani w tej chwili, czy Pana/Pani serwer kompresuje strony, proszę otworzyć DevTools i sprawdzić nagłówek Content-Encoding. Jeśli go nie ma, proszę wrócić do sposobu 1 i dopisać trzy linijki w .htaccess.

Krótka matryca decyzyjna:

  • Strona na Apache i nie boi się Pan/Pani FTP → sposób 1 (.htaccess), 5 minut
  • Strona na NGINX i ma Pan/Pani dostęp do konfiguracji → sposób 2 (nginx.conf), 10 minut z weryfikacją składni
  • Z zasady nie dotyka Pan/Pani plików serwera → W3 Total Cache lub WP Super Cache, 2 minuty
  • Już płaci Pan/Pani za WP Rocket → proszę nic nie robić, kompresja działa od razu po instalacji
  • Nie chce Pan/Pani niczego konfigurować → proszę napisać do pomocy technicznej hostingu

Proszę sprawdzić wynik dowolnym z trzech powyższych sposobów i zamknąć tę kwestię na zawsze. To jedna z tych rzadkich optymalizacji, którą naprawdę robi się raz, a która oszczędza transfer i przyspiesza stronę przez lata, bez aktualizacji, subskrypcji i ponownych konfiguracji.