Strona działa wolno, a GTMetrix pokazuje ponad 130 żądań HTTP na stronę?

To nie jest abstrakcyjna liczba z raportu. Każde żądanie to odwołanie przeglądarki do serwera po plik: skrypt, arkusz stylów, obraz, czcionkę. Im jest ich więcej, tym dłużej odwiedzający patrzy na biały ekran. Według danych Portent opóźnienie ładowania z 0 do 3 sekund obniża konwersję o 2,5%. A każda dodatkowa sekunda powyżej to kolejne minus 4,4%.

Problem z żądaniami HTTP nie polega na tym, że występują. Polega na tym, że większość stron na WordPressie generuje ich wielokrotnie więcej, niż potrzeba. Poniżej pięć konkretnych kroków, które zmniejszają liczbę żądań bez przepisywania strony od zera.

💡 Szybki przegląd:

• Proszę usunąć nieużywane wtyczki i motywy, które generują zbędne żądania na każdej podstronie
• Proszę zoptymalizować obrazy: skompresować pliki, usunąć nieużywane grafiki, połączyć ikony w sprite'y
• Proszę połączyć CSS i JavaScript w 1-2 pliki oraz włączyć minifikację
• Proszę skonfigurować ładowanie odroczone dla skryptów blokujących renderowanie strony
• Proszę włączyć buforowanie i CDN, aby powracający odwiedzający nie ładowali strony od nowa

Krok 1. Proszę usunąć śmieci

Każda zainstalowana wtyczka ciągnie za sobą pliki. PHP, CSS, JavaScript, każdy z nich generuje żądanie HTTP podczas ładowania strony. Dwadzieścia wtyczek to już blisko setka żądań na samym starcie, przed załadowaniem treści.

Pierwsza rzecz do zrobienia to audyt. Proszę otworzyć Wtyczki → Zainstalowane wtyczki i szczerze odpowiedzieć: które z nich są krytyczne dla działania strony, a które wiszą „na wszelki wypadek"? Analizator SEO, który zainstalowali Państwo rok temu i otwierali dwa razy, to kandydat do usunięcia. Wtyczka do wstawiania ikon mediów społecznościowych również, jeśli i tak umieścili Państwo linki w stopce.

Osobną kategorią są wtyczki łączące się z zewnętrznymi serwerami. Czat na żywo, radio, powiadomienia push. Każda taka wtyczka generuje dodatkowe zewnętrzne żądania HTTP do serwerów stron trzecich. Proszę usunąć wszystko, bez czego strona działa. Potrzebują jej Państwo raz na miesiąc? Proszę zainstalować na jeden dzień i usunąć.

Ta sama zasada dotyczy motywów. W Wygląd → Motywy proszę trzymać tylko aktywny motyw i jeden zapasowy (na przykład domyślny Twenty Twenty-Five). Resztę do kosza.

Jeśli wtyczka jest potrzebna, ale tylko na konkretnej podstronie, proszę ładować ją wybiórczo. Służy do tego Asset CleanUp: Page Speed Booster, bezpłatna wtyczka z ponad 100 000 aktywnych instalacji i oceną 4,7 na WordPress.org.

Wtyczka skanuje stronę, pokazuje listę załadowanych CSS i JS oraz pozwala wyłączyć poszczególne pliki na konkretnych podstronach, typach wpisów lub w całej witrynie. Jeśli Contact Form 7 jest potrzebny tylko na stronie kontaktowej, proszę odznaczyć pozostałe podstrony, a jego skrypty nie będą się ładować tam, gdzie formularz nie jest używany.

🔗 Asset CleanUp na WordPress.org

Przy okazji proszę zoptymalizować bazę danych: po wyczyszczeniu wtyczek w tabelach zostają ustawienia i wpisy, które również warto usunąć. Proszę też sprawdzić uszkodzone linki, każde przekierowanie to dodatkowe żądanie HTTP.

Aby naocznie zobaczyć skalę problemu przed i po, proszę przetestować stronę w GTMetrix:

Pierwszy przebieg pokaże wyjściowy obraz: liczbę żądań, całkowity rozmiar strony, czas ładowania. Po każdym kroku z tego artykułu proszę powtarzać test. W ten sposób zobaczą Państwo, co konkretnie dało największy efekt.

Krok 2. Proszę zoptymalizować obrazy

Obrazy to główna „waga" przeciętnej strony WordPress. Według danych HTTP Archive na komputerach stacjonarnych grafiki zajmują około 44% całkowitej objętości strony. A każdy obraz to żądanie HTTP.

Proszę zacząć od usunięcia nieużywanych plików. W Media → Biblioteka proszę odfiltrować „Niepodpięte", to obrazy, które nie są przypisane do żadnego wpisu. Jeśli nie są używane w motywie ani w stopce, proszę je usunąć.

Następnie kompresja. Wtyczki takie jak WP Compress robią to automatycznie: podczas przesyłania obraz jest przepuszczany przez chmurowy optymalizator, kompresowany bez widocznej utraty jakości i konwertowany do WebP lub AVIF. Te formaty są zauważalnie lżejsze od JPEG przy tej samej jakości wizualnej: według danych Google WebP zmniejsza rozmiar pliku średnio o 25-35% w porównaniu z JPEG.

WP Compress ma ponad 10 000 aktywnych instalacji, ocenę 4,5 na 5 i ponad 1,1 miliona pobrań na WordPress.org. Pierwsze 100 obrazów bezpłatnie, wystarczy, aby ocenić różnicę.

🔗 WP Compress na WordPress.org

Sama kompresja nie zmniejsza liczby żądań HTTP. Ale obniża rozmiar każdego pliku, a tym samym czas jego przesyłania. W połączeniu z pozostałymi krokami daje to odczuwalny wzrost szybkości.

CSS sprite'y: jeden plik zamiast dziesięciu

Jeśli na stronie jest kilkanaście drobnych ikon (media społecznościowe, strzałki, gwiazdki oceny), każda ładuje się osobnym żądaniem. CSS sprite rozwiązuje ten problem: wszystkie ikony są zbierane w jeden plik, a CSS pokazuje potrzebny fragment.

Zasada działania: pięć obrazków to pięć żądań do serwera. Te same pięć obrazków zebrane w jeden sprite to jedno żądanie. Do tworzenia sprite'ów służą narzędzia online, takie jak CSS Sprite Generator. Potrzebna będzie podstawowa znajomość CSS, aby ustawić background-position dla każdej ikony.

Proszę zwrócić uwagę: jeśli serwer obsługuje HTTP/2, pliki są ładowane asynchronicznie w ramach jednego połączenia. W takim przypadku oszczędność ze sprite'ów jest mniej zauważalna. Ale w praktyce kilkanaście ikon w jednym pliku i tak ładuje się szybciej niż w dziesięciu osobnych.

Krok 3. Proszę połączyć i zminifikować CSS oraz JavaScript

Typowy obrazek na stronie WordPress: ponad 40 plików JS i ponad 20 CSS. Każdy to osobne żądanie HTTP. W sumie daje to ponad 60 odwołań do serwera tylko za skrypty i arkusze stylów, które ładują się przed wyświetleniem treści.

Minifikacja usuwa z plików wszystko, co zbędne: spacje, znaki nowej linii, komentarze. Plik staje się lżejszy, ale liczba żądań HTTP się nie zmienia.

Łączenie skleja kilka plików w jeden. Było pięć CSS-ów, zostały dwa (jeden dla pierwszego ekranu, jeden dla reszty). Pięć JS-ów, analogicznie. I zamiast dziesięciu żądań zostają dwa-trzy.

Najpopularniejszym bezpłatnym narzędziem do tego jest Autoptimize. Wtyczka z milionem aktywnych instalacji i oceną 4,7. W ustawieniach są trzy pola wyboru: optymalizować HTML, CSS i JS. Proszę włączyć wszystkie trzy, a otrzymają Państwo natychmiastowy rezultat.

Do bardziej precyzyjnej konfiguracji służy WP Rocket, rozwiązanie premium, które łączy pliki, minifikuje je i dodaje buforowanie w jednym interfejsie.

Po scaleniu koniecznie proszę sprawdzić witrynę w trybie incognito: czasami łączenie plików psuje układ. Jeśli coś się rozjedzie, proszę wyłączyć scalanie dla problematycznego pliku i pozostawić tylko minifikację.

🔗 WP Rocket na oficjalnej stronie

I jeszcze raz: scalanie plików nie jest panaceum. Jeśli wtyczka ładuje zewnętrzne skrypty z CDN (Google Fonts, reCAPTCHA, odtwarzacz YouTube), nie da się ich scalić. Można je jedynie odroczyć lub ładować asynchronicznie, o czym w następnym kroku.

Krok 4. Skonfiguruj skrypty blokujące renderowanie

Przeglądarka czyta stronę od góry do dołu. Gdy napotka <script src="..."> w <head>, zatrzymuje renderowanie, wczytuje cały skrypt i dopiero wtedy kontynuuje. Odwiedzający widzi w tym czasie pustą stronę.

Rozwiązanie: przenieść skrypty, które nie są potrzebne do wyrenderowania pierwszego ekranu, na dół strony lub dodać atrybut async/defer. Różnica:

• defer: skrypt ładuje się w tle, ale wykonuje się ściśle po sparsowaniu HTML i w kolejności podłączenia;
• async: skrypt ładuje się i wykonuje przy pierwszej możliwej okazji, kolejność nie jest gwarantowana.

Dla WordPressa istnieje darmowa wtyczka Async JavaScript. Dodaje ona async lub defer do wybranych skryptów za pomocą przejrzystego interfejsu. Działa od razu po instalacji, ale wymaga ostrożności: jeśli skrypt dodany przez async musi wykonać się przed innym, strona może przestać działać.

Bezpieczne podejście: przetestować na jednym skrypcie, sprawdzić witrynę w trybie incognito, a następnie przejść do kolejnego.

WP Rocket również potrafi opóźniać skrypty: zakładka File Optimization → Load JavaScript deferred. Proszę wybrać „Deferred" i dodać jQuery do wyjątków, ponieważ większość motywów i wtyczek WordPressa jest od niego zależna.

Rezultat: strona zaczyna się renderować wcześniej, nawet jeśli całkowita liczba żądań HTTP się nie zmieniła. Odwiedzający widzi treść, podczas gdy reszta skryptów doładowuje się w tle.

Krok 5. Włącz cache'owanie i CDN

Cache'owanie bezpośrednio redukuje liczbę żądań HTTP podczas kolejnych wizyt. Mechanika jest prosta: przeglądarka zapisuje pliki statyczne (CSS, JS, obrazy, czcionki) lokalnie. Przy następnym otwarciu strony zamiast wysyłać żądanie do serwera, pobiera plik z cache. Zero żądań HTTP dla tego pliku.

Cache'owanie serwerowe to kolejny poziom: serwer odsyła już złożoną stronę HTML, zamiast wykonywać dziesiątki zapytań PHP do bazy danych. Wtyczki do cache'owania (WP Rocket, Flying Press, W3 Total Cache) robią to automatycznie.

CDN (Content Delivery Network) to sieć serwerów na całym świecie. Zamiast pobierać pliki z Pana hostingu w Holandii dla odwiedzającego z Brazylii, CDN dostarcza je z najbliższego mu węzła. Dodatkowo dostawcy CDN często oferują kompresję, minifikację i optymalizację obrazów „od ręki".

Cloudflare to darmowa opcja, która pokrywa podstawowe potrzeby: CDN, ochrona przed DDoS, darmowy SSL.

Proszę zainstalować wtyczkę Cloudflare dla WordPressa, połączy ona witrynę z CDN i udostępni podstawowe ustawienia bezpośrednio z panelu administracyjnego. W celu dokładniejszej konfiguracji należy zalogować się do panelu sterowania Cloudflare: włączyć Auto Minify dla CSS/JS/HTML, kompresję Brotli oraz Rocket Loader do asynchronicznego ładowania skryptów.

🔗 Cloudflare na WordPress.org

Dzięki cache'owaniu i CDN liczba żądań HTTP dla powracającego odwiedzającego spada radykalnie. Pierwsza wizyta to pełne ładowanie. Druga: większość plików jest dostarczana z cache przeglądarki i najbliższego węzła CDN, bez odwoływania się do Pana serwera.

Bonus: proszę sprawdzić, czy serwer obsługuje HTTP/2

HTTP/2 to protokół, który przesyła wiele plików przez jedno połączenie TCP. Przeglądarka nie czeka na zakończenie ładowania pliku nr 1, aby zażądać pliku nr 2, ładują się one równolegle. Zmniejsza to negatywny efekt dużej liczby żądań HTTP: 60 plików przez HTTP/2 ładuje się szybciej niż te same 60 przez HTTP/1.1.

Proszę sprawdzić swój serwer za pomocą narzędzia KeyCDN HTTP/2 Test, wpisać domenę i kliknąć „Test". Wynik „HTTP/2 is supported" oznacza, że multipleksowanie działa.

Jeśli test pokazuje HTTP/1.1, proszę skontaktować się z dostawcą hostingu. Większość nowoczesnych hostingów (SiteGround, Cloudways, Kinsta) domyślnie obsługuje HTTP/2. Na współdzielonych hostingach z lat 2010-tych bywa inaczej. Przy okazji proszę sprawdzić wersję PHP: przejście na nowoczesną wersję PHP daje zauważalny wzrost wydajności, a przestarzałe wersje przetwarzają żądania wielokrotnie wolniej. Jeśli dostawca hostingu nie aktualizuje ani protokołu, ani wersji PHP, być może nadszedł czas, aby rozważyć zmianę hostingu.

Jeśli woli Pan format wideo, oto wizualny poradnik dotyczący redukcji żądań HTTP w WordPressie (w języku angielskim, 12 minut).

⁉️🤔 Często zadawane pytania

Ile żądań HTTP uznaje się za normalne dla WordPressa?

Punkt odniesienia: od 30 do 60 na stronę. Wszystko powyżej 80-90 jest powodem do optymalizacji. GTMetrix i Pingdom pokazują konkretne liczby w swoich raportach. Po zastosowaniu pięciu kroków z tego artykułu realne jest zejście ze 130 do 35-45 żądań.

„Mam stronę na Elementorze, jest tam 100+ żądań i tak już jest. Czy to normalne?"

Kreatory stron z natury generują dużo CSS i JS. Sam Elementor i Divi dodają 30-50 żądań. Nie oznacza to „pogódź się z tym", oznacza to, że reszta witryny musi być maksymalnie czysta. Proszę usunąć wszystko, co nie dotyczy kreatora: zbędne wtyczki, zewnętrzne czcionki, niezoptymalizowane obrazy. Proszę zostawić tylko to, co realnie działa na korzyść odwiedzającego.

Co jest ważniejsze: liczba żądań czy całkowity rozmiar strony?

Jedno i drugie. 20 żądań po 1 MB każde, strona ładuje się 20 sekund. 100 żądań po 5 KB może załadować się szybciej, ale każde żądanie generuje narzut na DNS, połączenie TCP i uzgadnianie TLS. Na HTTP/2 ta różnica się zaciera. Na HTTP/1.1 jest krytyczna. Proszę optymalizować oba parametry: zmniejszać liczbę żądań poprzez łączenie plików i sprite'y, zmniejszać rozmiar poprzez kompresję i minifikację.

Czy można obejść się bez wtyczek?

Częściowo tak. Minifikację CSS/JS można skonfigurować przez Gulp lub Webpack na etapie budowania motywu. HTTP/2 włącza się na poziomie serwera (konfiguracja Nginx/Apache). Cache'owanie przez reguły serwerowe. Jednak dla większości właścicieli witryn WordPress wtyczki to najbardziej praktyczna droga: konfiguracja w kilka minut, natychmiastowy rezultat, niższe ryzyko uszkodzenia witryny.

Jak często należy sprawdzać liczbę żądań HTTP?

Po każdej większej instalacji lub aktualizacji wtyczki. Nowa wtyczka może dodać swoje CSS/JS na wszystkich stronach, a Pan tego nie zauważy, dopóki witryna nie zacznie zwalniać. Raz w miesiącu to wystarczająca częstotliwość rutynowej kontroli. GTMetrix pozwala skonfigurować automatyczne monitorowanie z powiadomieniem przy spadku wydajności.

Czy ten poradnik jest w ogóle potrzebny, jeśli mam już szybki hosting?

Hosting rozwiązuje część problemu na poziomie serwera, ale nie na poziomie kodu. Jeśli wtyczka wstawia 15 skryptów w <head> strony, nawet najlepszy serwer nie sprawi, że załadują się one natychmiast. Przeglądarka i tak będzie czekać. Szybki hosting daje przewagę, ale wygrywa ten, kto czyści również część kliencką.

Co realnie skraca liczbę zapytań HTTP, a co nie?

Przejdźmy przez wszystkie kroki bez złudzeń:

• Czyszczenie wtyczek i motywów daje najbardziej zauważalny przyrost. Każda usunięta wtyczka eliminuje jej CSS, JS i zewnętrzne wywołania. W praktyce po audycie znika 10-30 zapytań.
• Kompresja obrazów: rozmiar plików maleje, liczba zapytań nie zmienia się. Ale łączny czas ładowania spada odczuwalnie.
• Łączenie CSS i JS mocno tnie liczbę zapytań. Minus: może zepsuć układ, należy sprawdzać po każdej zmianie.
• Odroczone ładowanie skryptów: zapytań jest tyle samo, ale strona staje się widoczna wcześniej.
• Buforowanie i CDN: dla nowych odwiedzających różnica jest minimalna. Dla powracających, ponowne załadowanie strony bez żadnego zapytania do serwera.

Gdybyśmy mieli wybrać dokładnie trzy działania, które dają największy efekt na typowej stronie WordPress: (1) usunąć niepotrzebne wtyczki, (2) włączyć łączenie CSS/JS przez Autoptimize, (3) wdrożyć Cloudflare. To trzy kroki, które zajmują wieczór, a nie tydzień, i które zobaczą Państwo w liczbach GTMetrix już następnego dnia.