Wolny WordPress to nie tylko gorszy wynik w PageSpeed Insights. Długi czas oczekiwania na największy element strony, opóźniona reakcja po kliknięciu czy przesuwające się podczas ładowania elementy wpływają przede wszystkim na użytkownika. Właśnie dlatego podczas optymalizacji nie próbuję za wszelką cenę uzyskać „100 punktów”, tylko szukam elementów, które realnie spowalniają stronę i pogarszają Core Web Vitals.
W tym poradniku pokażę Ci, jak podchodzę do optymalizacji Core Web Vitals na WordPressie, co oznaczają LCP, INP i CLS oraz co najczęściej faktycznie daje poprawę zamiast jedynie kosmetycznej zmiany wyniku testu.
- Core Web Vitals obejmują obecnie trzy główne wskaźniki: LCP, INP i CLS.
- Dobre wartości to LCP do 2,5 s, INP do 200 ms i CLS do 0,1.
- PageSpeed Insights pokazuje zarówno dane rzeczywistych użytkowników, jeśli są dostępne, jak i test laboratoryjny Lighthouse.
- Na WordPressie problemy często powodują ciężkie obrazy, JavaScript, rozbudowane wtyczki, page buildery, fonty oraz wolny serwer.
- Cache pomaga, ale nie naprawia automatycznie wszystkich problemów z wydajnością.
- Najpierw diagnozuję konkretny problem, a dopiero później dobieram sposób optymalizacji.
Co to są Core Web Vitals?
Core Web Vitals to zestaw wskaźników wykorzystywanych do oceny doświadczenia użytkownika podczas korzystania ze strony. Z punktu widzenia właściciela WordPressa warto znać przede wszystkim trzy skróty: LCP, INP i CLS.
Mierzy czas potrzebny na wyświetlenie największego istotnego elementu widocznego w obszarze ekranu.
Ocenia responsywność strony podczas interakcji użytkownika, np. kliknięcia lub użycia elementu interfejsu.
Mierzy nieoczekiwane przesunięcia elementów układu podczas korzystania ze strony.
| Wskaźnik | Dobry wynik | Co mierzy? |
|---|---|---|
| LCP | ≤ 2,5 s | Szybkość wyświetlenia największego elementu treści. |
| INP | ≤ 200 ms | Responsywność strony podczas interakcji. |
| CLS | ≤ 0,1 | Stabilność wizualną układu strony. |
Wartości te ocenia się na podstawie doświadczeń użytkowników, a przy klasyfikacji bierze się pod uwagę 75. percentyl wizyt. Oznacza to, że nie wystarczy, aby strona była szybka tylko dla mnie na komputerze podłączonym do szybkiego internetu.
PageSpeed Insights – wynik punktowy to nie wszystko
Jednym z pierwszych narzędzi, do których zaglądam, jest PageSpeed Insights. Trzeba jednak wiedzieć, jak interpretować znajdujące się tam informacje.
PageSpeed może prezentować dane terenowe pochodzące od rzeczywistych użytkowników oraz dane laboratoryjne generowane podczas testu Lighthouse. To nie jest dokładnie to samo.
Wynik Lighthouse może zmieniać się pomiędzy kolejnymi testami. Dlatego nie oceniam kondycji witryny wyłącznie na podstawie tego, czy dostała 72, 89 czy 97 punktów.
Nie optymalizuję strony po to, żeby zrobić 100/100 i wrzucić zrzut ekranu do portfolio. Jeżeli mam wybierać, wolę stabilną, szybko odczuwalną stronę, dobre Core Web Vitals i poprawne działanie wszystkich funkcji niż wynik 100 osiągnięty agresywną optymalizacją, która zaczyna psuć formularze, menu albo skrypty.
Od czego zaczynam optymalizację WordPressa?
Najpierw ustalam, co jest wąskim gardłem. Instalowanie kilku kolejnych wtyczek optymalizacyjnych bez diagnozy często prowadzi jedynie do nakładania się ich funkcji.
Jak poprawić LCP na WordPressie?
LCP jest jednym z problemów, które bardzo często widzę na stronach WordPress. Szczególnie łatwo o niego na stronach z rozbudowanym hero, dużym zdjęciem, sliderem albo ciężkim tłem.
Pierwsze pytanie brzmi: co dokładnie jest elementem LCP? Bez odpowiedzi na nie optymalizacja przypomina zgadywanie.
Zoptymalizuj obraz znajdujący się w hero
Jeżeli elementem LCP jest zdjęcie, sprawdzam jego rozdzielczość, wagę, format oraz sposób ładowania. Nie ma sensu wysyłać na telefon ogromnego obrazu o szerokości kilku tysięcy pikseli, jeżeli użytkownik ogląda go na znacznie mniejszym ekranie.
W zależności od sytuacji wykorzystuję nowoczesne formaty obrazów, odpowiednie rozmiary oraz mechanizmy responsywnych grafik WordPressa.
Uwaga na lazy loading: grafika będąca elementem LCP i widoczna od razu po wejściu na stronę zazwyczaj nie jest dobrym kandydatem do opóźnionego ładowania. Lazy loading świetnie sprawdza się przy obrazach znajdujących się niżej, ale nie powinien bezmyślnie obejmować wszystkiego.
Priorytet ładowania najważniejszego obrazu
Przeglądarka powinna możliwie szybko odkryć zasób odpowiedzialny za LCP. W zależności od implementacji można poprawić sposób jego osadzenia i nadać mu odpowiedni priorytet pobierania.
Ma to szczególne znaczenie, jeśli obraz hero jest odkrywany późno przez CSS albo JavaScript.
Sprawdź czas odpowiedzi serwera
Jeśli serwer długo przygotowuje pierwszy dokument HTML, przeglądarka później dowiaduje się również o grafikach, stylach i pozostałych zasobach. Dlatego problem z LCP nie zawsze leży w samym zdjęciu.
Pomóc może cache strony, odpowiednia konfiguracja PHP, wydajny hosting, ograniczenie ciężkich zapytań i uporządkowanie samego WordPressa.
Jak poprawić INP na WordPressie?
INP dotyczy responsywności strony. W praktyce użytkownik klika przycisk, rozwija menu, wybiera filtr albo wykonuje inną interakcję i oczekuje szybkiej reakcji.
Jednym z głównych obszarów, którym przyglądam się przy słabym INP, jest JavaScript i obciążenie głównego wątku przeglądarki.
Na WordPressie źródłem problemu mogą być między innymi:
- ciężkie skrypty motywu lub page buildera,
- rozbudowane slidery i animacje,
- skrypty reklamowe i marketingowe,
- chaty i widgety zewnętrzne,
- narzędzia analityczne,
- skrypty wtyczek ładowane również tam, gdzie nie są potrzebne,
- duża ilość JavaScriptu wykonywanego podczas interakcji.
Tutaj samo zmniejszenie zdjęć zazwyczaj nie rozwiąże problemu. Trzeba sprawdzić, co blokuje główny wątek i które skrypty rzeczywiście są potrzebne.
Jak poprawić CLS?
CLS jest chyba najłatwiejszy do zauważenia bez żadnego narzędzia. Wchodzisz na stronę, chcesz kliknąć przycisk, a w tym momencie pojawia się inny element i cała zawartość przesuwa się w dół.
Tego typu sytuacje są irytujące dla użytkownika i właśnie je mierzy Cumulative Layout Shift.
Określ wymiary grafik
Przeglądarka powinna wiedzieć, ile miejsca przeznaczyć na obraz jeszcze zanim zostanie on pobrany. Dlatego zwracam uwagę na prawidłowe wymiary obrazów i zachowanie odpowiednich proporcji.
Rezerwuj miejsce na elementy dynamiczne
Banery, formularze, widgety, reklamy czy inne elementy pojawiające się po chwili nie powinny nagle wypychać istniejącej treści.
Uważaj na fonty
Zmiana fontu po jego załadowaniu może wpłynąć na szerokość tekstu, wysokość linii i położenie pozostałych elementów. Dlatego optymalizacja fontów jest ważna nie tylko z punktu widzenia liczby requestów.
Optymalizacja zdjęć na WordPressie
Obrazy są jednym z pierwszych elementów, które sprawdzam na wolnej stronie. Wciąż zdarzają się witryny, na których pojedyncze zdjęcie waży kilka megabajtów, mimo że jest wyświetlane w stosunkowo niewielkim rozmiarze.
Przy optymalizacji grafik zwracam uwagę na:
Nie chodzi o to, żeby każde zdjęcie miało 20 KB i wyglądało źle. Szukam rozsądnego kompromisu pomiędzy jakością wizualną a wagą pliku.
Cache – ważny, ale nie jest magicznym rozwiązaniem
Cache potrafi znacząco przyspieszyć WordPressa. Dzięki niemu serwer nie musi za każdym razem wykonywać całej pracy potrzebnej do wygenerowania tej samej strony.
Problem pojawia się wtedy, gdy oczekujemy, że jedna wtyczka cache naprawi wszystko.
Jeżeli witryna ładuje ogromne grafiki, mnóstwo JavaScriptu, kilka zewnętrznych fontów, rozbudowane widgety i dziesiątki niepotrzebnych zasobów, sam cache nie usunie tych problemów.
Zamiast instalować kilka wtyczek robiących praktycznie to samo, wolę mieć jedno sensownie skonfigurowane rozwiązanie i dokładnie wiedzieć, co ono robi. Nakładanie na siebie minifikacji, opóźniania JavaScriptu, cache i optymalizacji CSS z kilku różnych wtyczek potrafi przynieść więcej problemów niż korzyści.
Czy duża liczba wtyczek spowalnia WordPressa?
Sama liczba nie daje pełnej odpowiedzi. Jedna źle napisana lub bardzo rozbudowana wtyczka może mieć większy wpływ na wydajność niż kilka lekkich.
Dlatego zamiast przyjmować zasadę „maksymalnie 10 wtyczek”, sprawdzam, co konkretna wtyczka robi. Interesuje mnie między innymi, czy wykonuje ciężkie zapytania, ładuje zasoby na każdej podstronie, wykonuje zadania w tle albo dodaje dużo JavaScriptu i CSS.
Usuwam również nieużywane rozwiązania. Jeżeli funkcję można bezpiecznie zrealizować prościej, nie widzę sensu utrzymywania rozbudowanej wtyczki tylko dla jednej drobnej funkcji.
Elementor i inne page buildery – czy muszą być wolne?
Nie. Sam fakt używania Elementora nie oznacza automatycznie, że strona będzie wolna. Trzeba jednak pamiętać, że rozbudowane buildery dają ogromne możliwości, a z nimi łatwo przesadzić.
Problemy zaczynają się wtedy, gdy na jednej stronie mam dziesiątki sekcji, efekty ruchu, animacje, slidery, filmy w tle, wiele dodatków do Elementora i kolejne biblioteki JavaScript.
W praktyce często więcej daje uproszczenie konstrukcji strony niż próba optymalizacji bardzo ciężkiego layoutu kolejnymi narzędziami.
Fonty również mają znaczenie
Kilka rodzin fontów, wiele odmian grubości i pobieranie wszystkiego z zewnętrznych serwerów może dokładać kolejne zasoby potrzebne do wyświetlenia strony.
Dlatego ograniczam liczbę używanych odmian i sprawdzam, czy rzeczywiście potrzebuję wszystkich wariantów. W odpowiednich przypadkach fonty można również hostować lokalnie i zadbać o prawidłowy sposób ich ładowania.
Skrypty zewnętrzne – niewidoczny koszt strony
Część problemów z wydajnością nie pochodzi bezpośrednio z WordPressa. Google Tag Manager, systemy reklamowe, mapy, chaty, piksele marketingowe, narzędzia do nagrywania sesji czy widgety social media również wymagają pobrania i wykonania kodu.
Każdy taki skrypt powinien mieć konkretne uzasadnienie biznesowe. Jeśli narzędzie nie jest używane, usuwam je zamiast pozwalać mu obciążać każdą wizytę użytkownika.
Nie opóźniam jednak bezmyślnie wszystkich skryptów. Niektóre są potrzebne do prawidłowego działania strony, analityki, zgód lub formularzy. Po każdej większej zmianie wydajnościowej sprawdzam więc nie tylko PageSpeed, ale również działanie witryny.
Hosting ma znaczenie dla szybkości WordPressa
Optymalizacja frontendu ma swoje granice. Jeżeli serwer jest przeciążony albo WordPress potrzebuje bardzo dużo czasu na wygenerowanie dokumentu, użytkownik nadal będzie czekał.
Przy problemach wydajnościowych sprawdzam więc również środowisko serwerowe, wersję PHP, cache po stronie serwera, bazę danych oraz zachowanie witryny pod obciążeniem.
Jest to szczególnie istotne przy WooCommerce, rozbudowanych serwisach i stronach wykonujących wiele dynamicznych operacji.
WooCommerce wymaga trochę innego podejścia
Sklep internetowy jest zwykle bardziej wymagający od prostej strony usługowej. Koszyk, konto klienta, filtrowanie, wyszukiwarka, warianty produktów i proces zamówienia wprowadzają elementy dynamiczne, których nie można traktować dokładnie tak samo jak statycznego artykułu.
Dlatego przy WooCommerce nie włączam agresywnego cache dla wszystkiego bez sprawdzenia wyjątków. Szczególnie uważam na:
- koszyk,
- checkout,
- konto użytkownika,
- dynamiczne fragmenty koszyka,
- filtry produktów,
- personalizowane treści.
Szybki sklep, w którym przestaje działać koszyk, nie jest dobrze zoptymalizowanym sklepem.
Mobile jest dla mnie szczególnie ważny
Strona może działać bardzo szybko na mocnym komputerze i światłowodzie, a znacznie gorzej na telefonie z wolniejszym połączeniem i słabszym procesorem.
Dlatego podczas optymalizacji zawsze analizuję wersję mobilną. To właśnie tam ciężki JavaScript, duże obrazy i rozbudowane elementy interfejsu często stają się najbardziej widoczne.
Czy Core Web Vitals wpływają na SEO?
Core Web Vitals są częścią szerszych sygnałów związanych z doświadczeniem użytkownika, ale nie traktuję ich jak magicznego czynnika, po którego poprawieniu strona automatycznie wskoczy na pierwsze miejsce.
Nadal ogromne znaczenie mają między innymi trafność treści, jej jakość, intencja wyszukiwania, struktura witryny, linkowanie i wiele innych elementów.
Szybkość warto poprawiać przede wszystkim dlatego, że użytkownik powinien dostać sprawną i wygodną stronę. Jeżeli jednocześnie poprawiam jej techniczną jakość z punktu widzenia Google, tym lepiej.
Najczęstsze błędy przy optymalizacji Core Web Vitals
- instalowanie kilku wtyczek cache jednocześnie,
- patrzenie wyłącznie na wynik 0–100 w PageSpeed,
- lazy loading najważniejszego obrazu LCP,
- agresywne opóźnianie JavaScriptu bez testowania funkcji strony,
- ignorowanie wersji mobilnej,
- optymalizacja grafik bez sprawdzenia ich rzeczywistych wymiarów,
- pozostawianie nieużywanych skryptów i wtyczek,
- ignorowanie hostingu i czasu odpowiedzi serwera,
- brak ponownych testów po aktualizacji WordPressa lub wtyczek.
Jak optymalizuję WordPressa krok po kroku?
W praktyce mój proces wygląda mniej więcej tak:
- Sprawdzam dane Core Web Vitals i PageSpeed Insights.
- Analizuję stronę osobno na mobile i desktopie.
- Identyfikuję element LCP oraz przyczyny problemów z INP i CLS.
- Sprawdzam czas odpowiedzi serwera.
- Analizuję obrazy, fonty, CSS i JavaScript.
- Weryfikuję motyw, builder oraz wtyczki WordPressa.
- Sprawdzam cache i konfigurację serwera.
- Usuwam lub ograniczam niepotrzebne zasoby.
- Wprowadzam zmiany etapami.
- Po każdej większej zmianie testuję zarówno szybkość, jak i działanie strony.
Najpierw diagnoza, później optymalizacja. Jeśli PageSpeed pokazuje słaby LCP, chcę wiedzieć, jaki element go powoduje. Jeśli problemem jest INP, szukam obciążenia JavaScriptu. Jeśli mam wysoki CLS, sprawdzam, co przesuwa układ. Dzięki temu nie próbuję naprawiać wszystkiego jedną wtyczką.
Czy warto walczyć o 100/100 w PageSpeed?
Nie traktuję wyniku 100/100 jako głównego celu. Oczywiście wysoki wynik jest przyjemny i może wskazywać, że wiele elementów działa dobrze, ale sam w sobie nie gwarantuje świetnego doświadczenia użytkownika ani wysokich pozycji.
Wolę doprowadzić stronę do stanu, w którym szybko się otwiera, sprawnie reaguje, nie przesuwa elementów, dobrze działa na urządzeniach mobilnych i nie traci ważnych funkcji.
To jest dla mnie realna optymalizacja WordPressa, a nie wyłącznie optymalizacja wyniku w narzędziu.
FAQ – Core Web Vitals i WordPress
Jakie są najważniejsze Core Web Vitals?
Główne wskaźniki Core Web Vitals to LCP, INP oraz CLS. LCP dotyczy szybkości wyświetlenia największego elementu treści, INP responsywności strony podczas interakcji, a CLS stabilności wizualnej układu.
Jaki wynik LCP jest dobry?
Za dobry wynik LCP uznaje się wartość nieprzekraczającą 2,5 sekundy. Przy ocenie Core Web Vitals znaczenie mają dane rzeczywistych użytkowników i 75. percentyl wizyt.
Jak poprawić Core Web Vitals na WordPressie?
Najpierw warto ustalić, który wskaźnik powoduje problem. W zależności od diagnozy optymalizacja może obejmować obrazy, JavaScript, CSS, fonty, cache, wtyczki, motyw, page builder oraz konfigurację hostingu.
Czy wtyczka cache wystarczy do przyspieszenia WordPressa?
Nie zawsze. Cache może znacznie pomóc, ale nie rozwiąże automatycznie problemów takich jak ciężkie obrazy, nadmiar JavaScriptu, zewnętrzne skrypty, nieoptymalny layout czy wolne zapytania wykonywane przez WordPressa.
Czy trzeba mieć 100 punktów w PageSpeed Insights?
Nie. Wynik punktowy Lighthouse jest pomocnym wskaźnikiem diagnostycznym, ale nie powinien być jedynym celem optymalizacji. Ważniejsze jest rzeczywiste doświadczenie użytkownika, poprawne Core Web Vitals oraz stabilne działanie strony.
Czy Elementor spowalnia WordPressa?
Elementor może zwiększać ilość kodu i zasobów potrzebnych do wyświetlenia strony, ale samo korzystanie z niego nie oznacza automatycznie słabej wydajności. Duże znaczenie ma sposób zbudowania strony, liczba widgetów, dodatków, animacji, skryptów oraz ogólna konfiguracja WordPressa.
WordPress jest wolny i nie wiesz, od czego zacząć?
Mogę przeanalizować stronę pod kątem technicznego SEO, wydajności i problemów wpływających na użytkowników. Zamiast instalować kolejną wtyczkę „do przyspieszania”, najpierw warto sprawdzić, co faktycznie jest wąskim gardłem.
Sprawdź audyt SEO
