Dlaczego Core Web Vitals i wydajność WordPressa są dziś kluczowe
Core Web Vitals po ludzku: LCP, CLS, INP
Core Web Vitals to trzy wskaźniki, które mówią, czy strona „czuje się” szybka i stabilna dla użytkownika. Nie są to abstrakcyjne techniczne parametry – każdy z nich odpowiada za realne odczucie wygody korzystania ze strony.
LCP (Largest Contentful Paint) mierzy, jak szybko ładuje się największy, główny element widoczny w oknie przeglądarki – zwykle jest to duży obraz, slider, sekcja hero lub duży nagłówek. Słaby LCP oznacza, że użytkownik długo czeka na „konkretną” treść, choć może już widzieć pasek ładowania czy szkielet strony.
CLS (Cumulative Layout Shift) mówi, jak bardzo „skacze” układ strony podczas ładowania. To te irytujące sytuacje, gdy chcesz kliknąć przycisk, a tu nagle wczytuje się reklama albo obraz, wszystko się przesuwa i klikasz coś innego. W WordPressie winne są często źle wstawione obrazki, dynamiczne bannery, zewnętrzne widgety i fonty.
INP (Interaction to Next Paint) zastąpił FID. Mierzy, jak szybko strona reaguje na akcje użytkownika – kliknięcia, wprowadzanie tekstu, gesty. W praktyce: czy po kliknięciu przycisku „Dodaj do koszyka” strona natychmiast reaguje, czy przez sekundę „myśli”. Na INP mocno wpływają ciężkie skrypty JS, page buildery i złożone wtyczki WooCommerce, analityka ładowana synchronicznie, rozbudowane menu i pop‑upy.
Wolny WordPress a SEO, konwersje i doświadczenie użytkownika
Wydajność strony opartej na WordPressie nie jest tylko „technikalią”. Bezpośrednio przekłada się na:
- pozycje w Google – Core Web Vitals to element sygnału Page Experience; słabe wyniki mogą obniżać widoczność, zwłaszcza w konkurencyjnych branżach, gdzie wiele stron ma podobną jakość treści i linków,
- konwersje – im dłużej ładuje się strona, tym więcej użytkowników rezygnuje przed zakupem czy wysłaniem formularza; szczególnie boleśnie widać to na mobile,
- współczynnik odrzuceń – użytkownicy przyzwyczajeni do natychmiastowych reakcji aplikacji mobilnych nie czekają 5–8 sekund, aż WordPress „się namyśli”.
Przy słabej wydajności WordPressa dzieją się trzy rzeczy naraz: rosną koszty (więcej ruchu płatnego, żeby osiągnąć ten sam efekt), spadają przychody (mniej konwersji z ruchu organicznego i płatnego), a użytkownicy budują skojarzenie „ta marka = męcząca, wolna strona”.
Elastyczność WordPressa kontra „spuchnięte” strony
WordPress daje mnóstwo swobody: motywy, buildery, setki tysięcy wtyczek. Ta elastyczność ma jednak skutki uboczne. Najczęstszy scenariusz:
- instalacja ciężkiego motywu „all in one”,
- dodanie page buildera (Elementor, WPBakery, Divi, inny),
- do tego kilka pakietów dodatków (addonsów) do buildera,
- kilkanaście wtyczek „od wszystkiego”: popupy, social media, formularze, galerie,
- hosting z dolnej półki, bez sensownego cache i szybkiego dysku.
Efekt: każdy element frontendu korzysta z własnych CSS i JS. Strona ładuje dziesiątki plików, często z duplikującą się funkcjonalnością (np. trzy różne biblioteki sliderów). Do tego dochodzą źle skompresowane obrazy, webfonty z kilkunastoma wariantami grubości, brak cache – i wyniki Core Web Vitals lecą w dół.
Praktyczny przykład: sklep WooCommerce przed i po optymalizacji
Typowy przypadek z praktyki: niewielki sklep WooCommerce na WordPressie, postawiony na motywie premium z wbudowanym builderem. Strona główna ma spory slider, kilka sekcji „bestsellery”, blog poniżej. Właściciel narzeka, że reklamy Google Ads słabo działają, a wyniki w Search Console pokazują „Słabe URL-e z powodu CWV”.
Po testach PageSpeed Insights i WebPageTest wychodzą problemy: LCP powyżej 4 s na mobile, wysoki CLS przez doskakujące banery i obrazki bez wymiarów, INP słaby, bo skrypty JS z buildera i kilku wtyczek do popupów blokują interakcje. Dodatkowo TTFB jest bardzo wysoki – hosting ledwo zipie.
Po przenosinach na lepszy serwer, włączeniu sensownej wtyczki cache, kompresji obrazów, odchudzeniu buildera (wyłączenie zbędnych widgetów) i wyrzuceniu dwóch ciężkich wtyczek popupów (zastąpionych lżejszym rozwiązaniem) LCP spada poniżej 2,5 s, CLS wraca do zielonej strefy, a INP poprawia się dzięki opóźnieniu ładowania części skryptów. Z tego samego ruchu sklep generuje znacznie więcej transakcji.
Co sprawdzić na start: szybki test PageSpeed i WebPageTest
Krok 1: uruchom PageSpeed Insights, wpisz adres strony głównej i jednego ważnego podstrony (np. produkt lub oferta). Zwróć uwagę na:
- kolor wskaźników LCP, CLS, INP dla mobile i desktopu,
- czas TTFB / „czas do pierwszego bajtu” (sekcja „Diagnostyka”),
- wielkość transferu (obrazki, JS, CSS),
- sekcje „Zwiększ wydajność obrazu”, „Usuń nieużywany kod JavaScript/CSS”.
Krok 2: uruchom WebPageTest (lub GTmetrix) z lokalizacją zbliżoną do twoich użytkowników, wybierz przeglądarkę mobilną i przetestuj stronę co najmniej 3 razy. Patrz przede wszystkim na:
- TTFB – jeśli jest wysoki, to często wąskie gardło serwera,
- „Fully Loaded Time” oraz „Largest Contentful Paint”,
- liczbę zapytań (requests) i ogólny rozmiar strony (Total size).
Co sprawdzić: zanotuj (lub zrób zrzuty ekranu) wartości LCP, CLS, INP, TTFB oraz całkowity rozmiar strony – będą referencją po optymalizacji.
Jak prawidłowo diagnozować problemy wydajności w WordPressie
Krok 1: Testy zewnętrzne – PageSpeed, Lighthouse, GTmetrix, WebPageTest
Pierwsza diagnoza to zawsze spojrzenie z zewnątrz. Najszybciej da się wyłapać, czy problem dotyczy frontendu (duże pliki, obrazy, CSS, JS), czy backendu (wydłużony czas generowania strony przez PHP i bazę danych).
Skuteczny schemat:
- PageSpeed Insights – podstawowy test CWV, metryki polowe (jeśli strona ma ruch), rekomendacje optymalizacyjne.
- Lighthouse w Chrome – szczegółowy audyt wydajności (CTRL+SHIFT+I → zakładka Lighthouse → Generate report).
- GTmetrix – dobra wizualizacja „Waterfall” i czasów poszczególnych zasobów.
- WebPageTest – zaawansowane podejście do TTFB, powtarzane testy, filmik ładowania strony.
Na co patrzeć krok po kroku:
- czy LCP jest powyżej 2,5 s (zielona strefa), 4 s (pomarańczowa), czy jeszcze gorzej,
- czy CLS przekracza 0,1 (wysokie przeskoki układu),
- czy INP jest wyraźnie powyżej 200–300 ms (strona reaguje ospale),
- czy TTFB przekracza 600–800 ms – jeśli tak, często problem leży w hostingu/serwerze lub ciężkim PHP,
- ile jest zapytań (requests) i ilu z nich można uniknąć (niepotrzebne zewnętrzne skrypty, fonty, wtyczki).
Krok 2: Chrome DevTools – Performance i Network
Drugi krok to narzędzia wbudowane w przeglądarkę. Chrome DevTools pozwala podejrzeć, co realnie dzieje się pod