Wolna strona odstrasza klientów i obniża pozycje w Google. Przechodzimy przez 10 najczęstszych przyczyn - od ciężkich zdjęć i nadmiaru wtyczek po stare PHP i brak cache - z prostą diagnozą „jak sprawdzić, czy to mój przypadek" i konkretną naprawą dla każdej.
Diagnoza na oko („u mnie działa wolno") bywa myląca. Trzy minuty pomiarów da Ci mapę problemów:
Kluczowa wskazówka diagnostyczna: TTFB (czas do pierwszego bajta). Jeśli przekracza ~0,6 s - problem leży po stronie serwera/aplikacji (przyczyny 1-4); jeśli TTFB jest niski, a strona i tak muli - winowajcą jest front (przyczyny 5-10).
Jak rozpoznać: wysoki TTFB (0,8-3 s) na wszystkich podstronach, mimo niedużego ruchu. Naprawa: wtyczka full page cache (LiteSpeed Cache / WP Super Cache / WP Rocket). To pojedynczo największa dźwignia - szczegóły w naszym przewodniku cache od A do Z.
Jak rozpoznać: w panelu hostingu sprawdź wersję - 7.4 lub starsza to czerwona lampka (brak wsparcia bezpieczeństwa + 20-30% straty wydajności względem 8.3/8.4). Naprawa: przełącz wersję w panelu (instrukcja dla DirectAdmin) i przetestuj stronę.
Jak rozpoznać: strona zwalnia w godzinach szczytu, statystyki zużycia procesów/CPU w panelu regularnie pod sufitem; najtańszy pakiet z czasów „strony-wizytówki" dźwiga dziś sklep z tysiącem produktów. Naprawa: sprawdź limity pakietu i technologię (NVMe? LiteSpeed? HTTP/3?); czasem rozwiązaniem jest wyższy pakiet, czasem - zmiana dostawcy na szybszego (przeniesiemy stronę bezpłatnie).
Jak rozpoznać: wolne są tylko strony dynamiczne (koszyk, wyszukiwarka, panel), a baza waży setki MB przy niewielkiej stronie. Naprawa: czyszczenie rewizji/transientów (WP-Optimize), kontrola danych autoload, dla sklepów - Redis. Przed sprzątaniem: kopia bazy.
Jak rozpoznać: GTmetrix/wodospad pokazuje pliki JPG/PNG po 1-8 MB. Naprawa: konwersja do WebP, przeskalowanie do realnych wymiarów, lazy loading. Hurtowo dla całej biblioteki zrobi to wtyczka - szczegółowy poradnik optymalizacji obrazów publikujemy osobno na blogu.
Jak rozpoznać: kilkadziesiąt aktywnych wtyczek; wynik pogarsza się po instalacji konkretnej. Naprawa: inwentaryzacja - usuń (nie tylko wyłącz) nieużywane; podejrzane sprawdź przez Query Monitor lub test na kopii strony. Jedna wtyczka „wszystko-w-jednym" często zastąpi pięć osobnych.
Jak rozpoznać: wodospad pełen domen third-party (facebook, hotjar, intercom...); PageSpeed wylicza „czas blokowania głównego wątku". Naprawa: zostaw tylko używane narzędzia; resztę ładuj z opóźnieniem lub po interakcji (funkcja „delay JS" we wtyczkach optymalizacyjnych); mapę Google zamień na statyczny obrazek z linkiem.
Jak rozpoznać: nawet pusta podstrona ładuje setki KB CSS/JS motywu. Naprawa: włącz opcje wydajności motywu/buildera, ogranicz animacje i slidery; przy Elementorze przejdź nasz poradnik 10 błędów wydajności (na blogu). Zmiana motywu to ostateczność - najpierw konfiguracja.
Jak rozpoznać: nagłówki odpowiedzi bez content-encoding (gzip/brotli); zasoby ładowane po HTTP/1.1 kolejkują się jeden za drugim. Naprawa: to konfiguracja serwera - na porządnym hostingu (w tym u nas) gzip/brotli i HTTP/2/3 są włączone domyślnie; jeśli Twój dostawca tego nie ma, to sygnał do zmiany.
Jak rozpoznać: nagłe spowolnienie bez zmian na stronie, dziwne procesy, skoki transferu w statystykach, obce pliki w katalogach. Naprawa: skan antymalware, zmiana haseł, odtworzenie z czystej kopii; procedura krok po kroku - w naszym poradniku zabezpieczania WordPressa. Boty przyblokuj regułami firewalla hostingu.
Cel praktyczny: główna treść widoczna do 2,5 s na telefonie (metryka LCP), TTFB poniżej 0,6 s (dobry hosting z cache osiąga <0,2 s). Poniżej tych progów użytkownicy przestają odczuwać czekanie.
Reguła TTFB z początku artykułu + prosty test: postaw czystego WordPressa na tym samym hostingu (podkatalog/subdomena). Śmiga? Problem w stronie. Muli? Hosting. Możemy też zdiagnozować to za Ciebie - napisz.
Full page cache na szybkim hostingu. Druga w kolejności: obrazy. Te dwie pozycje odpowiadają zwykle za 70-80% problemu.
Wolna strona to prawie zawsze suma kilku typowych zaniedbań - i prawie nigdy przypadek beznadziejny. Zmierz, zlokalizuj (serwer czy front?), napraw według listy - a jeśli okaże się, że sufit stanowi sam hosting, przenieś stronę tam, gdzie NVMe, LiteSpeed, HTTP/3 i PHP 8.4 są standardem: McProdukt, z bezpłatną migracją i pomiarem przed/po.
Wszystkie poradniki z kategorii: Szybkość i wydajność