Dlaczego strona WordPress ładuje się wolno i jak sprawdzić przyczynę

Strona WordPress ładuje się wolno najczęściej z czterech powodów: przeciążonego serwera współdzielonego, braku działającego cache, starej wersji PHP oraz nadmiaru wtyczek, które przy każdym wejściu odpytują bazę danych. Kolejność diagnozy ma znaczenie, bo optymalizacja zdjęć na serwerze, który odpowiada po sekundzie, jest jak wymiana opon w aucie bez paliwa. Poniżej pokazujemy, jak w kwadrans ustalić, gdzie znikają Twoje sekundy, zanim komukolwiek za to zapłacisz.

Najpierw zrozum, z czego składa się czas ładowania

Wejście na stronę dzieli się na dwa odcinki. Pierwszy to czas, w którym przeglądarka czeka na odpowiedź serwera, czyli na sam kod HTML. Nazywa się to czasem do pierwszego bajtu (TTFB) i odpowiada za niego wyłącznie hosting: procesor, dysk, baza danych i cache. Drugi odcinek zaczyna się dopiero po odebraniu HTML i obejmuje pobieranie obrazów, arkuszy stylów, czcionek i skryptów, a także ich przetwarzanie w przeglądarce. Za ten etap odpowiada motyw, wtyczki i sposób, w jaki zbudowano stronę.

To rozróżnienie jest kluczowe, bo połowa porad w internecie dotyczy wyłącznie drugiego odcinka. Kompresja zdjęć, ładowanie leniwe i łączenie plików CSS mają sens, ale nie skrócą oczekiwania na pierwszy bajt nawet o milisekundę. Jeśli Twoja strona zaczyna się rysować po półtorej sekundy, to nie jest problem zdjęć.

Powód pierwszy: przeciążony serwer współdzielony

Na hostingu współdzielonym na jednej maszynie stoi wiele stron, które dzielą procesor, pamięć i dysk. Dopóki sąsiedzi zachowują się spokojnie, wszystko działa. Problem pojawia się, gdy jedna ze stron na tym samym serwerze dostaje falę ruchu albo uruchamia ciężki import, a Twoja witryna czeka w kolejce na moc obliczeniową.

Objaw rozpoznawczy jest prosty: strona bywa szybka rano, a wyraźnie wolniejsza wieczorem i w poniedziałki. Drugi objaw to panel administracyjny, który mieli dłużej niż strona dla gościa. Panel nie jest podawany z cache, więc pokazuje prawdziwą kondycję serwera i bazy. Jeśli to Twój przypadek, żadna wtyczka tego nie naprawi, bo brakuje po prostu mocy, a nie konfiguracji.

Powód drugi: cache, którego nie ma albo nie działa

WordPress przy każdym wejściu buduje stronę od nowa: uruchamia PHP, odpytuje bazę kilkadziesiąt razy, składa szablon i dopiero wtedy oddaje HTML. Cache zapisuje gotowy wynik i przy kolejnych wejściach podaje plik zamiast powtarzać całą pracę. Różnica potrafi wynosić kilkaset milisekund na każdym wejściu.

Częstym błędem jest założenie, że skoro wtyczka do cache jest zainstalowana, to cache działa. Wystarczy jedna wtyczka wymuszająca dynamiczną treść, źle ustawione wykluczenia albo aktywna sesja użytkownika, żeby cache przestał obejmować większość ruchu. Sprawdzisz to w kilkanaście sekund: otwórz stronę w oknie prywatnym, odśwież ją dwa razy i porównaj czas oczekiwania na dokument HTML. Jeśli drugie odświeżenie nie jest zauważalnie szybsze, cache nie działa tak, jak myślisz.

Powód trzeci: stara wersja PHP

PHP to język, w którym napisano WordPressa, a każda kolejna wspierana wersja obsługuje więcej zapytań na tym samym sprzęcie. Strony stojące na wersji sprzed kilku lat tracą wydajność bez żadnego powodu, a przy okazji nie dostają już poprawek bezpieczeństwa. Aktualizacja PHP jest jedną z niewielu zmian, które potrafią przyspieszyć stronę bez dotykania jej kodu.

Haczyk polega na tym, że podniesienie wersji PHP przy starym motywie albo porzuconej wtyczce potrafi wywalić błąd. Dlatego robi się to w kolejności: kopia zapasowa, test na środowisku testowym, dopiero potem produkcja. To standardowy element opieki, którą prowadzimy w planach z zarządzanymi aktualizacjami, i dokładnie ten scenariusz opisaliśmy w poradniku o bezpiecznej aktualizacji WordPressa z kopią przed zmianą.

Powód czwarty: wtyczki i baza danych

Każda aktywna wtyczka dokłada zapytania do bazy i kod do wykonania przy każdym wejściu. Trzydzieści wtyczek to nie zawsze problem, jeśli są lekkie, ale jedna źle napisana potrafi dodać pół sekundy do każdego żądania. Do tego dochodzi tabela wp_options i dane ładowane automatycznie przy starcie: po latach potrafi się tam zebrać kilka megabajtów śmieci po odinstalowanych wtyczkach, które wciąż są wczytywane przy każdym otwarciu strony.

Typowi winowajcy to rozbudowane kreatory stron, wtyczki statystyk zapisujące każde wejście do bazy, wtyczki powiązanych produktów w sklepie i wszystko, co odpytuje zewnętrzne API w trakcie ładowania strony. Ostatnia kategoria jest najgorsza: jeśli zewnętrzny serwis odpowiada wolno, Twoja strona czeka razem z nim.

Jak to sprawdzić w kwadrans

Zamiast zgadywać, wykonaj cztery kroki w tej kolejności:

1. Zmierz czas odpowiedzi serwera. Otwórz narzędzia deweloperskie przeglądarki, zakładkę Sieć, odśwież stronę i sprawdź czas oczekiwania na pierwszy dokument HTML. Powtórz pomiar kilka razy, w tym wieczorem. Powyżej sekundy odpowiada serwer.
2. Porównaj widok gościa i zalogowanego. Wyloguj się i odśwież stronę. Jeśli dla gościa jest szybko, a w panelu wolno, cache maskuje wolną bazę i przeciążony serwer.
3. Sprawdź dane z realnych użytkowników. W PageSpeed Insights patrz na sekcję z danymi terenowymi, a nie tylko na wynik laboratoryjny. Dobry LCP to 2,5 sekundy lub mniej, dobry INP to 200 milisekund lub mniej, a dobry CLS to 0,1 lub mniej.
4. Testuj wtyczki na kopii, nigdy na żywej stronie. Sklonuj witrynę na środowisko testowe i wyłączaj wtyczki pojedynczo, mierząc różnicę. Na produkcji ten test kosztuje zamówienia.

Po tych czterech krokach wiesz już, czy rozmawiasz o serwerze, czy o kodzie strony. To ważne również dlatego, że oferty na przyspieszenie strony potrafią kosztować więcej niż roczny abonament za lepszy hosting, a czasem rozwiązują zupełnie inny problem niż ten, który masz.

Kiedy przyspieszy dopiero zmiana hostingu

Zmiana serwera ma sens, gdy pomiar wskazuje na TTFB liczony w sekundach, gdy panel administracyjny działa wolno mimo lekkiej strony, gdy sklep zwalnia przy kilkunastu osobach na raz albo gdy dostawca nie pozwala podnieść wersji PHP. W tych sytuacjach zysk jest natychmiastowy i widać go w pierwszym pomiarze po przeprowadzce. Więcej o tym, co konkretnie składa się na wydajność serwera, piszemy na stronie szybkiego hostingu WordPress na dyskach NVMe.

Zdarza się też sytuacja odwrotna i warto ją nazwać uczciwie. Jeśli strona ma dziesięć lat, kilkanaście warstw kreatora i motyw, którego nikt już nie rozwija, to przeprowadzka niczego nie załatwi, a rozsądniejszym wydatkiem bywa zbudowanie nowej strony firmowej w stałej cenie i postawienie jej od razu na porządnym serwerze. Nowoczesny szablon potrafi zejść z czasem ładowania niżej niż jakakolwiek optymalizacja starego kodu.

Ile realnie kosztuje wolna strona

Szybkość jest jednym z sygnałów rankingowych Google, ale traktowanie jej wyłącznie jako czynnika SEO zaniża stawkę. Wolna strona traci ludzi jeszcze przed wyświetleniem oferty, a przy płatnym ruchu każde takie wyjście to budżet reklamowy wyrzucony przed pierwszym zdaniem. W sklepie efekt widać wprost w porzuconych koszykach, a w firmie usługowej w liczbie wysłanych formularzy.

Dlatego warto zacząć od pomiaru, a nie od zakupu. Jeśli chcesz, żeby ktoś zrobił to za Ciebie, w ramach opieki przeglądamy stronę, mierzymy czas odpowiedzi serwera i mówimy wprost, co ją spowalnia, także wtedy, gdy wina nie leży po stronie hostingu. Pełny zakres opieki opisuje strona zarządzanego hostingu WordPress, a stawki znajdziesz w cenniku.