Dlaczego WordPress zwalnia — mechanizm i granice optymalizacji

WordPress zwalnia, bo składa każdą podstronę od nowa przy każdym wejściu: pyta bazę danych o treść, uruchamia motyw, a potem po kolei wszystkie wtyczki — także te, które na tej podstronie nie są do niczego potrzebne. Dopiero gotowy wynik leci do przeglądarki. Dużą część tego opóźnienia da się usunąć bez zmiany platformy. Poniżej pokazuję, gdzie dokładnie ucieka czas, co poprawisz sam i gdzie jest sufit, którego ustawieniami się nie przeskoczy.

Bez ideologii. WordPress da się rozpędzić i widuję szybkie wdrożenia na tym silniku. Chodzi o to, żebyś wiedział, za co płacisz czasem i pieniędzmi.

Co się dzieje między kliknięciem a wyświetleniem strony

Gdy ktoś wchodzi na Twoją podstronę, serwer wykonuje kilka kroków w tej kolejności:

1. Uruchamia PHP — język, w którym napisany jest WordPress.
2. Wczytuje rdzeń systemu, motyw graficzny i każdą aktywną wtyczkę.
3. Odpytuje bazę danych o treść, ustawienia i menu. Każda wtyczka może dołożyć własne zapytania.
4. Składa gotowy dokument HTML i odsyła go przeglądarce.
5. Przeglądarka doczytuje arkusze stylów, skrypty, czcionki i zdjęcia — każdy plik to osobne żądanie.

Punkty 1–4 nazywa się czasem odpowiedzi serwera. Dopiero po nim zaczyna się to, co widzi użytkownik. Jeśli serwer myśli sekundę, próg LCP poniżej 2,5 sekundy — czyli czas, po którym widać główną treść — masz do wykorzystania w połowie zjedzony, zanim cokolwiek się narysowało.

Cztery miejsca, w których ucieka czas

Wtyczki, które ładują się wszędzie

Większość wtyczek dokłada swoje pliki CSS i JavaScript do każdej podstrony, bo nie wie, gdzie zostaną użyte. Wtyczka do galerii dogrywa swoją bibliotekę także na stronie kontaktu. Wtyczka do formularzy — na blogu. Przy dwudziestu wtyczkach przeglądarka pobiera kilkadziesiąt plików, z których realnie korzysta z kilku.

Efekt widać najmocniej w INP poniżej 200 milisekund — metryce mówiącej, jak szybko strona reaguje na kliknięcie. Przeglądarka zajęta wykonywaniem cudzych skryptów nie ma kiedy obsłużyć Twojego menu.

Zapytania do bazy danych

Każde menu, każda lista wpisów, każdy licznik to zapytanie. Źle napisana wtyczka potrafi wykonać ich kilkadziesiąt na jedną podstronę. Baza odpowiada szybko, ale kilkadziesiąt razy pod rząd to już zauważalne dziesiątki milisekund — a przy współdzielonym hostingu, gdzie serwer obsługuje setki stron naraz, dużo więcej.

Motyw uniwersalny

Motywy sprzedawane jako „do wszystkiego" niosą kod pod dziesiątki układów, z których używasz jednego. Do tego kreatory stron typu przeciągnij-i-upuść generują głęboko zagnieżdżony kod, który przeglądarka musi przeliczyć, zanim cokolwiek narysuje.

Brak albo zła konfiguracja cache

Cache to zapamiętana, gotowa wersja podstrony, którą serwer oddaje bez ponownego liczenia. Bez cache każdy odwiedzający uruchamia całą procedurę od nowa. Z cache źle ustawionym bywa gorzej: zalogowani użytkownicy widzą stare treści, a formularze przestają działać.

Co poprawisz bez zmiany platformy

To realna lista, w kolejności od największego zysku:

• Zdjęcia. Konwersja do WebP i zmniejszenie do faktycznych rozmiarów. Zdjęcie 4 MB z aparatu schodzi zwykle poniżej 200 KB bez różnicy widocznej okiem. To najczęściej największy pojedynczy zysk na LCP.
• Przegląd wtyczek. Wyłącz i usuń wszystko, czego nie używasz od pół roku. Dwie wtyczki robiące to samo to klasyk.
• Cache stron z poprawną konfiguracją i kompresją odpowiedzi serwera.
• CDN — sieć serwerów, która oddaje pliki z punktu najbliższego użytkownikowi zamiast z jednej maszyny.
• Lepszy hosting. Przejście z współdzielonego na serwer dedykowany pod WordPressa potrafi ściąć czas odpowiedzi o połowę.
• Rezerwacja miejsca na elementy, które doczytują się później — banery zgody na pliki cookie, reklamy, osadzone mapy. To leczy CLS poniżej 0,1, czyli metrykę mówiącą, czy treść skacze pod palcem.

Znaczenie każdej z tych trzech metryk rozpisałem we wpisie o Core Web Vitals.

Gdzie jest sufit

Wszystkie powyższe zabiegi zmniejszają objaw. Nie zmieniają mechanizmu: strona wciąż jest składana na żądanie, a przeglądarka wciąż dostaje kod motywu i wtyczek napisany na wyrost.

Sufit poznasz po tym, że po optymalizacji wynik w PageSpeed na telefonie stoi w miejscu, a każda kolejna zmiana daje pojedyncze punkty. Zwykle dzieje się to tam, gdzie:

• strona ma kreator wizualny i kilkanaście wtyczek, których nie da się usunąć bez utraty funkcji,
• cache nie działa dla podstron z formularzem albo koszykiem,
• pod jedną domeną siedzi sklep, blog i wizytówka, a wszystkie ładują ten sam ciężki motyw.

Co robi inaczej generowanie z wyprzedzeniem

W Next.js 16 podstrony powstają przed wejściem użytkownika — w momencie publikacji, nie w momencie odwiedzin. Serwer nie liczy niczego na żądanie, tylko oddaje gotowy plik. Znika krok z bazą danych, znika uruchamianie wtyczek, a przeglądarka dostaje tylko ten kod, który jest na danej podstronie potrzebny.

Konsekwencje są policzalne, nie ideologiczne:

• czas odpowiedzi serwera przestaje zależeć od liczby funkcji na stronie,
• hosting statyczny kosztuje zwykle 0 zł, bo nie ma czego liczyć,
• nie ma wtyczek do aktualizowania, więc wydajność nie pogarsza się z miesiąca na miesiąc.

Na mazcode.pl daje to 100/100 w PageSpeed — możesz to sprawdzić samodzielnie, wpisując adres w narzędzie Google.

Najczęstsze pytania

Czy da się mieć szybkiego WordPressa?

Da się. Lekki motyw, kilka wtyczek zamiast dwudziestu, dobry hosting i cache potrafią zejść poniżej progów Core Web Vitals. Problem w tym, że taki stan trzeba utrzymywać — każda nowa wtyczka odbiera część zapasu.

Ile trwa optymalizacja istniejącej strony?

Zdjęcia, przegląd wtyczek i cache to zwykle jeden dzień pracy. Przebudowa motywu to inna skala i wtedy warto policzyć, czy nie taniej wyjdzie nowa strona — porównanie kosztów jest we wpisie o wyborze między WordPressem a stroną pisaną ręcznie.

Czy wynik w PageSpeed przekłada się na klientów?

Pośrednio. Google używa Core Web Vitals jako czynnika rankingowego, więc lepszy wynik pomaga w pozycjach. Bezpośrednio działa cierpliwość użytkownika: strona ładująca się pięć sekund traci część wchodzących, zanim zobaczą ofertę.

Od czego zacząć, jeśli nie znam się na technicznych rzeczach?

Od pomiaru. Wpisz adres swojej strony w PageSpeed Insights i patrz na wynik dla urządzeń mobilnych, nie dla komputera. Mobilny jest tym, który widzi większość Twoich klientów.

Co z tym zrobić

Zmierz stronę na telefonie, wypisz aktywne wtyczki i sprawdź wagę największego zdjęcia na stronie głównej. Te trzy informacje wystarczą, żeby stwierdzić, czy masz do czynienia z problemem konfiguracji, czy z sufitem architektury. Pierwszy naprawia się w jeden dzień. Drugi wymaga decyzji o przebudowie.

Jeśli chcesz mieć to policzone, zamów bezpłatny audyt — dostaniesz pięć konkretnych rzeczy do poprawy w 48 godzin, bez zobowiązań. Stack, na którym buduję szybkie strony, opisałem w dziale technologia.