Najbardziej irytujący rodzaj wolnej strony to nie zawsze ten, na którym obrazy doczytują się przez pół minuty. Czasami klikasz link i przez chwilę nie dzieje się absolutnie nic. Biała przestrzeń, spinner albo po prostu cisza. Dopiero po dwóch, trzech, pięciu sekundach strona nagle zaczyna ładować się całkiem szybko. I wtedy bardzo łatwo usłyszeć: trzeba skompresować zdjęcia, zainstalować cache albo poprawić JavaScript. Tylko że jeśli przeglądarka czeka na pierwszą sensowną odpowiedź serwera, problem może znajdować się dużo wcześniej.

WordPress nie jest statycznym plikiem HTML leżącym na dysku. Przy dynamicznym requestcie PHP uruchamia aplikację, WordPress ładuje konfigurację, motyw i wtyczki, wykonuje hooki, pyta bazę danych o treści i ustawienia, czasem kontaktuje się z zewnętrznymi usługami, a dopiero potem składa odpowiedź. Jeżeli któryś z tych etapów jest wolny, użytkownik siedzi przed zamkniętą bramą. Optymalizacja tego, co wydarzy się po otwarciu bramy, może być potrzebna, ale nie skróci kolejki przed nią.

TTFB: zanim strona zacznie wyglądać, serwer musi zacząć odpowiadać

Time to First Byte nie jest idealnym wskaźnikiem wszystkiego, ale daje ważną wskazówkę: ile czasu mija, zanim przeglądarka zacznie dostawać odpowiedź. Na TTFB wpływa sieć, CDN, hosting i sama aplikacja. Jeśli jest wysoki, warto patrzeć głębiej niż na frontend. Możesz wycinać kolejne kilobajty CSS i zamieniać JPG na AVIF, ale jeśli backend potrzebuje kilku sekund na wygenerowanie dokumentu, użytkownik nadal będzie czekał.

WebsiteGarage / Usługi

Sprawdź nasze usługi.

To jak tuning samochodu, który przez trzy sekundy po wciśnięciu gazu zastanawia się, czy rzeczywiście chcesz jechać. Możesz założyć lżejsze felgi, sportowy filtr i karbonową maskę. Nadal najbardziej wkurza Cię to, że naciskasz pedał i nic się nie dzieje.

Baza danych może być winna, ale nie dlatego, że “jest duża”

Popularne wyjaśnienie brzmi: “baza jest za duża”. Czasami to prawda w bardzo uproszczonym sensie, ale sama liczba megabajtów niewiele mówi. Duża, dobrze zorganizowana baza może działać świetnie. Znacznie bardziej interesuje mnie to, jakie zapytania są wykonywane, ile ich jest, czy wykorzystują indeksy, czy jakaś wtyczka robi kosztowne operacje przy każdym requestcie, czy tabela opcji nie jest przeładowana automatycznie ładowanymi danymi i czy system nie mieli informacji, których użytkownik w ogóle nie potrzebuje na tej stronie.

WordPress i jego ekosystem pozwalają wtyczkom bardzo łatwo dopisywać własne dane i logikę. To jest ogromna zaleta platformy i jednocześnie powód, dla którego po kilku latach strona może przypominać samochód po pięciu właścicielach. Jeden dołożył radio, drugi alarm, trzeci światła dzienne, czwarty kamerę, piąty ładowarkę. Każde urządzenie samo działa. Problem zaczyna się, kiedy otwierasz deskę rozdzielczą i widzisz wiązkę kabli skręconych na kostkach z marketu.

Jedna wtyczka może wykonać zaskakująco dużo pracy

Wtyczka nie musi być “ciężka” w sensie rozmiaru pliku, żeby spowalniać stronę. Może wykonywać wiele zapytań do bazy, budować skomplikowane warunki, sprawdzać licencję z zewnętrznym API, generować dynamiczne dane albo ładować logikę na każdej stronie mimo że jest potrzebna tylko w jednym miejscu. Dlatego diagnoza typu “masz 37 pluginów, usuń połowę” jest równie precyzyjna jak diagnoza “samochód ma za dużo części”. Liczy się to, które części i co robią.

Możesz mieć pięć bardzo źle napisanych wtyczek i katastrofę albo czterdzieści lekkich komponentów i zupełnie przyzwoity wynik. Liczbę pluginów warto traktować jako sygnał złożoności do utrzymania, nie jako bezpośrednią metrykę wydajności.

Autoload: mały przełącznik, który potrafi zrobić duży bałagan

WordPress przechowuje wiele ustawień w tabeli opcji, a część danych jest automatycznie ładowana przy requestach. To ma sens dla informacji potrzebnych praktycznie wszędzie. Nie ma sensu dla ogromnych porzuconych struktur, danych tymczasowych albo ustawień wtyczki, której od dwóch lat nie ma na stronie. Z czasem autoload potrafi więc stać się jednym z miejsc, które warto sprawdzić przy wolnym backendzie. Nie przez magiczne “wyczyść bazę”, tylko przez identyfikację konkretnych danych i ich właściciela.

Zewnętrzne API też może trzymać stronę za gardło

Nie każda zwłoka siedzi w MySQL. Wtyczka może podczas generowania strony pytać zewnętrzny system o kurs waluty, status licencji, dane produktu, feed, pogodę, CRM albo cokolwiek innego. Jeżeli request jest synchroniczny i zewnętrzna usługa odpowiada wolno, WordPress może czekać razem z użytkownikiem. To jeden z tych problemów, których kompresja obrazków nie zauważy, bo zdjęcie nie dostało jeszcze nawet szansy zacząć się ładować.

Cache może sprawić, że problem zobaczysz tylko czasami

Pełny page cache potrafi praktycznie ominąć dużą część pracy WordPressa dla publicznych stron. Pierwsza osoba generuje dokument, następne dostają gotową kopię. To świetne rozwiązanie i należy z niego korzystać tam, gdzie ma sens. Ale wtedy problem z backendem może pojawiać się tylko po wygaśnięciu cache, po jego czyszczeniu, dla użytkownika zalogowanego albo w miejscach dynamicznych. Strona “zazwyczaj działa”, a raz na jakiś czas staje i myśli. Takie problemy są szczególnie wdzięczne do diagnozy, bo potrafią zniknąć dokładnie wtedy, kiedy zaczynasz je mierzyć.

Dlaczego test z zewnątrz nie zawsze pokaże przyczynę?

Narzędzie zewnętrzne widzi głównie efekt: serwer odpowiedział po X milisekundach, dokument waży tyle, skrypty robią to, obrazki robią tamto. Żeby znaleźć przyczynę po stronie WordPressa, często trzeba wejść głębiej: profilować PHP, przejrzeć query, zobaczyć slow query log, sprawdzić requesty HTTP, cron, obiektowy cache, zasoby serwera i zachowanie konkretnych endpointów. To nie jest czarna magia. Po prostu wymaga patrzenia na system od środka.

Czy hosting jest winny?

Czasami tak. Słaby CPU, ograniczenia konta, przeciążona infrastruktura, wolny storage albo zła konfiguracja PHP potrafią zrobić swoje. Ale “zmień hosting” jest równie leniwą diagnozą jak “zainstaluj cache”. Jeżeli aplikacja wykonuje bezsensownie drogie zapytania, mocniejszy serwer może tylko szybciej wykonywać bezsensowną pracę. To bywa skuteczne i czasem ekonomicznie uzasadnione, ale nadal warto wiedzieć, co kupujemy. Większy silnik pomaga, tylko jeśli problemem naprawdę jest brak mocy, a nie zaciągnięty hamulec ręczny.

Jak diagnozować wolny WordPress sensownie?

Zacznij od ustalenia, gdzie występuje opóźnienie. Czy problemem jest pierwsza odpowiedź serwera, czy renderowanie w przeglądarce? Wszystkie strony czy jeden typ? Użytkownicy zalogowani czy anonimowi? Cold cache czy warm cache? Frontend czy wp-admin? Potem dopiero schodź głębiej. Sprawdź PHP, bazę, zapytania, zewnętrzne połączenia, cron i wtyczki. Wyłączanie losowych pluginów na produkcji nie jest metodologią, tylko cyfrową wersją potrząsania kablem i patrzenia, czy telewizor wróci.

Jeżeli WordPress długo czeka, zanim cokolwiek zacznie się ładować, nie zaczynaj od polowania na pojedyncze kilobajty frontendu. Najpierw sprawdź, dlaczego aplikacja tak długo przygotowuje odpowiedź. Bo czasami strona nie jest wolna dlatego, że ma za duże zdjęcia. Jest wolna dlatego, że zanim pokaże Ci zdjęcie, musi najpierw odbyć pięć niepotrzebnych spotkań z bazą danych i zadzwonić do trzech zewnętrznych usług.