Monitoring Core Web Vitals w opiece miesięcznej: jak pilnować szybkości strony cały rok

Core Web Vitals to temat, który wraca do mnie przy każdej rozmowie z nowym klientem. Ktoś kilka miesięcy temu optymalizował stronę, ma zielone paski w PageSpeed - i zakłada, że sprawa jest załatwiona. A potem wchodzi wtyczka do cache w nowej wersji, klient wgrywa galerię zdjęć bez kompresji i po miesiącu LCP skacze z 1,8 sekundy do 3,4 sekundy. Nikt tego nie zauważył, bo nikt nie patrzył.

Prowadzę opiekę techniczną WordPress dla kilkudziesięciu stron i sklepów, głównie w Polsce i Niemczech. Z doświadczenia wiem, że wyniki CWV są dynamiczne - zmieniają się po każdej aktualizacji, po każdym nowym komponencie na stronie, czasem nawet po zmianie dostawcy hostingu. Dlatego monitoring Core Web Vitals musi być procesem, nie jednorazowym projektem.

Trzy metryki, które liczy Google w 2026 roku

Od marca 2024 zestaw Core Web Vitals składa się z trzech metryk:

• LCP (Largest Contentful Paint) - czas do wyświetlenia największego elementu na ekranie. Próg "good": poniżej 2,5 sekundy.
• INP (Interaction to Next Paint) - responsywność każdej interakcji: kliknięcia, tapnięcia, wpisywania. Próg "good": poniżej 200 milisekund.
• CLS (Cumulative Layout Shift) - stabilność layoutu podczas ładowania. Próg "good": poniżej 0,1.

INP zastąpiło FID i to zmiana, która wielu właścicieli WordPressa zaskoczyła. FID mierzył tylko pierwszą interakcję, INP mierzy każdą. Ciężki skrypt czatu załadowany asynchronicznie po 3 sekundach nie psuł FID, ale INP już tak - i to wyraźnie.

W 2026 roku sytuacja jest wyraźna: według danych z Chrome UX Report tylko 47% stron spełnia progi "good" dla wszystkich trzech metryk jednocześnie. INP jest najczęściej niezdaną metryką - 43% stron nadal nie przechodzi progu 200ms. Po aktualizacji algorytmu Google z marca 2026 wydajność strony ma większy wpływ na ranking niż rok temu.

Dlaczego wyniki się zmieniają bez Twojej wiedzy

Zajmując się opieką techniczną WordPress regularnie widzę ten sam schemat. Optymalizacja na wdrożeniu daje dobre wyniki - ale nic na stronie nie stoi w miejscu. Oto co najczęściej psuje wyniki CWV po wdrożeniu:

Aktualizacje wtyczek. Popularne wtyczki do formularzy, SEO czy e-commerce potrafią w nowej wersji dołożyć dodatkowe żądania JS lub CSS. Wystarczy jedna aktualizacja Elementora czy WooCommerce, żeby LCP podskoczyło o 0,5 sekundy.

Treści od klienta. Klient wgrywa do biblioteki mediów zdjęcia prosto z telefonu - 4MB na zdjęcie, bez kompresji. Albo osadza film z YouTube w sekcji hero. CLS rośnie, LCP rośnie, a klient jest przekonany, że "nic nie zmieniał".

Nowe elementy na stronie. Baner reklamowy, widget z mediami społecznościowymi, nowy popup z zapisem do newslettera - każdy z nich może wpłynąć na INP lub CLS.

Zmiany po stronie zewnętrznych serwisów. Skrypt Google Tag Managera z nowym tagiem analitycznym dodanym przez agencję marketingową klienta. Nowy pixel Facebooka. Te zmiany dzieją się poza Twoją kontrolą jako webdevelopera.

Darmowy fundament: Google Search Console i PageSpeed Insights

Dla większości stron WordPress darmowe narzędzia Google w zupełności wystarczą jako podstawa monitoringu. Ważne, żeby rozumieć różnicę między nimi.

Google Search Console - raport "Core Web Vitals" w sekcji "Jakość" pokazuje URL-e pogrupowane według statusu: Good, Needs Improvement, Poor. Dane pochodzą z Chrome UX Report (CrUX), czyli z prawdziwych wizyt użytkowników korzystających z Chrome w ciągu ostatnich 28 dni. To jest ta sama perspektywa, z której ocenia Cię Google w rankingu. Minus: potrzebujesz odpowiedniej liczby wizyt na URL, żeby dane były widoczne - nowe strony lub te z małym ruchem mogą nie mieć danych CrUX.

PageSpeed Insights - testuje pojedynczy URL i łączy dwa widoki: dane laboratoryjne (Lighthouse, symulowane mobilne połączenie 4G) oraz dane terenowe (CrUX dla tego URL lub całej domeny). Lab data jest przydatna do diagnozy konkretnych problemów - Lighthouse wskazuje elementy spowalniające LCP, skrypty blokujące rendering, elementy powodujące CLS. Ważne: wyniki laboratoryjne nie są tym, co Google bierze do rankingu - to dane terenowe mają znaczenie.

Obydwa narzędzia razem dają kompletny obraz. Search Console powie Ci "które strony mają problem", PageSpeed Insights powie Ci "co konkretnie jest przyczyną".

Narzędzia płatne: kiedy warto dołożyć budżet

Dla stron z dużym ruchem i sklepów internetowych warto rozważyć dedykowane narzędzia do monitoringu wydajności. Różnica w stosunku do darmowych narzędzi Google to przede wszystkim: automatyczne alerty przy regresji, historia wyników z możliwością porównania przed/po oraz testy syntetyczne uruchamiane co godzinę lub co dzień.

DebugBear (od ok. 200 PLN/miesiąc w przeliczeniu) to narzędzie, z którego korzystam dla kilku klientów z aktywnymi kampaniami reklamowymi - tam regresja wydajności bezpośrednio przekłada się na wyższy koszt pozyskania klienta. Automatyczny alert pozwala zareagować w ciągu godzin, nie tygodni.

Dla małej strony firmowej czy bloga darmowe narzędzia Google przy regularnym przeglądzie raz w miesiącu są w zupełności wystarczające.

Jak wygląda monitoring CWV w mojej opiece miesięcznej

W ramach opieki technicznej WordPress mam wypracowany schemat pracy z Core Web Vitals, który stosuję dla każdego klienta.

Na początku każdego miesiąca przeglądam raport CWV w Search Console dla każdej strony. Skupiam się na URL-ach zdegradowanych w stosunku do poprzedniego miesiąca. Jeśli liczba URL-ów w statusie "Poor" wzrosła, to jest sygnał alarmowy do dalszej diagnozy.

Następnie dla każdego problematycznego URL uruchamiam PageSpeed Insights na mobile - bo Google ocenia strony głównie w wersji mobilnej (mobile-first indexing). Sprawdzam, która metryka jest problemem: LCP powyżej 2,5s, INP powyżej 200ms czy CLS powyżej 0,1. Każda z nich ma inne przyczyny i inne rozwiązania.

Diagnoza i naprawa to osobny etap. Najczęstsze problemy, z którymi się mierzę:

LCP: niezoptymalizowane obrazy (brak loading="lazy" na pierwszym ekranie jest błędem - tam trzeba fetchpriority="high"), brak preloadu dla czcionek, wolno ładujące się skrypty blokujące rendering.

INP: ciężkie biblioteki JavaScript ładowane synchronicznie (np. pełna biblioteka jQuery UI tylko dla jednego slidera), skrypty stron trzecich wywołujące długie zadania w wątku głównym.

CLS: brak zdefiniowanych wymiarów dla obrazów, reklamy bez zarezerwowanej przestrzeni, czcionki webowe powodujące FOUT (Flash of Unstyled Text) bez font-display: swap.

Po naprawie zapisuję datę zmiany i czekam na aktualizację danych CrUX (zazwyczaj 28 dni). To ważne, żeby nie oceniać efektu zbyt wcześnie - dane polowe potrzebują czasu.

Co zrobić gdy wyniki się pogorszyły

Przede wszystkim: nie panikować i nie wdrażać losowych "optymalizacji" bez diagnozy. Widziałem strony, które po "przyspieszeniu" przez losową wtyczkę cache były wolniejsze niż przed.

Krok pierwszy: sprawdź co się zmieniło na stronie w ciągu ostatnich 4 tygodni. Aktualizacje wtyczek w dashboardzie WordPress (historia w logu aktywności jeśli masz WP Activity Log), nowe treści, zmiany w GTM. Często przyczyna jest oczywista.

Krok drugi: uruchom Lighthouse w Chrome DevTools w trybie incognito, żeby wykluczyć rozszerzenia przeglądarki. Raport wskaże konkretne elementy - "Largest Contentful Paint element", "Long Tasks", elementy powodujące CLS.

Krok trzeci: napraw jeden problem naraz i przetestuj. Jeśli naprawisz pięć rzeczy jednocześnie, nie wiesz co pomogło i nie powtórzysz sukcesu na kolejnej stronie.

Jeśli Twoja strona jest sklepem WooCommerce, przeczytaj też mój artykuł o cotygodniowym przeglądzie Google Search Console - wiele sygnałów wydajnościowych jest widocznych właśnie tam, zanim pojawi się problem z rankingiem.

Kilka słów o infrastrukturze - bo hosting ma znaczenie

W pracy z polskimi klientami zauważam, że Core Web Vitals to często diagnoza problemu infrastrukturalnego, nie tylko kwestia optymalizacji kodu. Hosting oparty na LiteSpeed Enterprise z LiteSpeed Cache for WordPress to fundament, na którym wszystkie inne optymalizacje mają sens. Na wolnym serwerze współdzielonym z dużym TTFB (Time to First Byte powyżej 600ms) żadna wtyczka cache nie pomoże osiągnąć LCP poniżej 2,5 sekundy.

Kilka projektów przeprowadziłem przez migrację z najtańszego hostingu na serwer LiteSpeed (LH.pl, home.pl, Seohost) i poprawa LCP o 1-2 sekundy pojawiała się praktycznie natychmiast - bez innych zmian. To warto mieć z tyłu głowy przy diagnozie.

CWV a inne aspekty opieki - jak to łączyć

Monitoring Core Web Vitals nie działa w oderwaniu od reszty opieki technicznej. Z mojego doświadczenia wynika, że najlepsze efekty daje podejście, w którym wydajność jest jednym z elementów regularnego przeglądu, a nie osobnym projektem.

W praktyce wygląda to tak: aktualizacja wtyczek (robiona w testowym środowisku, potem na produkcji) idzie w parze z kontrolnym testem PageSpeed Insights. Optymalizacja zdjęć wgranych przez klienta to element comiesięcznego przeglądu treści. Sprawdzenie nowych skryptów dodanych przez agencję marketingową to element audytu bezpieczeństwa i wydajności jednocześnie.

W artykule o tym co obejmuje abonament opieki WordPress pisałem szerzej o tym jak planować taki zakres pracy. Jeśli zastanawiasz się nad taką formą współpracy, zajrzyj też na stronę opieki technicznej WordPress - tam opisuję jak to wygląda konkretnie u mnie.

Natomiast jeśli chcesz wiedzieć jak diagnozować problemy z widocznością w Google, sprawdź wpis o cotygodniowym przeglądzie Google Search Console - to naturalne uzupełnienie tematu CWV.

Najczęstsze pytania

Jak często powinienem sprawdzać Core Web Vitals swojej strony?

Minimum raz w miesiącu w Google Search Console, gdzie widzisz dane z realnych użytkowników (CrUX). Dodatkowo uruchamiaj PageSpeed Insights po każdej większej zmianie - nowej wtyczce, zmianie szablonu, dodaniu nowych grafik czy widżetów. Zmiany layoutu potrafią dramatycznie pogorszyć CLS w ciągu jednego dnia.

Czym różni się wynik w PageSpeed Insights od raportu w Search Console?

PageSpeed Insights testuje pojedynczy URL w warunkach laboratoryjnych (symulowane połączenie mobilne) i pokazuje dane z ostatnich 28 dni z Chrome UX Report. Search Console grupuje URL-e i pokazuje dane z prawdziwych wizyt Twoich użytkowników. Obie perspektywy są potrzebne - lab data pomaga diagnozować problemy, field data pokazuje co widzi Google.

INP zastąpiło FID - co to oznacza praktycznie dla WordPressa?

INP (Interaction to Next Paint) mierzy responsywność każdej interakcji na stronie, nie tylko pierwszej jak FID. Dla WordPressa oznacza to, że ciężkie skrypty ładowane po załadowaniu strony - np. chatboty, skrypty śledzące, rozbudowane filtry produktów w WooCommerce - mogą teraz powodować słabe wyniki INP nawet jeśli strona ładuje się szybko. W marcu 2024 Google oficjalnie przeszło na INP.

Czy Core Web Vitals naprawdę wpływają na pozycje w Google?

Tak, choć nie są jedynym czynnikiem. Po aktualizacji algorytmu z marca 2026 Google wzmocnił wagę wydajności w rankingu. Bardziej bezpośredni wpływ widzę jednak na konwersje - klienci z moich projektów e-commerce notują wyższy współczynnik odrzuceń na wolno ładujących się stronach, szczególnie na mobile. Strona z LCP powyżej 4 sekund traci realnych klientów, nie tylko punkty w rankingu.

Jakie narzędzie do monitoringu CWV polecasz małym firmom?

Na start w zupełności wystarczy Google Search Console (darmowe) plus regularne testy w PageSpeed Insights. Dla sklepów WooCommerce z kilkuset zamówieniami miesięcznie warto rozważyć DebugBear (od ok. 200 PLN/miesiąc) - automatyczne alerty przy regresji są warte tej ceny, bo wyłapują problem zanim zaczniecie tracić sprzedaż.

Co robisz w ramach opieki miesięcznej jeśli chodzi o CWV?

Raz w miesiącu przeglądam raport Core Web Vitals w Search Console każdego klienta. Jeśli pojawią się URL-e w statusie 'Needs Improvement' lub 'Poor', wchodzę w PageSpeed Insights i diagnozuję przyczynę. Najczęstsze winowajce to niezoptymalizowane obrazy wgrane przez klienta, nowa wtyczka z ciężkim skryptem albo zmiana layoutu powodująca CLS. Naprawiam problem i weryfikuję po kolejnych 28 dniach.