Co naprawdę spowalnia ładowanie strony na WordPressie?
Sam WordPress po czystej instalacji ładuje się poniżej sekundy. Problem zaczyna się przy pierwszej wtyczce, pierwszym motywie i pierwszym obrazie wrzuconym bez kompresji. Po audytach w GTmetrix i PageSpeed Insights widzę pięć powtarzających się przyczyn wolnego ładowania stron.
- Wtyczki ładujące własne skrypty CSS i JavaScript na każdej podstronie, nawet tam gdzie nie są używane.
- Obrazy w oryginalnej rozdzielczości bez konwersji do WebP i bez lazy loading poniżej pierwszego ekranu.
- Brak wtyczki pamięci podręcznej, przez co każde wejście generuje pełne zapytanie do bazy danych MySQL.
- Hosting współdzielony z TTFB powyżej 800 ms i przestarzałą wersją PHP 7.x zamiast 8.2 lub 8.3.
- Niezoptymalizowana baza danych z tysiącami rewizji wpisów, transientsów i tabel po dawno usuniętych pluginach.
- Nie zaktualizowana strona na WordPress, która nie jest przystosowana do wtyczek i innych komponentów
Wtyczki i motyw WordPress- ile jest za dużo
Liczba wtyczek w WordPress sama w sobie nic nie mówi. Miałem projekt z 38 aktywnymi pluginami i wynikiem 92 w PageSpeed. Na innej stronie 11 wtyczek generowało TTFB powyżej dwóch sekund. Sprawdzam to przez Query Monitor, który pokazuje ile milisekund i zapytań SQL dokłada każdy plugin do załadowania strony. Ciężkie motywy wielofunkcyjne typu Avada czy flavor potrafią same wstrzyknąć 300-500 KB kodu CSS i JS zanim przeglądarka wyświetli pierwszą treść. Na projektach nastawionych na szybkość działania strony wybieram GeneratePress lub Kadence. Startują poniżej 50 KB i nie ładują modułów, których nie aktywuję. Usuwanie nieużywanych wtyczek to pierwszy krok, ale sam w sobie nie wystarczy jeśli te pozostałe są źle napisane.
Hosting i wersja PHP a czas odpowiedzi serwera
Przesiadka z hostingu współdzielonego na serwer z LiteSpeed i PHP 8.3 skróciła TTFB jednego z moich projektów z 920 do 180 ms. Bez jednej zmiany w kodzie strony. Benchmarki WordPressa na PHP 8.3 pokazują niemal trzykrotnie krótszy czas wykonania skryptów niż na PHP 7.4. Zmianę wersji robię przez panel hostingu, ale zawsze testuję zgodność wtyczek na środowisku stagingowym przed przełączeniem. Zarządzany hosting WordPress z obsługą object cache Redis eliminuje powtarzalne zapytania SQL. Przy sklepach WooCommerce z dużą liczbą produktów to potrafi obniżyć czas ładowania strony o kolejne 30-40%.
Jak zmierzyć szybkość strony WordPress?
Zanim cokolwiek zmienisz, potrzebujesz punktu odniesienia. Testuję każdą stronę minimum trzema narzędziami, bo każde mierzy co innego. Google PageSpeed Insights pokazuje wyniki Lighthouse i dane z realnych użytkowników z Chrome UX Report. GTmetrix daje waterfall, czyli dokładną kolejność ładowania każdego zasobu z czasem w milisekundach. WebPageTest pozwala wybrać lokalizację serwera testowego i przetestować stronę na throttlowanym połączeniu 3G. Pojedynczy test to za mało, bo czas ładowania strony WordPress waha się w zależności od obciążenia serwera w danej chwili. Robię minimum trzy pomiary i biorę medianę.
- Otwórz przeglądarkę w trybie incognito, żeby pamięć podręczna nie fałszowała wyników.
- Wejdź na pagespeed.web.dev i wklej adres URL strony głównej oraz jednej podstrony wewnętrznej.
- Zapisz wyniki Core Web Vitals: LCP, INP i CLS, zarówno z danych polowych jak i laboratoryjnych.
- Otwórz gtmetrix.com i przetestuj ten sam URL. Przejdź do zakładki waterfall i znajdź zasoby ładujące się najdłużej.
- Sprawdź sekcję możliwości w PageSpeed Insights. Posortuj sugestie po szacowanym zysku w sekundach.
- Zrób zrzuty ekranu wszystkich wyników. To twój punkt odniesienia przed jakąkolwiek optymalizacją.
- Powtórz test po każdej zmianie na stronie, żeby zmierzyć realny wpływ pojedynczej optymalizacji.
Google PageSpeed Insights i metryki Core Web Vitals
PageSpeed Insights to jedyne narzędzie, które łączy dane laboratoryjne Lighthouse z danymi polowymi z Chrome UX Report. Dane polowe pokazują jak strona działa u realnych użytkowników na ich urządzeniach. Dane laboratoryjne to symulacja w kontrolowanych warunkach. Trzy metryki Core Web Vitals, na które patrzę w pierwszej kolejności to LCP, INP i CLS. Te wskaźniki Google traktuje jako sygnał rankingowy. Wynik liczbowy 0-100 w PageSpeed to orientacja, ale realne decyzje optymalizacyjne podejmuję na podstawie konkretnych metryk z zakładki diagnostyka.
| Metryka | Co mierzy | Dobry wynik | Wymaga poprawy | Słaby wynik |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Czas renderowania największego widocznego elementu na ekranie | Poniżej 2.5 s | 2.5 s do 4.0 s | Powyżej 4.0 s |
| INP (Interaction to Next Paint) | Opóźnienie reakcji strony na kliknięcie, tap lub naciśnięcie klawisza | Poniżej 200 ms | 200 ms do 500 ms | Powyżej 500 ms |
| CLS (Cumulative Layout Shift) | Przesunięcia układu strony podczas ładowania, np. skaczące elementy | Poniżej 0.1 | 0.1 do 0.25 | Powyżej 0.25 |
| FCP (First Contentful Paint) | Czas do wyświetlenia pierwszego elementu treści na ekranie | Poniżej 1.8 s | 1.8 s do 3.0 s | Powyżej 3.0 s |
| TTFB (Time to First Byte) | Czas odpowiedzi serwera na pierwsze zapytanie przeglądarki | Poniżej 800 ms | 800 ms do 1800 ms | Powyżej 1800 ms |
Z PageSpeed 40 na 82 — optymalizacja strony na Elementorze
Jak uporządkowanie struktury, obrazów i wtyczek przywróciło konwersję klientowi z Tomaszowa Mazowieckiego.
Problem: strona, która odstraszała klientów zanim zdążyli zobaczyć ofertę
Klient prowadzący firmę usługową z Tomaszowa Mazowieckiego zgłosił się z konkretnym problemem: formularz kontaktowy na stronie generował coraz mniej zapytań, mimo że ruch z Google utrzymywał się na stałym poziomie. Strona działała na WordPressie z Elementorem i wizualnie wyglądała dobrze, ale użytkownicy opuszczali ją zanim ta zdążyła się załadować.
Na urządzeniach mobilnych strona ładowała się ponad 7 sekund, a przejście między zakładkami trwało 2–3 sekundy z widocznym zamrożeniem interfejsu. Użytkownik klikał w menu i przez chwilę nic się nie działo — na telefonie wygląda to jak zawieszenie się strony. Bounce rate na stronie głównej wynosił 72%, a współczynnik konwersji z formularza kontaktowego spadł w ciągu pół roku z 3,2% do 1,1%.
Pierwsze testy w Google PageSpeed Insights potwierdziły to, co podejrzewałem:
| Metryka | Mobile | Desktop |
|---|---|---|
| Wynik PageSpeed | 40 / 100 | 60 / 100 |
| LCP (Largest Contentful Paint) | 6.8 s | 3.9 s |
| INP (Interaction to Next Paint) | 480 ms | 310 ms |
| CLS (Cumulative Layout Shift) | 0.32 | 0.18 |
| TTFB (Time to First Byte) | 1.4 s | 1.2 s |
| Całkowita waga strony | 5.2 MB | 5.2 MB |
Diagnoza: trzy warstwy problemu
Po audycie w GTmetrix, Query Monitor i ręcznym przeglądzie kodu źródłowego zidentyfikowałem trzy główne przyczyny.
Obrazy bez jakiejkolwiek optymalizacji
W bibliotece mediów znajdowały się pliki graficzne o wadze 2–3 MB każdy. Zdjęcia z sesji produktowej zostały wgrane prosto z aparatu w rozdzielczości 4000×3000 px, a wyświetlały się w kontenerze o szerokości 600 px. Strona główna ładowała łącznie 14 obrazów o łącznej wadze ponad 18 MB. Żaden nie był w formacie WebP. Żaden nie miał ustawionego lazy loading.
Przeładowana struktura Elementora
Strona korzystała z Elementora w sposób, który spotykam na co trzecim audycie: dziesiątki zagnieżdżonych kontenerów, sekcji i kolumn, z których wiele było pustych lub pełniło wyłącznie funkcję spacera. Na stronie głównej naliczyłem 47 kontenerów, z czego 19 nie zawierało żadnej widocznej treści.
Każdy taki kontener generuje dodatkowy kod HTML — puste divy, klasy CSS, atrybuty data. W praktyce przekłada się to na konkretny problem: stosunek kodu HTML do faktycznej treści. Google analizuje ten wskaźnik. Gdy strona ma 4000 linii HTML, a treść zajmuje 200, algorytm widzi stronę przeładowaną kodem i ubogą w wartość. Na tej stronie stosunek treści do kodu wynosił niecałe 8%, podczas gdy zdrowy poziom to 25–40%.
Elementor ładował też na każdej podstronie pełną bibliotekę ikon, animacji i stylów — niezależnie od tego, czy dana podstrona z nich korzystała.
Wtyczki ładujące się tam, gdzie nie powinny
Na stronie działało 28 aktywnych wtyczek. Część funkcjonalności, które realizowały osobne pluginy, można było osiągnąć natywnie z poziomu Elementora. Formularz kontaktowy obsługiwała osobna wtyczka, choć Elementor Pro ma wbudowany moduł formularzy. Slider na stronie głównej to kolejny plugin z własnym zestawem skryptów. Wtyczka do Google Maps ładowała API na każdej podstronie, choć mapa była osadzona tylko na stronie kontaktowej.
W Query Monitor każde wejście na stronę generowało 127 zapytań do bazy danych i ładowało 34 pliki JavaScript oraz 22 arkusze CSS. Łączna waga skryptów i stylów przekraczała 1,8 MB — zanim przeglądarka zaczęła pobierać obrazy.
Optymalizacja krok po kroku
Optymalizacja obrazów
Wszystkie grafiki przeskalowałem do docelowej szerokości wyświetlania (max 1200 px dla hero, 800 px dla zdjęć w treści) i skonwertowałem do formatu WebP z kompresją na poziomie 82%. Grafiki dekoracyjne i tła dostały kompresję 70%. Dla obrazów poniżej pierwszego ekranu włączyłem lazy loading. Zdjęcie hero i logo ustawiłem na loading=”eager” z atrybutem fetchpriority=”high”, żeby nie pogarszać LCP.
Porządki w strukturze Elementora
Usunąłem 19 pustych kontenerów i połączyłem sekcje, które niepotrzebnie dzieliły treść na osobne bloki. Tam, gdzie klient używał trzech zagnieżdżonych sekcji jako „podkładki” pod jeden przycisk CTA, zastąpiłem je jednym kontenerem z marginesem. Wyłączyłem globalnie ładowanie biblioteki ikon Font Awesome oraz skryptów Motion Effects na podstronach bez animacji.
Po tych zmianach stosunek treści do kodu wzrósł z 8% do 22%.
Redukcja wtyczek
Odinstalowałem 9 wtyczek, których funkcje zastąpiłem natywnym modułem Elementora Pro lub jednolinijkowym kodem w functions.php:
- Formularz kontaktowy → moduł Elementor Forms
- Slider → widget Elementor Carousel
- Google Maps → osadzenie iframe z leniwym ładowaniem, tylko na stronie kontaktowej
- Ikony social media → blok HTML z SVG
- Cookie banner → lżejsza alternatywa z asynchronicznym ładowaniem
Dla pozostałych wtyczek użyłem Asset CleanUp, żeby wyłączyć ich skrypty CSS i JS na podstronach, na których nie są potrzebne.
Cache, minifikacja i kompresja
Zainstalowałem LiteSpeed Cache (hosting klienta działał na serwerze LiteSpeed) i skonfigurowałem cache stron z automatycznym preloadem, minifikację HTML/CSS/JS (każdy typ testowałem osobno), Critical CSS generowany przez QUIC.cloud, opóźnione ładowanie JavaScript do pierwszej interakcji użytkownika, kompresję Brotli na poziomie serwera oraz Object Cache z Redis.
Czyszczenie bazy danych
WP-Optimize wyczyścił 1847 rewizji wpisów, 340 wygasłych transientsów i 12 tabel po dawno usuniętych wtyczkach. Rozmiar bazy zmniejszył się z 95 MB do 28 MB. Ustawiłem limit rewizji na 3 i automatyczne czyszczenie co tydzień.
Wyniki po optymalizacji
| Metryka | Przed (mobile) | Po (mobile) | Przed (desktop) | Po (desktop) |
|---|---|---|---|---|
| Wynik PageSpeed | 40 | 82 | 60 | 95 |
| LCP | 6.8 s | 2.1 s | 3.9 s | 1.2 s |
| INP | 480 ms | 140 ms | 310 ms | 85 ms |
| CLS | 0.32 | 0.04 | 0.18 | 0.02 |
| TTFB | 1.4 s | 380 ms | 1.2 s | 310 ms |
| Waga strony | 5.2 MB | 1.1 MB | 5.2 MB | 1.1 MB |
| Zapytania HTTP | 89 | 31 | 89 | 31 |
Wpływ na biznes
Czas ładowania strony na urządzeniach mobilnych spadł z ponad 7 sekund do 2,4 sekundy. Przejścia między zakładkami stały się natychmiastowe dzięki cache’owi i prefetchowi linków wewnętrznych.
Po miesiącu od wdrożenia optymalizacji dane z Google Analytics pokazały:
Klient z Tomaszowa Mazowieckiego po raz pierwszy od miesięcy zaczął regularnie otrzymywać zapytania z formularza kontaktowego. Szybka strona nie tylko poprawia wynik w PageSpeed — przede wszystkim zmienia to, jak użytkownik odbiera firmę w pierwszych sekundach kontaktu.
Prowadzisz firmę w Tomaszowie Mazowieckim lub okolicach i potrzebujesz strony, która działa szybko od pierwszego dnia?
Sprawdź ofertę → Strony internetowe Tomaszów MazowieckiJaką wtyczkę pamięci podręcznej wybrać? WP Rocket vs LiteSpeed Cache vs WP Super Cache
Wybór wtyczki pamięci podręcznej to jedna z decyzji, która najbardziej wpływa na czas wczytywania strony WordPress. Przetestowałem te trzy na tym samym środowisku: hosting z serwerem LiteSpeed, motyw GeneratePress, 12 aktywnych wtyczek i strona z 45 podstronami. Różnice w wynikach PageSpeed Insights po samej instalacji i bazowej konfiguracji były znaczące. Poniżej zestawiam co oferuje każda z nich i kiedy ma sens.
| Cecha | WP Rocket | LiteSpeed Cache | WP Super Cache |
|---|---|---|---|
| Cena | Od 59 USD/rok za 1 stronę | Darmowa | Darmowa |
| Typ cache | Cache stron, obiektów, przeglądarki | Cache stron, obiektów, ESI, CDN QUIC.cloud | Cache stron (statyczny HTML) |
| Minifikacja CSS/JS | Tak, z łączeniem plików i opóźnionym ładowaniem JS | Tak, z zaawansowaną optymalizacją i łączeniem | Nie, wymaga osobnej wtyczki |
| Optymalizacja obrazów | Lazy loading, brak wbudowanej kompresji | Kompresja, konwersja do WebP, lazy loading | Nie |
| Integracja z CDN | Cloudflare, BunnyCDN, StackPath | Natywna z QUIC.cloud, Cloudflare | Podstawowa obsługa CDN |
| Wymagania serwera | Apache, Nginx, LiteSpeed | Pełna wydajność tylko na serwerze LiteSpeed | Apache, Nginx |
| Czyszczenie bazy danych | Tak, wbudowane | Tak, optymalizacja bazy danych | Nie |
| Preload cache | Tak, automatyczny | Tak, z crawlerem | Tak, podstawowy |
| Critical CSS | Tak, automatyczne generowanie | Tak, z QUIC.cloud | Nie |
| Poziom trudności konfiguracji | Niski, działa dobrze po instalacji | Średni, dużo opcji do ustawienia | Niski, ale ograniczone możliwości |
| Wynik PageSpeed w moim teście (mobile) | 94 | 96 | 78 |
LiteSpeed Cache dał najlepszy wynik, ale tylko dlatego że testowałem na serwerze LiteSpeed. Na Nginx lub Apache ta wtyczka traci połowę swoich funkcji i WP Rocket wygrywa. WP Super Cache sprawdza się na prostych blogach gdzie potrzebujesz tylko podstawowego cachowania stron bez optymalizacji kodu i obrazów. Jeśli nie chcesz płacić i masz hosting z LiteSpeed, wybór jest oczywisty. Jeśli zależy ci na rozwiązaniu które działa wszędzie bez konfiguracji, WP Rocket odpracowuje swoją cenę.
Jak zoptymalizować obrazy na stronie? Kompresja, WebP i lazy loading
Obrazy odpowiadają za 40-60% wagi przeciętnej strony WordPress. Na jednym projekcie e-commerce samo przejście z PNG na WebP i wdrożenie lazy loading obniżyło wagę strony głównej z 4.8 MB do 1.1 MB. LCP spadł z 5.2 do 1.9 sekundy. Optymalizacja zdjęć to najszybszy sposób na poprawę wyniku PageSpeed Insights bez dotykania kodu.
- Przed wgraniem na stronę przeskaluj obrazy do docelowego rozmiaru wyświetlania. Zdjęcie hero o szerokości 1200 px nie potrzebuje pliku źródłowego 4000 px.
- Konwertuj wszystkie obrazy do formatu WebP. Daje 25-35% mniejszy rozmiar pliku niż JPEG przy tej samej jakości wizualnej. Do automatycznej konwersji używam ShortPixel lub Imagify, obie wtyczki przetwarzają też istniejącą bibliotekę mediów.
- Ustaw poziom kompresji na 80-85% dla zdjęć i 70% dla grafik dekoracyjnych. Różnica w jakości jest niewidoczna na ekranie, a oszczędność sięga kilkuset kilobajtów na plik.
- Włącz lazy loading dla wszystkich obrazów poniżej pierwszego ekranu. WordPress od wersji 5.5 dodaje atrybut loading lazy natywnie, ale obrazy w pierwszym widoku (hero, logo) powinny mieć loading eager, żeby nie pogarszać LCP.
- Dodaj atrybut width i height do każdego tagu img. Bez tych wymiarów przeglądarka nie rezerwuje miejsca na obraz i generuje przesunięcia layoutu, czyli wyższy CLS.
- Wyłącz generowanie nieużywanych rozmiarów miniatur w ustawieniach mediów WordPress. Domyślnie WordPress tworzy 3-5 wersji każdego obrazu. Każda zajmuje miejsce na serwerze i spowalnia upload.
- Raz w miesiącu uruchom wtyczkę Media Cleaner, żeby usunąć osierocone pliki graficzne, które nie są przypisane do żadnego wpisu ani podstrony.
Minifikacja CSS, JS i HTML bez rozbijania strony
Surowe pliki CSS i JavaScript w WordPressie zawierają komentarze, spacje i puste linie, które przeglądarka musi pobrać, ale nie potrzebuje do renderowania. Minifikacja kodu usuwa ten balast i zmniejsza wagę zasobów o 10-30%. Problem w tym, że agresywna minifikacja potrafi rozbić stronę. Znikają menu, nie działają formularze, slider przestaje się przesuwać. Dlatego każdą zmianę wdrażam etapami i testuję osobno.
- Zacznij od minifikacji HTML. To najbezpieczniejsza opcja, która praktycznie nigdy nie powoduje konfliktów. W WP Rocket włączam ją w zakładce optymalizacja plików jednym kliknięciem.
- Włącz minifikację CSS i sprawdź stronę na mobile i desktop. Jeśli układ się nie rozjechał, przejdź dalej. Jeśli coś wygląda inaczej, wyłącz łączenie plików CSS i zostaw samą minifikację.
- Minifikację JavaScript włączaj jako ostatnią. Dodaj opóźnione ładowanie JS z opcją delay do interakcji użytkownika. W LiteSpeed Cache ta opcja nazywa się JS defer, w WP Rocket load JavaScript deferred.
- Po każdej zmianie testuj w trybie incognito na mobile. Cache przeglądarki maskuje błędy. Sprawdź menu mobilne, formularze kontaktowe, koszyk WooCommerce i slidery.
- Jeśli konkretny skrypt powoduje problem, dodaj go do listy wykluczeń zamiast wyłączać całą minifikację. W WP Rocket wklejam ścieżkę do pliku JS w polu excluded JavaScript files.
- Usuń nieużywany CSS narzędziem PurgeCSS lub opcją remove unused CSS w WP Rocket. Na typowej stronie WordPress 60-70% pobranego kodu CSS nigdy nie jest wykorzystywane przez przeglądarkę.
- Wygeneruj critical CSS dla pierwszego widoku strony. To fragment stylów potrzebny do wyrenderowania tego co użytkownik widzi bez przewijania. WP Rocket i LiteSpeed Cache generują go automatycznie przez QUIC.cloud.
Kolejność ma znaczenie. Włączenie wszystkiego naraz i szukanie co się zepsuło to strata czasu. Etapowa minifikacja z testem po każdym kroku pozwala złapać konflikt zanim urośnie w problem niewidoczny w panelu admina, ale widoczny dla każdego odwiedzającego.
Optymalizacja bazy danych strony internetowej WordPress z rewizji i transientsów
WordPress zapisuje każdą wersję roboczą wpisu jako osobną rewizję. Po roku prowadzenia bloga z 50 artykułami baza potrafi mieć 2000-3000 zbędnych rekordów. Do tego dochodzą transienty, czyli tymczasowe dane wtyczek które powinny się same usuwać, ale często zostają na stałe. Tabele po dawno odinstalowanych pluginach to trzeci klasyczny problem. Na jednym projekcie optymalizacja bazy danych zmniejszyła jej rozmiar z 340 MB do 85 MB, a czas odpowiedzi serwera spadł o 200 ms. Używam do tego WP-Optimize, która w jednym panelu czyści rewizje, wygasłe transienty, spam w komentarzach i osierocone meta dane. Ograniczam też liczbę rewizji do trzech dodając wp_revisions_to_keep w pliku wp-config.php. Raz w tygodniu WP-Optimize uruchamia się automatycznie przez wbudowany harmonogram. Przy sklepach WooCommerce z dużą liczbą zamówień czyszczę też tabelę wp_options z przeładowanych danych autoload, bo to najczęstsza przyczyna wolnych zapytań SQL, której PageSpeed Insights nie pokaże.
Content Delivery Network i kompresja Brotli – kiedy dają realną różnicę
CDN nie jest potrzebny każdej stronie. Jeśli twój ruch pochodzi z jednego kraju i hosting stoi w tym samym regionie, Content Delivery Network da ci może 50-100 ms różnicy. CDN zaczyna mieć sens przy ruchu międzynarodowym i plikach statycznych powyżej 2 MB na podstronę. Na jednym sklepie WooCommerce z ruchem z Polski i Niemiec wdrożenie Cloudflare skróciło czas wczytywania strony dla niemieckich użytkowników z 3.8 do 1.6 sekundy. Cloudflare w darmowym planie wystarcza dla większości stron WordPress. BunnyCDN za kilka dolarów miesięcznie daje lepszą kontrolę nad cache rules. QUIC.cloud integruje się natywnie z LiteSpeed Cache i generuje critical CSS po stronie chmury. Kompresja Brotli to następca GZIP zmniejszający rozmiar przesyłanych plików o dodatkowe 15-20%. Serwery LiteSpeed i Nginx obsługują Brotli natywnie. Jeśli hosting tego nie wspiera, Cloudflare włącza Brotli automatycznie dla całego ruchu przechodzącego przez ich sieć. Sprawdzam czy działa wklejając URL w narzędziu brotli.pro. Przy stronach z dużą ilością kodu JavaScript różnica między GZIP a Brotli jest widoczna w GTmetrix jako niższy total page size i krótszy czas ładowania strony na połączeniach mobilnych.
Checklista optymalizacji prędkości strony opartej na WordPress
Poniższa lista to kolejność w jakiej przeprowadzam optymalizację wydajności WordPress na każdym projekcie. Kolejność nie jest przypadkowa. Zaczynamy od zmian dających największy efekt przy najmniejszym ryzyku.
- Zmierz szybkość wczytywania strony w Google PageSpeed Insights, GTmetrix i WebPageTest. Zapisz wyniki LCP, INP, CLS i TTFB jako punkt odniesienia.
- Sprawdź wersję PHP w panelu hostingu. Jeśli jest niższa niż 8.2, zaktualizuj wersję php swojego WordPress po przetestowaniu zgodności wtyczek na stagingu.
- Usuń nieużywane wtyczki i motywy. Nie dezaktywuj, tylko usuń całkowicie z instalacji WordPress.
- Zainstaluj wtyczkę pamięci podręcznej. WP Rocket jeśli płacisz, LiteSpeed Cache jeśli hosting to LiteSpeed, WP Super Cache jako darmowe minimum.
- Konwertuj obrazy do WebP przez ShortPixel lub Imagify. Włącz kompresję na poziomie 80-85% dla całej biblioteki mediów.
- Włącz lazy loading dla obrazów i osadzonych filmów. Obrazy w pierwszym widoku ustaw na loading eager.
- Uruchom minifikację HTML, potem CSS, na końcu JavaScript. Testuj po każdym kroku w trybie incognito na mobile.
- Wygeneruj critical CSS i włącz opóźnione ładowanie JS do pierwszej interakcji użytkownika.
- Wyczyść bazę danych z rewizji, transientsów i tabel po usuniętych wtyczkach. Ustaw automatyczny harmonogram w WP-Optimize.
- Włącz kompresję Brotli lub GZIP na serwerze. Jeśli hosting nie obsługuje Brotli, podepnij stronę pod Cloudflare.
- Rozważ CDN jeśli masz ruch międzynarodowy lub strona waży powyżej 2 MB na podstronę.
- Ogranicz zewnętrzne skrypty. Każdy piksel trackingowy, widget social media i osadzona mapa Google dodaje zapytania HTTP.
- Zmierz ponownie wyniki w PageSpeed Insights i GTmetrix. Porównaj z punktem odniesienia z kroku pierwszego.
Najczęściej zadawane pytania
Poniżej 2 sekund na urządzeniach mobilnych. Strony ładujące się w czasie krótszym niż 1 sekunda osiągają najlepsze współczynniki konwersji. Powyżej 3 sekund ponad połowa użytkowników opuszcza stronę zanim zobaczy treść.
Tak, jeśli hosting jest dobry. LiteSpeed Cache na serwerze LiteSpeed daje wyniki porównywalne z płatnym WP Rocket. WP Super Cache sprawdzi się na prostych blogach. Płatne wtyczki oszczędzają czas konfiguracji i oferują funkcje jak critical CSS czy usuwanie nieużywanego kodu w jednym narzędziu.
Jeśli TTFB przekracza 800 ms po wszystkich optymalizacjach po stronie WordPressa, to hosting jest wąskim gardłem. Zmiana na serwer z LiteSpeed, PHP 8.3 i dyskami NVMe potrafi obniżyć czas odpowiedzi o 60-70% bez dotykania kodu strony.
Zainstaluj Query Monitor i otwórz dowolną podstronę. W zakładce queries zobaczysz ile zapytań SQL generuje każdy plugin. W zakładce timing znajdziesz czas wykonania PHP każdego komponentu. Wyłączaj podejrzane wtyczki po jednej i mierz różnicę w GTmetrix.
AVIF daje 20% lepszą kompresję niż WebP przy porównywalnej jakości. Wsparcie przeglądarek w 2026 roku jest wystarczające dla większości projektów. ShortPixel i Imagify obsługują konwersję do AVIF. Wdrażam go jako pierwszy wybór z WebP jako fallback dla starszych przeglądarek.
Ustawiam automatyczne czyszczenie raz w tygodniu w WP-Optimize. Przy sklepach WooCommerce z dużą liczbą zamówień robię to codziennie. Ręczny przegląd tabeli wp_options pod kątem przeładowanego autoload zalecam raz w miesiącu.
Oczywiście. Głównymi powodami są niepoprawnie zarządzanie kontenerami i sekcjami, za duże obrazy, brak wtyczki do cache, duża ilość wtyczek. Dodanie każdego kontenera powoduje umieszczenie dodatkowego kodu strony.
