Jak przyspieszyć WordPress — optymalizacja prędkości krok po kroku

Wynik 34/100 w PageSpeed Insights. Ładowanie 7,4 sekundy. „Core Web Vitals: Niewystarczające” w Google Search Console.

Widziałeś którąś z tych liczb — i prawdopodobnie dlatego tutaj jesteś.

Dobra wiadomość: większość wolnych stron WordPress jest wolna z przewidywalnych powodów i można je naprawić w przewidywalny sposób. Zła wiadomość: nie ma jednego magicznego ustawienia które rozwiąże wszystko naraz. Jest kolejność działań — od najtańszych i najszybszych, do bardziej zaawansowanych.

Ten artykuł to ta kolejność.

Jak zmierzyć prędkość WordPress — narzędzia i co mierzą

Zanim cokolwiek zmienisz, zmierz stan obecny. Inaczej nie będziesz wiedział czy Twoje działania przyniosły efekt.

Google PageSpeed Insights (pagespeed.web.dev) — podstawowe narzędzie. Ocenia stronę w skali 0–100 osobno dla mobile i desktop. Ważniejsza jest zakładka „Core Web Vitals” niż sam wynik liczbowy. Bezpłatne.

GTmetrix (gtmetrix.com) — bardziej szczegółowe. Pokazuje waterfall ładowania zasobów — widać dokładnie które elementy ładują się najdłużej. Darmowy plan pozwala testować z jednej lokalizacji.

Google Search Console → zakładka „Dane o stronie” → „Core Web Vitals” — dane z prawdziwych użytkowników Twojej strony (nie syntetyczne jak PageSpeed). To jest miarodajne. Dane pojawiają się tylko gdy strona ma wystarczający ruch — jeśli widzisz „brak danych”, strona jest za mała lub za mało odwiedzana.

Czego nie mierzyć za pomocą tylko jednego narzędzia: PageSpeed Insights pokazuje ocenę laboratoryjną (symulowaną). GSC pokazuje dane polowe (realne). Oba są ważne — laboratoryjne mówi co naprawiać, polowe mówi czy to działa dla Twoich użytkowników.

Core Web Vitals — co Google faktycznie ocenia

Google od 2021 roku oficjalnie uwzględnia Core Web Vitals jako sygnał rankingowy. Nie jest to decydujący czynnik (treść i linki wciąż ważą więcej), ale przy zbliżonej jakości stron — wolna strona przegra z szybką.

Trzy metryki które mierzą Core Web Vitals:

LCP — Largest Contentful Paint (Ładowanie największego elementu). Mierzy kiedy główna treść strony staje się widoczna. Cel: poniżej 2,5 sekundy. Najczęstszy winowajca w WordPress: duże niezoptymalizowane zdjęcie w nagłówku (hero image).

INP — Interaction to Next Paint (Responsywność na interakcje). Mierzy jak szybko strona reaguje na kliknięcia, przewijanie, wypełnianie formularzy. Cel: poniżej 200ms. Najczęstszy winowajca: ciężki JavaScript, zbyt wiele skryptów analitycznych lub reklamowych.

CLS — Cumulative Layout Shift (Stabilność układu). Mierzy czy elementy strony „skaczą” podczas ładowania. Cel: poniżej 0,1. Najczęstszy winowajca: obrazy bez zdefiniowanych wymiarów, czcionki webowe bez font-display.

Poprawa każdej z tych metryk ma swoje konkretne techniki — opisuję je w sekcji działań poniżej.

Co najczęściej spowalnia WordPress

Przed przystąpieniem do optymalizacji warto wiedzieć gdzie zazwyczaj leży problem. W 80% przypadków jest to jedno lub kilka z poniższych:

Zły hosting. Najtańszy shared hosting (30–50 zł/mies) to najczęstszy powód wolnego WordPress. Serwer współdzielony z setkami innych stron, bez PHP 8.x, bez opcache, z mechanicznym dyskiem zamiast SSD. Żadna optymalizacja nie naprawi złego hostingu — to jest fundament.

Brak cache. WordPress generuje stronę dynamicznie przy każdym zapytaniu — łączy się z bazą danych, składa PHP, zwraca HTML. Cache zapisuje gotowy HTML i serwuje go bez odpytywania bazy. Różnica między stroną z cache a bez może wynosić 3–5 sekund ładowania.

Niezoptymalizowane obrazy. Zdjęcia wrzucone bezpośrednio z aparatu (3–8 MB, JPEG 4000×3000px) na stronę gdzie wyświetlają się w 800px to klasyczny problem. Strona ładuje dziesiątki razy więcej danych niż potrzebuje.

Za dużo wtyczek. Każda aktywna wtyczka ładuje swoje skrypty i style przy każdym załadowaniu strony — nawet jeśli na tej konkretnej podstronie nie jest używana. 40 aktywnych wtyczek to 40 okazji do spowolnienia.

Brak CDN. Statyczne zasoby (CSS, JS, obrazy) serwowane z jednego serwera gdzieś w Niemczech — dla użytkownika z Polski to i tak ok., ale bez CDN strona ładuje wszystko z jednego miejsca. CDN replikuje zasoby do dziesiątek lokalizacji globalnie.

Nieaktualne oprogramowanie. PHP 7.x jest wolniejszy od PHP 8.x o 30–50% przy typowych obciążeniach WordPress. Część hostingów wciąż domyślnie korzysta ze starszych wersji.

Jak przyspieszyć WordPress — kolejność działań

Oto hierarchia działań od najtańszych i najszybszych, do bardziej zaawansowanych. Zacznij od początku — nie od końca.

Krok 1 — Hosting: fundament którego nic nie zastąpi

Jeśli Twoja strona działa na hostingu za 3 zł/mies — żaden plugin Ci nie pomoże. Hosting to podstawa.

Co szukać w hostingu dla WordPress:

• PHP 8.1 lub 8.2 z opcache włączonym
• Dysk SSD NVMe (nie HDD, nie SATA SSD)
• Dedykowany serwer lub VPS zamiast shared hosting przy ruchu >1000 odwiedzin/dzień
• Serwer w Polsce lub Niemczech (dla polskich stron)
• HTTP/2 lub HTTP/3 obsługiwane

Zmiana hostingu jest jednorazowa i może poprawić wyniki o 40–60% bez żadnych innych zmian.

Krok 2 — Cache: najtańszy zysk

Zainstaluj wtyczkę cache. Dla większości stron rekomendujemy:

WP Rocket (ok. 60 USD/rok) — najprostszy w konfiguracji, działa poprawnie po instalacji bez zaawansowanej wiedzy. Obsługuje cache stron, minifikację CSS/JS, lazy loading obrazów, prefetching DNS.

LiteSpeed Cache — bezpłatna, ale wymaga hostingu LiteSpeed (nie Apache). Jeśli Twój hosting go obsługuje — to najlepsza darmowa opcja.

W3 Total Cache — bezpłatny, ale konfiguracja jest skomplikowana. Łatwo zepsuć. Dla zaawansowanych użytkowników lub deweloperów.

Po włączeniu cache sprawdź czy strona wyświetla się poprawnie — w szczególności formularze, koszyk WooCommerce, strony logowania. Cache musi być wyłączony dla zalogowanych użytkowników i stron dynamicznych.

Szczegółowe porównanie WP Rocket i W3 Total Cache opisujemy w osobnym artykule.

Krok 3 — Obrazy: największy potencjał bez ryzyka

Obrazy zazwyczaj odpowiadają za 60–80% wagi strony. Optymalizacja obrazów to działanie bez skutków ubocznych — możesz to zrobić bezpiecznie.

Konwertuj na WebP. Format WebP jest 25–35% lżejszy od JPEG przy tej samej jakości wizualnej. WordPress 5.8+ obsługuje WebP natywnie. Wtyczki jak Imagify, ShortPixel lub Smush przepiszą istniejące obrazy i nowe wgrywanie automatycznie konwertują.

Włącz lazy loading. Obrazy poniżej ekranu nie muszą ładować się od razu. WordPress od wersji 5.5 dodaje loading="lazy" automatycznie, ale wtyczki optymalizacyjne robią to lepiej (kontrola nad hero image który lazy loadingu nie powinien mieć).

Definiuj wymiary obrazów. Każdy obraz bez atrybutów width i height powoduje CLS (przesunięcia układu). W WordPress — dodaj wymiary przy wgrywaniu obrazu lub przez CSS.

Użyj właściwego rozmiaru. WordPress generuje kilka rozmiarów każdego obrazu automatycznie. Upewnij się że w <img> ładujesz właściwy rozmiar — nie oryginał 4000px dla miniatury wyświetlanej w 300px.

Krok 4 — Audyt wtyczek: usuń co nie jest potrzebne

Otwórz listę wtyczek i przejdź każdą:

1. Czy ta wtyczka jest aktywnie używana?
2. Czy robi coś czego nie robi żadna inna wtyczka na liście?
3. Czy ta funkcjonalność jest wbudowana w WordPress lub motyw?

Usuń (nie tylko dezaktywuj) wszystko co nie przeszło tej weryfikacji. Każda aktywna wtyczka to potencjalne zapytania do bazy danych, dodatkowe skrypty i style.

Sprawdź też Query Monitor (bezpłatna wtyczka diagnostyczna) — pokazuje ile zapytań do bazy danych generuje każda podstrona i które wtyczki za nie odpowiadają. Norma to 20–40 zapytań. Powyżej 100 — problem.

Sprawdź co ładuje się w nagłówku strony: skrypty śledzenia, piksel Facebooka, Google Tag Manager z dziesiątkami tagów — każdy z nich kosztuje milisekundy. GTM powinien zarządzać skryptami zamiast wgrywać je bezpośrednio, ale sam GTM też ma wagę.

Krok 5 — Baza danych: utrzymanie higieny

Przez lata użytkowania baza danych WordPress rośnie: stare rewizje wpisów, tymczasowe dane transient, dane usuniętych wtyczek.

WP-Optimize lub Advanced DB Cleaner pozwalają wyczyścić:

• Rewizje wpisów (WordPress domyślnie trzyma każdą wersję — po kilku latach setki bezużytecznych wierszy)
• Trashed posty i komentarze
• Expired transients (tymczasowe dane cache)
• Tabele po usuniętych wtyczkach

Uwaga: przed czyszczeniem bazy danych zawsze zrób backup. To operacja nieodwracalna.

Krok 6 — CDN: dla treści statycznych

Content Delivery Network replikuje Twoje pliki CSS, JavaScript, obrazy i fonty do serwerów na całym świecie. Użytkownik z Wrocławia ładuje obrazy z serwera w Warszawie lub Frankfurcie — nie z Singapuru.

Dla polskich stron z polskim ruchem CDN ma mniejszy efekt niż dla stron globalnych — serwer i tak jest blisko. Ale CDN odciąża główny serwer i przyspiesza serwowanie plików statycznych.

Cloudflare (bezpłatny plan) to minimum. Pełny CDN jak BunnyCDN lub KeyCDN (~10–30 zł/mies) daje lepsze wyniki.

Większość wtyczek cache integruje się z CDN automatycznie.

Krok 7 — CSS i JavaScript: dla zaawansowanych

To ostatni krok — bo jest najbardziej ryzykowny. Minifikacja i łączenie CSS/JS, eliminacja render-blocking resources, defer/async dla skryptów — każda z tych operacji może zepsuć wygląd lub funkcjonalność strony.

WP Rocket i LiteSpeed Cache mają te opcje — ale muszą być włączane stopniowo z testowaniem po każdej zmianie.

Konkretna zmiana która przynosi duże efekty bezpiecznie: preload kluczowych czcionek i dodanie font-display: swap — eliminuje FOUT (flash of unstyled text) i poprawia LCP. Można to zrobić przez wtyczkę lub ręcznie przez functions.php.

Co możesz zrobić sam, co wymaga dewelopera

Większość kroków 1–5 można zrobić samodzielnie przy odrobinie cierpliwości i backupie przed każdą zmianą.

Jeśli po przejściu kroków 1–5 Core Web Vitals wciąż są czerwone — problem leży w kodzie motywu lub konfiguracji serwera. To jest moment kiedy warto zaangażować dewelopera.

Diagnozujemy i naprawiamy problemy z wydajnością w ramach opieki nad WordPress lub jako jednorazowe zlecenie — opisz nam sytuację na stronie SEO i optymalizacja WordPress.

Najczęstsze pytania o prędkość WordPress

Jak sprawdzić prędkość strony WordPress?

Użyj Google PageSpeed Insights (pagespeed.web.dev) — wpisz adres strony i dostaniesz wynik dla mobile i desktop. Dla bardziej szczegółowych danych: GTmetrix (pokazuje waterfall zasobów). Dla danych z realnych użytkowników: Google Search Console → Dane o stronie → Core Web Vitals.

Dlaczego WordPress jest wolny?

Najczęstsze przyczyny: zły hosting (shared hosting za 30 zł/mies), brak cache (strona generuje się dynamicznie przy każdym zapytaniu), niezoptymalizowane obrazy (oryginały zdjęć z aparatu zamiast skompresowanych WebP), za dużo aktywnych wtyczek. Wolność nie jest wbudowana w WordPress — jest efektem braku optymalizacji.

Czy WP Rocket naprawia Core Web Vitals?

WP Rocket poprawia LCP (przez cache i lazy loading) i CLS (przez optymalizację czcionek). Na INP ma mniejszy wpływ — to metryka związana z kodem JavaScript, który często pochodzi z zewnętrznych skryptów analitycznych, reklamowych lub z motywu. WP Rocket nie przepisze kodu motywu.

Jak poprawić LCP w WordPress?

LCP to czas ładowania największego elementu widocznego na ekranie — najczęściej hero image lub nagłówek. Aby poprawić LCP: zoptymalizuj obraz hero (WebP, właściwy rozmiar), dodaj <link rel="preload"> dla tego obrazu, upewnij się że serwer szybko odpowiada (dobry hosting + cache), przenieś render-blocking CSS do krytycznego. Cel: poniżej 2,5 sekundy.

Czy prędkość strony wpływa na pozycje Google?

Tak, ale to nie jest decydujący czynnik. Google oficjalnie uwzględnia Core Web Vitals jako sygnał rankingowy od 2021 roku. Przy zbliżonej jakości treści i linków — szybsza strona może wygrać z wolną. Ale wolna strona z doskonałą treścią zazwyczaj wciąż wyprzedza szybką stronę z kiepską treścią. Prędkość to „tiebreaker”, nie główny czynnik.

Co to jest cache WordPress i jak działa?

WordPress generuje każdą stronę dynamicznie: łączy się z bazą danych, wykonuje PHP, zwraca HTML. Cache zapisuje gotowy wynik tej operacji jako statyczny plik HTML. Przy kolejnym zapytaniu serwer zwraca gotowy plik zamiast generować stronę od nowa — jest 10–50× szybciej. Cache musi być wyłączony dla zalogowanych użytkowników i stron dynamicznych (koszyk, checkout, panel klienta).

Masz wolną stronę i nie wiesz od czego zacząć?

Audyt wydajności WordPress to jeden z elementów naszej opieki nad WordPress — sprawdzamy Core Web Vitals, diagnozujemy źródło problemów i naprawiamy w ramach pakietu.

Jeśli wolisz jednorazową optymalizację — napisz do nas przez stronę SEO i optymalizacja WordPress. Opisz swój wynik PageSpeed i stronę — wrócimy z diagnozą.

Opisz nam problem → lub zadzwoń: +48 883-655-181

Artykuł napisany przez zespół SzamaniWP — agencję specjalizującą się wyłącznie w WordPress od 2012 roku.