Jak przyspieszyć WordPressa: od hostingu po bazę danych

Większość wolnych stron na WordPressie działa wolno z innego powodu, niż sądzą ich właściciele. Zanim zainstalujesz kolejną wtyczkę, zrób pomiary. Czas do pierwszego bajtu (TTFB) pokazuje, ile serwer potrzebuje na wygenerowanie HTML; jeśli na stronie z cache przekracza mniej więcej 600 ms, problem leży po stronie serwera. Largest Contentful Paint (LCP) pokazuje, kiedy faktycznie pojawia się główna treść, a Google za dobry wynik uznaje do 2,5 sekundy. Uruchom PageSpeed Insights, aby zobaczyć dane od prawdziwych użytkowników, a potem WebPageTest lub kartę „Sieć” w przeglądarce, by sprawdzić, co i w jakiej kolejności się ładuje. Zapisz wyniki: każda z poniższych zmian powinna poprawić któryś z nich, a jeśli nie poprawia — cofnij ją.

Zacznij od samego dołu stosu, bo żadna wtyczka nie naprawi wolnego serwera. Najpierw sprawdź wersję PHP: WordPress na PHP 8.x działa wyraźnie szybciej niż na 7.x, a wersje starsze niż 8.2 nie dostają już poprawek bezpieczeństwa. Upewnij się, że włączony jest OPcache, dzięki któremu PHP trzyma skompilowany kod w pamięci, zamiast przy każdym żądaniu od nowa parsować te same pliki. Liczy się też dysk: WordPress czyta setki małych plików na każdą stronę, a dyski NVMe radzą sobie z tym znacznie lepiej niż SSD SATA. Największy pojedynczy zysk daje jednak cache na poziomie serwera, gdy serwer WWW zwraca zapisaną stronę w ogóle bez uruchamiania PHP.

Tu wybór planu spotyka się z wyborem wtyczki cache. Na naszym hostingu WordPress anonimowi odwiedzający dostają stronę z cache bezpośrednio od serwera WWW, a PHP działa tylko dla zalogowanych użytkowników i wysyłanych formularzy, więc zadanie wtyczki sprowadza się do czyszczenia cache właściwych stron po publikacji. Na hostingu bez cache serwera statyczne pliki HTML zapisuje zamiast tego wtyczka, na przykład WP Super Cache, W3 Total Cache lub WP Rocket. Wybierz jedną, nie dwie: kilka wtyczek cache walczy o te same reguły i serwuje nieaktualne albo zepsute strony. Jeśli serwer działa na LiteSpeed, zwykle najlepiej sprawdza się jego własna wtyczka.

Obrazy są zwykle najcięższą częścią strony i najłatwiej je poprawić. Konwertuj przesyłane pliki do WebP lub AVIF — przy tej samej jakości są one zazwyczaj o 25–50% mniejsze od JPEG, a WordPress obsługuje WebP od wersji 5.8, a AVIF od 6.5. Nie wgrywaj zdjęcia o szerokości 4000 pikseli, by wyświetlić je w 800: WordPress generuje kilka rozmiarów i dzięki srcset pozwala przeglądarce wybrać właściwy, ale tylko wtedy, gdy motyw poprawnie podaje rozmiary obrazów. Natywne leniwe ładowanie opóźnia obrazy poniżej pierwszego ekranu, jednak główny obraz powinien ładować się od razu, bo leniwe ładowanie elementu LCP to jeden z najczęstszych sposobów na pogorszenie tego wyniku.

Każda aktywna wtyczka dodaje kod PHP, a wiele z nich także zapytania do bazy, skrypty i style na każdej stronie, niezależnie od tego, czy są tam potrzebne. Za pomocą Query Monitor sprawdź, które wtyczki zabierają najwięcej czasu, wyłącz te, których już nie używasz, a przy najbliższym redesignie zastąp motyw oparty na page builderze lekkim motywem blokowym. Potem zajmij się bazą danych. Opcje autoload są wczytywane przy każdym żądaniu, więc utrzymuj ich łączny rozmiar wyraźnie poniżej megabajta i usuwaj pozostałości po odinstalowanych wtyczkach. Ogranicz liczbę rewizji w wp-config.php, usuwaj wygasłe transienty i zleć to WP-CLI lub wtyczce czyszczącej regularnie, a nie jednorazowo.

WooCommerce zmienia zasady, bo jego najważniejszych stron nie da się cache’ować. Koszyk, kasa i konto klienta są inne dla każdego odwiedzającego, dlatego trzeba je wyłączyć z cache stron — inaczej jeden klient może zobaczyć koszyk innego. Oznacza to, że PHP i baza danych wykonują prawdziwą pracę na każdym etapie zakupu. Trwały cache obiektów, na przykład Redis, przechowuje wyniki powtarzających się zapytań w pamięci, a High-Performance Order Storage przenosi zamówienia z ogólnej tabeli wpisów do osobnych tabel. Plan WP Pro sam konfiguruje cache obiektów oraz wyjątki dla koszyka i kasy — to minimum, którego sklep potrzebuje, by pozostać szybkim.

Jeśli to wszystko zostało zrobione, a panel administracyjny nadal działa ociężale, kasa zwalnia w czasie promocji albo TTFB zmienia się w zależności od pory dnia, wąskim gardłem nie jest już konfiguracja, lecz współdzielony procesor. To moment, by przejść z hostingu WordPress na hosting premium, gdzie rdzenie CPU i pamięć są zarezerwowane wyłącznie dla Twojej strony, kopie zapasowe powstają co godzinę, a zgłoszenia trafiają od razu do starszego inżyniera. Plan Premium S kosztuje od €24.99 miesięcznie. W WebHostFlow zmiana planu odbywa się bez migracji — to samo konto, te same ścieżki, ten sam adres IP — więc następnego dnia możesz zmierzyć wszystko ponownie i sprawdzić, czy wyniki się poprawiły.