Cache, PHP 8.4, obrazy, audyt wtyczek, baza i autoload - dziewięć kroków przyspieszania WordPressa we właściwej kolejności, z pomiarami po drodze.
Wolny WordPress to niemal zawsze ta sama lista przyczyn w tej samej kolejności: brak cache, stara wersja PHP, nieskompresowane obrazy, przeciążone wtyczki i ciężki motyw. Naprawa w tej właśnie kolejności daje największy efekt najmniejszym kosztem - dwa pierwsze kroki to zwykle kilkukrotne przyspieszenie w pół godziny, bez dotykania wyglądu strony.
Poniżej dziewięć kroków z pomiarami po drodze: od największej pojedynczej dźwigni po decyzję o zmianie hostingu, która powinna zapadać na końcu, a nie na początku. Do tego dwa mniej znane zabójcy szybkości - rozdęta tabela opcji i autoload - oraz ściąga z kolejnością na jedną kartkę.
Przyspieszanie „na czuja" kończy się wyłączaniem przypadkowych wtyczek i frustracją. Zrób pomiar bazowy - nasz test szybkości strony mierzy z polskiej lokalizacji, a raport PageSpeed pokaże metryki od realnych użytkowników (jak go czytać: przewodnik po PageSpeed Insights). Zapisz wyniki i mierz po każdej zmianie - tylko tak dowiesz się, co faktycznie zadziałało.
Jedna liczba z raportu zasługuje na szczególną uwagę: czas odpowiedzi serwera (TTFB). Jeśli przekracza pół sekundy, problem leży przed przeglądarką - w PHP, bazie albo serwerze - i to tam trzeba zacząć. Znaczenie pozostałych wskaźników tłumaczy tekst o Core Web Vitals.
Bez cache WordPress buduje każdą stronę od zera: przy każdym wejściu uruchamia PHP, odpytuje bazę i skleja HTML - także wtedy, gdy strona nie zmieniła się od tygodnia. Cache zapisuje gotowy wynik i serwuje go w ułamku sekundy.
Na hostingu z serwerem LiteSpeed (jak nasz) używaj wtyczki LiteSpeed Cache - działa na poziomie serwera, zanim w ogóle uruchomi się PHP, czyli szybciej niż wtyczki budujące cache w samym WordPressie. Po włączeniu sprawdź stronę w trybie prywatnym i przejdź formularze oraz koszyk - agresywne ustawienia potrafią zamrozić elementy dynamiczne. Mechanikę wszystkich warstw cache wyjaśnia przewodnik po cache.
Różnica między PHP 7.4 a 8.3-8.4 to często 20-40 procent szybciej - za darmo, jednym kliknięciem w panelu hostingu. Gałęzie starsze niż 8.2 nie dostają już przy tym żadnych poprawek bezpieczeństwa, więc to zmiana podwójnie zasadna.
Przed przełączeniem sprawdź stronę po zmianie (najlepiej na kopii): bardzo stare wtyczki potrafią protestować. W razie problemów wracasz jednym kliknięciem, aktualizujesz winowajcę i próbujesz ponownie - procedurę opisuje tekst o bezpiecznej aktualizacji.
Zdjęcie prosto z telefonu waży 4-8 MB; na stronie potrzebuje 100-300 KB. To drugi najczęstszy winowajca po braku cache - i najczęstszy na stronach z galeriami. Trzy ruchy: konwersja do formatu WebP, kompresja i leniwe ładowanie obrazów poniżej pierwszego ekranu (ale NIE obrazu głównego w nagłówku - jego opóźnienie pogarsza wyniki). Szczegóły i narzędzia w przewodniku o optymalizacji obrazów.
Nie liczba wtyczek zabija, tylko ich jakość: jedna źle napisana wtyczka „statystyk" potrafi dokładać dziesiątki zapytań do bazy przy każdym wejściu, podczas gdy dwadzieścia porządnych nie dokłada nic odczuwalnego. Metoda jest nudna i skuteczna: wyłączaj po jednej i mierz.
Typowi podejrzani: wtyczki pokazujące „powiązane wpisy", stare wtyczki bezpieczeństwa skanujące wszystko przy każdym żądaniu, moduły odpytujące zewnętrzne API (kursy walut, pogoda, opinie) na żywo oraz statystyki zapisujące każde wejście w bazie. Sprawdzony minimalny zestaw dla strony firmowej opisujemy w tekście o wtyczkach must-have. Nieużywane wtyczki kasuj w całości - dezaktywacja nie zwalnia niczego.
Ciężkie motywy „do wszystkiego" ładują dziesiątki plików stylów i skryptów na każdej podstronie - także tych, których dana podstrona wcale nie używa. Jeśli budujesz Elementorem, przejdź nasz spis 10 błędów, które spowalniają strony w Elementorze - większość naprawisz bez zmiany motywu. Decyzję „czym budować", żeby było lekko, ułatwia porównanie Gutenberg, Elementor czy Divi.
Rewizje wpisów, kosz, wygasłe dane tymczasowe i tabele po odinstalowanych wtyczkach potrafią po latach rozdąć bazę kilkukrotnie - a im większa baza, tym wolniejsze zapytania. Wtyczka porządkująca (na przykład WP-Optimize albo funkcje wbudowane w LiteSpeed Cache) czyści to bezpiecznie. Warunek bezwzględny: najpierw kopia zapasowa, potem sprzątanie.
Mniej znany zabójca szybkości: opcje w tabeli wp_options oznaczone flagą autoload ładują się z bazy przy KAŻDYM żądaniu - wszystkie naraz, niezależnie od tego, czy są potrzebne. Wtyczki potrafią zostawić tam setki kilobajtów danych nawet po odinstalowaniu.
Praktyczny próg: jeśli suma danych autoload przekracza 1 MB, masz znalezisko - każde wejście na stronę dźwiga ten balast. Sprawdzenie i czyszczenie wymaga pracy bezpośrednio na bazie, więc zostaw je osobie technicznej albo nam; to standardowy punkt naszych przeglądów wydajności.
Gdy odbiorcy są głównie w Polsce, a serwer też stoi w Europie, CDN daje mniej, niż obiecują reklamy - bywa wręcz, że dokłada opóźnienie pierwszego połączenia. Ma sens przy odbiorcach z różnych kontynentów, bardzo ciężkich mediach albo dużym ruchu. To krok ósmy, nie pierwszy - wdrażany zamiast poprzednich nie naprawi niczego.
Jeżeli po krokach 1-8 czas odpowiedzi serwera wciąż przekracza około pół sekundy, ogranicza Cię serwer: przeciążona maszyna, wolne dyski albo ciasne limity. Sprawdź w panelu, czy nie dobijasz do limitów konta - a jeśli strona jest zoptymalizowana i limity się nie świecą, to sygnał do rozmowy o przeprowadzce.
Dyski NVMe, LiteSpeed z cache na poziomie serwera i aktualne PHP robią tu realną różnicę - zobacz nasz hosting pod WordPressa (co znaczą te technologie: technologie hostingu po ludzku). Przy przejściu przenosimy stronę za darmo i przy okazji wdrażamy kroki 1-3 z tej listy.
Szerszy kontekst całej optymalizacji - także poza WordPressem - zbiera przewodnik Szybka strona WWW.
Od cache - to największy pojedynczy zysk, osiągalny w kwadrans i bez ryzyka dla treści. Druga w kolejności jest zmiana wersji PHP w panelu hostingu. Te dwa kroki razem potrafią skrócić czas ładowania kilkukrotnie, zanim w ogóle dotkniesz obrazów czy wtyczek.
To źle postawione pytanie - liczy się jakość, nie liczba. Strona z trzydziestoma dobrze napisanymi wtyczkami działa szybko, a jedna wadliwa potrafi położyć wszystko. Zamiast liczyć, mierz: wyłączaj pojedynczo i obserwuj czas odpowiedzi. Usuwaj natomiast wszystko, czego realnie nie używasz - każda wtyczka to też powierzchnia ataku.
Bywa, że znacząco - ale to najdroższy krok na liście, więc zostaw go na koniec. Najpierw wyczerp tańsze rezerwy: cache, PHP, obrazy i ustawienia obecnego motywu. Jeśli po tym wszystkim motyw nadal ładuje dziesiątki zbędnych plików na każdej podstronie, dopiero wtedy licz koszt przebudowy.
To wzorzec wskazujący na zewnętrzne obciążenie, nie na kod strony: kopie zapasowe albo skany antywirusowe o stałych godzinach, crony, ruch botów albo sąsiadów na przeciążonym serwerze współdzielonym. Sprawdź wykresy zużycia zasobów w panelu hostingu i porównaj godziny spowolnień z harmonogramem zadań.
Panel nie korzysta z cache stron, więc każde kliknięcie przechodzi pełną drogę przez PHP i bazę. Muli go zwykle to samo, co bez cache spowalniałoby całą stronę: stara wersja PHP, rozdęta baza, autoload i wtyczki dokładające własne zapytania w kokpicie. Kroki 2, 6 i 7 z tej listy działają na panel bezpośrednio.
Po wyniku kroków 1-8: jeśli strona ma cache, aktualne PHP, lekkie obrazy i przejrzany zestaw wtyczek, a czas odpowiedzi serwera nadal przekracza pół sekundy - rezerwy po stronie strony się skończyły. Drugi sygnał to spowolnienia skorelowane z ruchem: strona działa dobrze rano, a muli wieczorem, gdy serwer współdzielony jest najbardziej obciążony.
Wszystkie poradniki z kategorii: WordPress