Strona ładuje się 4 sekundy i odwiedzający odchodzi. Znajoma sytuacja?

Według danych Google Research z 2023 roku prawdopodobieństwo odrzucenia rośnie o 32% przy wydłużeniu ładowania z 1 do 3 sekund. Jedną z głównych przyczyn spowolnienia, którą często się pomija, są nadmiarowe zapytania HTTP. Nie rzucają się w oczy jak ciężkie obrazy czy słaby hosting, ale kumulują się dziesiątkami i w sumie pożerają sekundy.

Przeanalizujmy, czym są te zapytania, jak je znaleźć poprzez analizę waterfall w GTmetrix i, co najważniejsze, jak zmniejszyć ich liczbę bez szkody dla funkcjonalności strony.

💡 Szybki przegląd:

• Otwiera Pan/Pani GTmetrix, wkleja URL strony i przechodzi do zakładki Waterfall, widzi Pan/Pani każde zapytanie z jego rozmiarem i czasem ładowania
• Filtruje Pan/Pani zapytania według folderów plugins i themes, znajduje wtyczki, które niepotrzebnie ciągną skrypty na wszystkich stronach
• Przechodzi Pan/Pani przez 5 punktów: zbędne obrazy, niepołączone CSS/JS, wtyczki z globalnym ładowaniem, ciężkie wtyczki oraz brak leniwego ładowania
• Po poprawkach uruchamia Pan/Pani test ponownie i porównuje liczbę zapytań „przed" i „po"

Czym są zapytania HTTP i dlaczego spowalniają stronę

Gdy przeglądarka otwiera stronę, nie otrzymuje gotowego obrazu w całości. Potrzebuje szkieletu HTML, plików stylów, każdego ze skryptów, czcionek, obrazów i dla każdego elementu przeglądarka wysyła osobne zapytanie HTTP do serwera.

Część zapytań trafia na Pana/Pani serwer (wewnętrzne: obrazy z biblioteki mediów, motyw, wtyczki). Część do zewnętrznych serwisów (Google Analytics, osadzenia YouTube, skrypty reklamowe). Przeglądarka ustawia je w kolejce i ładuje.

Zależność jest prosta: więcej zapytań, dłuższe ładowanie. Ale nie wszystkie zapytania są jednakowe. Malutki skrypt śledzący ładuje się w 20 ms, a niezoptymalizowany obraz o wadze 500 KB może wisieć pół sekundy. Dlatego zadaniem nie jest po prostu „zmniejszyć liczbę", lecz usunąć niepotrzebne i odchudzić te, które zostają.

W praktyce różnica jest zauważalna: strona portfolio na czystym motywie wykonuje 18 zapytań i otwiera się natychmiast. Duży portal informacyjny, taki jak New York Times, wykonuje ponad 200 zapytań, z czego połowa to skrypty reklamowe i śledzące. Pana/Pani strona jest gdzieś pośrodku i tę liczbę można zmniejszyć.

Jak analizować zapytania HTTP: waterfall w GTmetrix

Najbardziej poglądowym sposobem, by zobaczyć zapytania HTTP, jest diagram waterfall (kaskadowy). Pokazuje on każde zapytanie w osobnym wierszu: skąd pochodzi, ile waży, kiedy zaczęło się ładować i jak długo to trwało.

Narzędzia obsługujące waterfall:

• Wbudowane Chrome DevTools (zakładka Network), bezpłatne, ale tylko dla Pana/Pani przeglądarki
• GTmetrix, bezpłatny abonament, test z różnych lokalizacji, przejrzysty interfejs
• Pingdom Tools, podobne do GTmetrix, inne punkty testowe
• WebPageTest, maksimum szczegółów, ale trudniejsze na początek

Przeanalizujmy na przykładzie GTmetrix. Wkleja Pan/Pani URL, uruchamia test. W wynikach zakładka Waterfall to właśnie kaskada:

Sam diagram wygląda następująco:

Co oznaczają kolumny:

• URL, ścieżka do pliku. Widać z niej, który plugin lub motyw dodał żądanie
• Domena, serwer Pana/Pani lub zewnętrzny. Od razu widać, ile ładuje się z zewnątrz
• Rozmiar, waga pliku. Ciężkie żądania mocniej uderzają w szybkość
• Oś czasu, kiedy żądanie się rozpoczęło i jak długo trwało. Ważny jest nie tylko rozmiar, ale i położenie: plik na początku łańcucha blokuje wszystko, co idzie za nim

Proszę kliknąć pole wyszukiwania nad diagramem i wpisać wp-content/plugins, zobaczy Pan/Pani tylko żądania od pluginów. Na poniższym przykładzie plugin Lightweight Social Fonts dodaje żądanie czcionki fontello.woff o wielkości 22,9 KB:

A jeśli przefiltruje Pan/Pani po themes, zobaczy Pan/Pani żądania motywu. GeneratePress na przykład generuje zaledwie 4 żądania, to dobry wynik dla lekkiego motywu:

Proszę przejrzeć listę i zadać sobie pytanie: „Czy ten plugin jest naprawdę potrzebny na każdej stronie?" Często odpowiedź brzmi: nie. Dalej omówimy, co z tym zrobić.

5 Sposobów na zmniejszenie liczby zapytań HTTP w WordPressie

Po analizie waterfall ma Pan/Pani w ręku listę zapytań. Teraz konkretne kroki, by je zredukować.

1. Usunąć zbędne i nieprzygotowane obrazy

Każdy obraz = jedno zapytanie HTTP. Jeśli na stronie jest 15 obrazków, a 5 z nich to elementy dekoracyjne lub duplikaty, to 5 zapytań, które można usunąć bez utraty sensu. Dla niezbędnych obrazów zasada jest inna: skompresować i dopasować do rozmiaru wyświetlania. Obrazek o szerokości 2500px wstawiony w blok o szerokości 700px ładuje 5 razy więcej danych, niż potrzeba.

W praktyce pomaga połączenie: ręczna rewizja (usunięcie zbędnych) + plugin do kompresji. Wśród aktualnych opcji: ShortPixel, Imagify, Smush. Kompresują one obrazy podczas przesyłania do biblioteki mediów i mogą ponownie skompresować już istniejące.

2. Połączyć CSS i JavaScript

Motyw i każdy plugin dodają swoje pliki stylów i skryptów. Jeśli ma Pan/Pani aktywny motyw, 10 pluginów i parę zewnętrznych serwisów, łatwo uzbiera się 30-40 osobnych plików CSS/JS. Każdy z nich wymaga osobnego zapytania HTTP.

Technika ta nazywa się konkatenacją (łączeniem) i zwykle idzie w parze z minifikacją, czyli usunięciem spacji i komentarzy z kodu. Większość pluginów do wydajności robi jedno i drugie:

• WP Rocket, plugin premium, łączy i minifikuje CSS/JS za pomocą kilku kliknięć
• Autoptimize, darmowy, tylko konkatenacja i minifikacja

Ważne: po włączeniu łączenia proszę przejść główne strony witryny i upewnić się, że układ się nie rozjechał. Czasami skrypty konfliktują ze sobą podczas sklejania, wtedy konkretny plik wyklucza się z łączenia.

3. Zabronić pluginom ładowania się tam, gdzie nie są potrzebne

Formularz kontaktowy znajduje się tylko na stronie kontaktowej. Ale jego CSS i JS często ładują się na całej witrynie, to 2-3 zbędne zapytania na każdej stronie bez formularza. Contact Form 7 na przykład domyślnie ładuje skrypty globalnie.

Jeśli plugin na to pozwala, są dwie drogi:

• Zastąpić bardziej zoptymalizowanym odpowiednikiem, który nie ładuje zasobów globalnie
• Pozostawić wtyczkę, ale zarządzać ładowaniem skryptów przez Perfmatters, który ma menedżer skryptów umożliwiający wyłączenie CSS/JS wtyczki na wszystkich stronach oprócz tych, gdzie jest faktycznie używana

Rezultat: te same 2-3 zapytania, ale tylko na jednej stronie kontaktowej, a nie w całej witrynie.

4. Zastąpić ciężkie wtyczki lekkimi odpowiednikami

Po zastosowaniu filtra waterfall dla plugins widzą Państwo, które wtyczki generują najwięcej zapytań. Jeśli jedna wtyczka dodaje 8 skryptów i stylów, a jej odpowiednik ogranicza się do dwóch, zamiana redukuje 6 zapytań HTTP.

Przykłady zamian z praktyki:

• Slider Revolution Slider (ciężki) → lekki blok okładki z motywu lub MetaSlider
• Kreator stron z dziesiątkami skryptów → natywny edytor bloków Gutenberg
• Wtyczka mediów społecznościowych z zewnętrznymi zapytaniami do API → statyczne ikony linków

Proszę sprawdzić każdą wtyczkę z listy waterfall: czy jest w ogóle używana? Jeśli wtyczka nie była aktualizowana od ponad roku lub funkcjonalność nie jest potrzebna, proszę ją całkowicie usunąć.

5. Włączyć leniwe ładowanie

Leniwe ładowanie (lazy loading) opóźnia wczytywanie obrazów i iframe, które znajdują się poniżej widocznego obszaru ekranu. Odwiedzający otwiera stronę, ładuje się tylko to, co widzi. Reszta jest pobierana w miarę przewijania.

Od WordPress 5.5 atrybut loading="lazy" jest dodawany do obrazów automatycznie. To wystarcza w podstawowym scenariuszu. Jeśli potrzebne jest bardziej agresywne leniwe ładowanie (dla iframe, obrazów tła, wideo), proszę użyć Perfmatters, WP Rocket lub bezpłatnego LazyLoad by WP Rocket.

Wideo: zapytania HTTP WordPress w 5 minut

Krótkie wideo na ten temat, od diagnostyki do redukcji zapytań bez wtyczek:

⁉️🤔 Często zadawane pytania

Ile żądań HTTP to norma dla WordPressa?

Nie ma jednej uniwersalnej liczby. Czysta witryna na lekkim szablonie z 5-7 wtyczkami mieści się w 25-40 żądaniach. Witryna z kreatorem stron, skryptami reklamowymi i kilkunastoma wtyczkami może generować 80-120. Proszę kierować się nie bezwzględną liczbą, a dynamiką: było 90, jest 55, to dobry wynik.

Czy zewnętrzne żądania (Google Fonts, Analytics) wpływają na szybkość?

Wpływają, ale inaczej. Zewnętrzne żądanie do Google Fonts dodaje 1-2 żądania, ale idą one przez CDN Google i ładują się szybko. Główny problem to blokowanie renderowania: dopóki czcionka się nie załaduje, przeglądarka może nie wyświetlać tekstu. Rozwiązanie: wstępne ładowanie czcionek przez preload lub hostowanie czcionek lokalnie.

Czy koniecznie trzeba łączyć wszystkie CSS i JS w jeden plik?

Nie zawsze. Połączenie wszystkich skryptów w jeden plik daje jedno żądanie, ale duży plik ładuje się dłużej. Współczesny HTTP/2 potrafi ładować kilka plików równolegle, dlatego 3-4 pliki po 30 KB mogą załadować się szybciej niż jeden plik 120 KB. Optymalnie jest połączyć krytyczny CSS (ten potrzebny do wyrenderowania pierwszego ekranu) i pozostawić niekrytyczne skrypty osobno z atrybutem defer.

Co zrobić, jeśli po połączeniu CSS popsuł się układ strony?

Wykluczyć problematyczny plik z łączenia. WP Rocket i Autoptimize pozwalają dodać URL skryptu lub stylu do listy wyjątków. Następnie proszę ponownie uruchomić test, utrata jednego pliku z puli 15 żądań jest prawie niezauważalna.

Czy można zmniejszyć liczbę żądań bez wtyczek?

Można. Ręczne wyrejestrowywanie skryptów przez functions.php daje pełną kontrolę, ale wymaga zrozumienia hooków WordPressa. Dla większości właścicieli witryn WP Rocket lub Perfmatters są prostsze i bezpieczniejsze: nie pozwolą wyłączyć skryptu krytycznego dla działania strony.

Czas zrobić porządek z żądaniami

Żądania HTTP to nie jest rzecz, którą naprawia się raz. Zainstalowali Państwo nową wtyczkę, zmienili szablon, dodali skrypt reklamowy, pojawiły się nowe żądania. Raz na kilka miesięcy proszę wchodzić do GTmetrix, otwierać Waterfall i porównywać z tym, co było ostatnim razem.

Jeśli w tej chwili nie wiedzą Państwo, ile żądań generuje Państwa witryna, proszę otworzyć GTmetrix, wkleić URL i kliknąć „Start Test". Za minutę zobaczą Państwo rzeczywisty obraz. A potem, krok po kroku według artykułu. Każde usunięte żądanie przybliża witrynę do ładowania w 1-2 sekundy.