Core Web Vitals – co to jest i jak poprawić LCP, INP i CLS?

Core Web Vitals to trzy wskaźniki Google, które mierzą doświadczenie prawdziwych użytkowników strony: szybkość ładowania głównej treści (LCP), responsywność na kliknięcia (INP) i stabilność układu (CLS). Strona przechodzi ocenę, gdy 75% odsłon ma LCP ≤ 2,5 s, INP ≤ 200 ms i CLS ≤ 0,1 – osobno na komórkach i na komputerach. Google potwierdza, że systemy rankingowe biorą te wskaźniki pod uwagę, ale trafność treści jest ważniejsza niż dobre wyniki CWV.

Czym są Podstawowe Wskaźniki Internetowe (Core Web Vitals)?

Podstawowe Wskaźniki Internetowe, znane jako Core Web Vitals (w skrócie CWV), to zbiór metryk opracowanych przez Google. Ich celem jest pomiar rzeczywistego doświadczenia użytkownika na stronie. Metryki te koncentrują się na trzech aspektach jakości witryny: szybkości ładowania, responsywności na interakcje i stabilności wizualnej. Dają właścicielom stron i deweloperom konkretne liczby, na podstawie których można poprawiać komfort korzystania z witryny.

Wskaźniki CWV są częścią szerszego zestawu aspektów, które Google określa jako „page experience” (doświadczenie strony). Nie istnieje jeden sygnał „page experience” – Google pisze, że jego główne systemy rankingowe biorą pod uwagę różne sygnały powiązane z ogólnym doświadczeniem strony, a Core Web Vitals są jednym z nich. Dla użytkowników dobre wyniki oznaczają szybsze i bardziej przewidywalne przeglądanie: nikt nie lubi czekać na wolno ładującą się stronę ani trafiać w zły przycisk, bo element nagle przesunął się w dół.

Z perspektywy właściciela strony optymalizacja CWV to nie tylko kwestia techniczna. Szybsza i stabilniejsza strona to mniej porzuconych wizyt i mniej barier na drodze do konwersji – niezależnie od tego, czy celem jest zakup, zapis na newsletter, czy wysłanie formularza kontaktowego.

Geneza i znaczenie Core Web Vitals – dlaczego Google je wprowadziło?

Zespół Chrome przedstawił Core Web Vitals na początku maja 2020 roku, a 28 maja 2020 roku Google Search zapowiedziało, że staną się one częścią sygnałów page experience w rankingu. Aktualizacja znana jako „page experience update” była wdrażana stopniowo od 15 czerwca do końca sierpnia 2021 roku – najpierw dla wyników mobilnych. Wersja dla wyników na komputerach była wdrażana od 22 lutego do końca marca 2022 roku.

Najważniejszą zmianą w składzie Core Web Vitals było zastąpienie metryki First Input Delay (FID) przez Interaction to Next Paint (INP) – 12 marca 2024 roku. FID mierzył tylko opóźnienie pierwszej interakcji, a INP ocenia responsywność przez całą wizytę. To pokazuje, że Core Web Vitals nie są zamkniętym zbiorem reguł: Google ma ustalony cykl życia metryk (eksperymentalna → oczekująca → stabilna), a zmiany w zestawie stabilnych wskaźników zapowiada z wyprzedzeniem. Optymalizacja doświadczenia użytkownika jest więc procesem ciągłym, a nie jednorazowym zadaniem.

Głównym powodem wprowadzenia Core Web Vitals było dążenie Google do poprawy ogólnej jakości stron w internecie. Użytkownicy wyraźnie preferują strony, które ładują się szybko, są stabilne wizualnie i od razu reagują na kliknięcia – a CWV pozwalają te trzy cechy zmierzyć liczbowo.

Słabe doświadczenie użytkownika ma też konsekwencje biznesowe. Według danych Google (Think with Google, badanie stron mobilnych) prawdopodobieństwo opuszczenia strony rośnie o 32%, gdy czas ładowania wydłuża się z 1 do 3 sekund. Strony, które ładują się szybko i są stabilne, rzadziej frustrują użytkowników i częściej prowadzą ich dalej – do kolejnych podstron, oferty i formularza.

Czy Core Web Vitals to czynnik rankingowy?

Tak, ale z ważnym zastrzeżeniem. Google w dokumentacji Search Central pisze wprost, że Core Web Vitals są używane przez jego systemy rankingowe, i zaleca osiąganie dobrych wyników. Jednocześnie podkreśla, że wyszukiwarka zawsze stara się pokazać najtrafniejszą treść, nawet jeśli doświadczenie strony jest słabe. Doświadczenie strony może mieć znaczenie przede wszystkim wtedy, gdy wiele stron oferuje podobnie pomocną treść.

W praktyce oznacza to, że poprawa CWV nie wyciągnie słabej treści na pierwsze miejsce, ale jest jednym z elementów, które mogą przesądzić o kolejności przy podobnej jakości wyników. Dużo pewniejsze są korzyści po stronie użytkowników: krótsze ładowanie i stabilny układ zmniejszają liczbę porzuconych wizyt niezależnie od pozycji w Google.

Główne składowe Core Web Vitals (CWV) i ich znaczenie

Podstawowe Wskaźniki Internetowe składają się z trzech metryk, które mierzą różne, uzupełniające się aspekty doświadczenia użytkownika. Wszystkie trzy oceniane są na 75. percentylu odsłon, osobno dla urządzeń mobilnych i komputerów. Strona (lub grupa adresów URL) przechodzi ocenę dopiero wtedy, gdy wszystkie trzy wskaźniki są w zakresie „Dobre”.

Wskaźnik	Co mierzy	Dobre	Wymaga poprawy	Słabe
LCP	Ładowanie głównej treści	≤ 2,5 s	> 2,5 s i ≤ 4 s	> 4 s
INP	Responsywność na interakcje	≤ 200 ms	> 200 ms i ≤ 500 ms	> 500 ms
CLS	Stabilność wizualna	≤ 0,1	> 0,1 i ≤ 0,25	> 0,25

Largest Contentful Paint (LCP) – szybkość ładowania największego elementu treści

Largest Contentful Paint (LCP) to metryka mierząca czas od rozpoczęcia ładowania strony do wyrenderowania największego elementu treści w widocznym obszarze (viewport). Największym elementem może być obraz, blok tekstu, plakat wideo lub obraz tła. LCP w przybliżeniu określa moment, w którym użytkownik widzi, że główna treść strony się załadowała – czyli jego pierwsze wrażenie.

Google ustaliło następujące progi dla oceny wyników LCP:

Ocena LCP	Czas (w sekundach)
Dobre	≤ 2,5
Wymaga poprawy	> 2,5 i ≤ 4
Słabe	> 4

Ważna uwaga: Google zaleca, aby 75. percentyl odsłon strony – liczony osobno dla urządzeń mobilnych i komputerów – mieścił się w progu „Dobre”. Oznacza to, że co najmniej trzy na cztery wizyty powinny mieć szybkie ładowanie głównej treści.

Wartość LCP można rozbić na cztery części składowe (web.dev podaje też orientacyjny udział każdej z nich w dobrze zoptymalizowanej stronie):

• Czas do pierwszego bajtu (Time to First Byte – TTFB): czas od rozpoczęcia ładowania strony do otrzymania pierwszego bajtu odpowiedzi HTML (ok. 40% LCP). Długi TTFB to najczęściej wolny hosting, brak cache stron lub ciężkie zapytania do bazy danych. Szczegółowo opisałem to w artykule o poprawie TTFB.
• Opóźnienie ładowania zasobu: czas między TTFB a rozpoczęciem pobierania zasobu LCP (cel: poniżej 10%).
• Czas ładowania zasobu LCP: czas potrzebny na pobranie samego elementu LCP, np. obrazu (ok. 40%).
• Opóźnienie renderowania: czas między pobraniem zasobu LCP a jego wyrenderowaniem (cel: poniżej 10%). Powodują je zwykle zasoby blokujące renderowanie, np. duże pliki CSS lub synchroniczny JavaScript.

Główne czynniki, które najczęściej wpływają na LCP

• Obrazy: bardzo często to właśnie obraz (zdjęcie w nagłówku, slajder) jest elementem LCP. Problemem są zbyt duże pliki, brak kompresji, obraz wczytywany z opóźnieniem przez lazy loading albo ustawiony jako tło w CSS, przez co przeglądarka odkrywa go dopiero po pobraniu arkusza stylów.
• Czas odpowiedzi serwera: wolny serwer, brak cache stron lub brak sieci CDN bezpośrednio wydłużają TTFB.
• Zasoby blokujące renderowanie: pliki CSS i JavaScript, które muszą zostać pobrane i przetworzone, zanim główna treść zostanie wyświetlona.
• Brak buforowania (caching): brak cache po stronie serwera wydłuża generowanie każdej odsłony, a brak cache przeglądarki zmusza ją do ponownego pobierania zasobów przy kolejnych wizytach.

Jak sprawdzić LCP i jak go poprawić

Dane z prawdziwych wizyt zobaczysz w raporcie Core Web Vitals w Google Search Console i w PageSpeed Insights (dane CrUX). Który element jest elementem LCP i która z czterech części trwa najdłużej, najszybciej sprawdzisz w panelu Performance w Chrome DevTools albo w sekcji diagnostyki PageSpeed Insights. Więcej o narzędziach piszę w dalszej części artykułu.

Poprawa LCP wymaga kompleksowego podejścia:

• Optymalizacja obrazu LCP: stosuj nowoczesne formaty (WebP, AVIF), kompresuj obrazy i dopasuj ich rozmiar do miejsca wyświetlania (srcset). Obraz LCP powinien być w HTML jako zwykły tag <img>, a nie tło w CSS, i mieć atrybut fetchpriority=”high”. Nigdy nie ładuj leniwie (lazy loading) obrazu LCP – lazy loading stosuj wyłącznie do obrazów poniżej pierwszego ekranu.
• WordPress: od wersji 6.3 WordPress sam dodaje fetchpriority=”high” do obrazu, który uznaje za prawdopodobny element LCP, i nie dodaje mu loading=”lazy”. Warto jednak sprawdzić, czy motyw, page builder albo wtyczka do lazy loadingu nie nadpisują tego zachowania – np. w slajderach w nagłówku strony.
• Poprawa czasu odpowiedzi serwera (TTFB): szybki hosting, cache stron (w WordPressie przez wtyczkę cache lub cache po stronie serwera) oraz CDN dostarczający treści z serwera bliżej użytkownika.
• Ograniczenie zasobów blokujących renderowanie: usuwaj nieużywany CSS i JavaScript, minifikuj pliki i odraczaj niekrytyczne skrypty (atrybuty async lub defer).
• Wdrożenie buforowania (caching): cache po stronie serwera skraca generowanie strony, a cache przeglądarki przyspiesza kolejne wizyty.

LCP jest wskaźnikiem „pierwszego wrażenia”. Jeśli użytkownik długo czeka na kluczową treść, rośnie ryzyko, że opuści stronę, zanim cokolwiek zobaczy. Ponieważ TTFB i czas pobierania zasobu odpowiadają zwykle za większość LCP, optymalizację warto zacząć od fundamentów – serwera, cache i obrazu w nagłówku – a dopiero potem przejść do szczegółowej optymalizacji kodu.

Interaction to Next Paint (INP) – responsywność strony na interakcje

Interaction to Next Paint (INP) to metryka mierząca ogólną responsywność strony. Obserwuje opóźnienie wszystkich kliknięć myszą, stuknięć na ekranie dotykowym i naciśnięć klawiszy przez cały czas trwania wizyty – liczy się czas od interakcji do najbliższej aktualizacji obrazu na ekranie. Przewijanie, najeżdżanie kursorem i powiększanie nie są brane pod uwagę. Wynikiem jest zwykle najwolniejsza interakcja; na stronach z dużą liczbą interakcji pomijana jest jedna najwolniejsza na każde 50, żeby pojedyncze przypadkowe „zacięcia” nie zawyżały wyniku.

INP zastąpił First Input Delay (FID) jako jeden z Core Web Vitals 12 marca 2024 roku. FID mierzył jedynie opóźnienie pierwszej interakcji – i to tylko do momentu rozpoczęcia jej obsługi. INP obejmuje całą interakcję, łącznie z czasem przetwarzania i wyświetlenia zmiany, przez całą wizytę.

Google ustaliło następujące progi dla oceny wyników INP:

Ocena INP	Czas (w milisekundach)
Dobre	≤ 200
Wymaga poprawy	> 200 i ≤ 500
Słabe	> 500

Ważna uwaga: podobnie jak w przypadku LCP, Google zaleca, aby 75. percentyl odsłon strony mieścił się w progu „Dobre”.

Każda interakcja składa się z trzech części: opóźnienia wejścia (input delay – czekanie, aż główny wątek przeglądarki będzie wolny), czasu przetwarzania (processing time – wykonanie kodu obsługi zdarzenia) i opóźnienia prezentacji (presentation delay – przeliczenie układu i wyrenderowanie zmiany). Główne czynniki wpływające na INP to:

• Długie zadania JavaScript: długo działające skrypty blokują główny wątek przeglądarki. Dopóki jest zajęty, przeglądarka nie może obsłużyć kliknięcia.
• Nadmierne obciążenie głównego wątku: główny wątek odpowiada za parsowanie HTML, wykonywanie JavaScriptu i renderowanie. W testach laboratoryjnych sygnałem tego problemu jest wysoki Total Blocking Time (TBT).
• Skrypty stron trzecich: reklamy, narzędzia analityczne, czaty, piksele reklamowe i widżety mediów społecznościowych uruchamiają własny kod, który konkuruje z Twoim o główny wątek.
• Duży rozmiar DOM (Document Object Model): im więcej elementów na stronie, tym dłużej trwa przeliczanie stylów i układu po każdej zmianie – co wydłuża opóźnienie prezentacji.
• Nieefektywna obsługa zdarzeń: zbyt złożone funkcje JavaScript uruchamiane w odpowiedzi na kliknięcie (np. przy filtrach w sklepie czy menu mobilnym) wydłużają czas przetwarzania.

Jak sprawdzić INP i jak go poprawić

INP to metryka terenowa – wymaga prawdziwej interakcji, więc nie da się jej zmierzyć w samym teście laboratoryjnym. Dane o INP z prawdziwych wizyt pokazują raport Core Web Vitals w Search Console i PageSpeed Insights (sekcja z danymi CrUX). Lighthouse w PageSpeed Insights nie mierzy INP; najbliższym laboratoryjnym odpowiednikiem jest TBT. Żeby znaleźć konkretną wolną interakcję, otwórz panel Performance w Chrome DevTools: widok metryk na żywo pokazuje INP dla Twoich kliknięć, a nagranie profilu wskazuje, który skrypt blokował główny wątek.

Poprawa INP koncentruje się na optymalizacji JavaScriptu i odciążeniu głównego wątku:

• Ograniczenie i odroczenie skryptów stron trzecich: przejrzyj, co faktycznie ładuje się na stronie. W WordPressie to często wtyczki ładujące swoje skrypty na każdej podstronie, choć potrzebne są na jednej (np. formularz kontaktowy, slajder, czat). Usuń zbędne, a niekrytyczne ładuj później.
• Redukcja opóźnienia wejścia: rozbijaj długie zadania głównego wątku na mniejsze części i oddawaj kontrolę przeglądarce (np. przez setTimeout lub scheduler.yield()), aby mogła w międzyczasie obsłużyć interakcję.
• Optymalizacja czasu przetwarzania: sprawdź w profilu wydajności, gdzie przeglądarka spędza najwięcej czasu, i uprość tę część kodu. W frameworkach takich jak React istotne jest unikanie niepotrzebnego ponownego renderowania komponentów.
• Aktualizacja interfejsu przed ciężkim przetwarzaniem: najpierw pokaż wizualną reakcję (np. wskaźnik ładowania), a ciężką pracę wykonaj po niej. Dla dużych obliczeń warto rozważyć web workery, które działają poza głównym wątkiem.
• Unikanie blokujących okien dialogowych: natywne okna alert, confirm i prompt blokują główny wątek – lepiej zastąpić je nieblokującymi elementami interfejsu.
• Redukcja opóźnienia prezentacji: ogranicz rozmiar DOM i zakres zmian w układzie po interakcji, aby przeglądarka mogła szybciej wyrenderować kolejną klatkę.

INP mierzy jakość całej wizyty, a nie tylko początkowego ładowania. Ma to szczególne znaczenie na stronach z rozbudowanymi interakcjami – konfiguratorach, kalkulatorach, filtrach produktów czy formularzach wieloetapowych. Jeśli każde kliknięcie „przycina się”, użytkownik szybko traci cierpliwość, zanim dojdzie do konwersji.

Cumulative Layout Shift (CLS) – stabilność wizualna strony

Cumulative Layout Shift (CLS) to metryka mierząca stabilność wizualną strony. Liczy nieoczekiwane przesunięcia układu przez cały czas życia strony – nie tylko podczas ładowania. Przesunięcia są grupowane w „okna sesji” (kolejne przesunięcia w odstępie poniżej 1 sekundy, maksymalnie 5 sekund na okno), a wynikiem CLS jest najwyższy wynik spośród tych okien. Przesunięcia, które nastąpiły do 500 ms po kliknięciu, stuknięciu lub naciśnięciu klawisza, są traktowane jako oczekiwane i nie są wliczane.

Google ustaliło następujące progi dla oceny wyników CLS:

Ocena CLS	Wartość
Dobre	≤ 0,1
Wymaga poprawy	> 0,1 i ≤ 0,25
Słabe	> 0,25

Ważna uwaga: podobnie jak w przypadku pozostałych metryk, Google zaleca, aby 75. percentyl odsłon strony mieścił się w progu „Dobre”.

Wynik pojedynczego przesunięcia układu to iloczyn dwóch współczynników:

• Współczynnik wpływu (Impact Fraction): jaką część widocznego obszaru (viewportu) zajmują niestabilne elementy – łącznie w poprzedniej i bieżącej klatce.
• Współczynnik odległości (Distance Fraction): największa odległość, o jaką przesunął się element, podzielona przez większy wymiar viewportu.

Główne przyczyny wysokiego CLS

• Obrazy i wideo bez zdefiniowanych wymiarów: gdy obraz lub wideo nie ma atrybutów width i height (ani zdefiniowanych proporcji w CSS), przeglądarka nie wie, ile miejsca zarezerwować. Po załadowaniu pliku treść pod nim „zjeżdża” w dół.
• Dynamicznie wstrzykiwana treść: reklamy, banery zgody na pliki cookie, paski promocyjne i inne elementy, które pojawiają się po początkowym renderowaniu i wypychają istniejącą treść.
• Czcionki internetowe (Web Fonts): gdy tekst jest najpierw wyświetlany czcionką zastępczą, a potem podmieniany na docelową o innych wymiarach (tzw. FOUT – flash of unstyled text), zmienia się wysokość i szerokość bloków tekstu, co przesuwa układ.
• Animacje CSS: animacje właściwości wpływających na układ, takich jak top, left, width, height czy margin, wymuszają ponowne przeliczanie układu i mogą generować przesunięcia.

Jak sprawdzić CLS

CLS sprawdzisz w tych samych narzędziach co LCP i INP: dane terenowe w Search Console i PageSpeed Insights, a szczegóły w panelu Performance w Chrome DevTools, który zaznacza przesunięcia układu na osi czasu i wskazuje elementy, które się przesunęły. Pamiętaj, że test laboratoryjny (Lighthouse) widzi tylko przesunięcia w czasie ładowania – przesunięcia po przewinięciu czy po dłuższym korzystaniu ze strony pokażą dopiero dane od prawdziwych użytkowników.

Jak poprawić CLS

Poprawa CLS wymaga przede wszystkim zapewnienia przewidywalności układu strony:

• Określanie wymiarów obrazów i wideo: dodawaj atrybuty width i height do tagów <img> i <video> (lub ustaw proporcje przez CSS aspect-ratio), aby przeglądarka mogła zarezerwować miejsce przed załadowaniem pliku. W WordPressie sprawdź szczególnie elementy dodawane przez motyw i wtyczki: logo, slajdery, osadzone filmy.
• Unikanie wstawiania treści powyżej istniejącej treści: poza sytuacjami, gdy jest to bezpośrednia odpowiedź na interakcję (np. rozwinięcie sekcji po kliknięciu), nie wstawiaj dynamicznie nowych elementów nad treścią, którą użytkownik już widzi. Baner cookies lepiej wyświetlać jako nakładkę (position: fixed) niż jako blok wypychający stronę w dół.
• Rezerwowanie miejsca na reklamy i osadzone treści: dla reklam, iframe’ów i innych dynamicznych elementów zarezerwuj przestrzeń z góry, np. przez min-height lub aspect-ratio.
• Optymalizacja ładowania czcionek: wstępnie ładuj krytyczne czcionki (link rel=”preload”), rozważ font-display: optional i dobieraj czcionki zastępcze o podobnych wymiarach do docelowych (np. przez size-adjust w regule @font-face), aby podmiana czcionki nie zmieniała układu.
• Użycie transformacji CSS zamiast animacji zmieniających układ: zamiast animować top czy left, używaj transform (translate, scale, rotate) – takie animacje nie przesuwają otaczającej treści i nie wpływają na CLS.

CLS jest silnie powiązany z zaufaniem do strony. Niespodziewane przesunięcia prowadzą do przypadkowych kliknięć, gubienia miejsca w tekście i poczucia braku kontroli. Strona, która „skacze”, wygląda po prostu mniej profesjonalnie – a to bezpośrednio wpływa na to, czy użytkownik zostawi na niej swoje dane.

Narzędzia do pomiaru Core Web Vitals

Skuteczna optymalizacja Core Web Vitals wymaga regularnego monitorowania. Google udostępnia bezpłatne narzędzia, które pokazują dane od rzeczywistych użytkowników (field data) lub dane z testów laboratoryjnych (lab data). Do oceny strony liczą się dane terenowe, a laboratoryjne służą do diagnozy.

Google Search Console (GSC)

Google Search Console to podstawowe narzędzie dla właścicieli stron, które pokazuje wyniki Core Web Vitals całej witryny na podstawie danych z rzeczywistych wizyt (CrUX).

• Dostęp do raportu: po zalogowaniu się do GSC i wybraniu usługi otwórz raport „Podstawowe wskaźniki internetowe” (Core Web Vitals) w menu bocznym. Raport ma osobne widoki dla urządzeń mobilnych i komputerów.
• Prezentacja danych: raport przypisuje adresom URL statusy „Dobre”, „Wymaga poprawy” i „Słabe”. Dane obejmują ostatnie 28 dni i przedstawiają 75. percentyl wyników. Status grupy wyznacza najsłabszy wskaźnik – jeśli INP jest dobry, a CLS słaby, cała grupa jest „Słaba”.
• Grupowanie URL-i: GSC grupuje adresy URL o podobnym doświadczeniu użytkownika, co ułatwia identyfikację problemów dotyczących całych szablonów stron, a nie tylko pojedynczych podstron.
• Ograniczenia: raport nie działa w czasie rzeczywistym, a witryny z małym ruchem mogą nie mieć w nim danych. Nie wskazuje też konkretnych elementów powodujących problem, lecz grupy stron i metryki, które wymagają uwagi.

Google PageSpeed Insights (PSI)

PageSpeed Insights to bezpłatne narzędzie Google do analizy pojedynczych adresów URL.

• Dane rzeczywiste i laboratoryjne: u góry raportu PSI pokazuje dane terenowe z CrUX (LCP, INP, CLS z ostatnich 28 dni) – to one odpowiadają ocenie Core Web Vitals. Poniżej znajduje się test laboratoryjny Lighthouse w symulowanym środowisku, przydatny do diagnozowania problemów. Lighthouse nie mierzy INP; zamiast niego pokazuje Total Blocking Time (TBT).
• Rekomendacje: od Lighthouse 13 (październik 2025) dawne audyty („możliwości” i „diagnostyka”) zostały zastąpione tzw. insights – tymi samymi analizami, które pokazuje panel Performance w DevTools, np. podział LCP na części, zasoby blokujące renderowanie czy rozmiar DOM.
• Wynik ogólny: PSI generuje wynik wydajności (Performance Score) w skali 0–100, który jest ważoną średnią metryk laboratoryjnych. Wynik od 90 w górę jest uznawany za dobry. To nie jest ocena Core Web Vitals – strona może mieć wynik poniżej 90 i jednocześnie przechodzić ocenę CWV w danych terenowych (i odwrotnie).
• Przełączanie między urządzeniami: wyniki są osobne dla urządzeń mobilnych i komputerów – zacznij od mobilnych, bo tam problemy są zwykle większe.

Chrome DevTools (Narzędzia Deweloperskie Chrome)

Narzędzia deweloperskie wbudowane w Chrome służą do diagnozowania CWV na Twoim komputerze – to tutaj najłatwiej znaleźć przyczynę problemu.

• Panel Performance – metryki na żywo: po otwarciu panelu od razu widać lokalne wartości LCP, CLS i INP podczas korzystania ze strony, bez nagrywania profilu. Panel może też pobrać dane terenowe z CrUX dla danego adresu i zestawić je z Twoim wynikiem lokalnym.
• Panel Performance – nagrywanie profilu: pozwala dokładnie przeanalizować aktywność głównego wątku: długie zadania JavaScript, przesunięcia układu, element LCP i jego części składowe. Jest szczególnie przydatny przy debugowaniu INP i TBT.
• Panel Lighthouse: pozwala uruchomić ten sam test laboratoryjny co w PageSpeed Insights, ale lokalnie – np. na wersji testowej strony, której nie da się sprawdzić z zewnątrz.

Rozszerzenie Web Vitals do Chrome, polecane w wielu starszych poradnikach, nie jest już rozwijane – Google zakończyło jego wsparcie w styczniu 2025 roku i przeniosło jego funkcje do panelu Performance.

Chrome User Experience Report (CrUX): CrUX Vis i CrUX API

CrUX to publiczny zbiór danych o doświadczeniach prawdziwych użytkowników Chrome – z niego korzystają Search Console i PageSpeed Insights.

• CrUX Vis: bezpłatne narzędzie do przeglądania historycznych danych CrUX dla domeny lub pojedynczego adresu URL. Dane aktualizowane są co tydzień. Zastąpiło dawny CrUX Dashboard w Looker Studio, którego konektor został wyłączony po listopadzie 2025 roku.
• Trend historyczny: pozwala śledzić zmiany wyników w czasie i ocenić, czy wdrożone poprawki faktycznie zadziałały.
• CrUX API i BigQuery: dla bardziej zaawansowanych analiz. Od stycznia 2025 roku CrUX API udostępnia m.in. części składowe LCP dla obrazów, typ zasobu LCP (tekst lub obraz) oraz dane o czasie podróży pakietu w obie strony (RTT).
• Ograniczenia: podobnie jak GSC, CrUX wymaga wystarczającego ruchu. Dane obejmują 28-dniowe okno, więc efekty zmian nie są widoczne od razu.

Biblioteka web-vitals (pomiar na własnej stronie)

Jeśli strona ma za mało ruchu dla CrUX albo chcesz widzieć wyniki szybciej niż po 28 dniach, możesz mierzyć Core Web Vitals samodzielnie. Google udostępnia małą bibliotekę JavaScript web-vitals, która mierzy LCP, INP i CLS u prawdziwych użytkowników i pozwala wysyłać wyniki np. do Google Analytics lub własnego systemu analitycznego. Wersja z atrybucją wskazuje dodatkowo, który element lub która interakcja odpowiada za słaby wynik.

Ważne jest zrozumienie różnicy między danymi laboratoryjnymi (lab data) a rzeczywistymi (field data). Dane laboratoryjne (Lighthouse w PageSpeed Insights lub DevTools) są zbierane w kontrolowanym środowisku, co pozwala na powtarzalne testy i precyzyjną diagnozę, ale nie odzwierciedlają różnorodności urządzeń, sieci i zachowań użytkowników. Dane terenowe z CrUX (dostępne w GSC, PSI, CrUX Vis i DevTools) pochodzą od prawdziwych użytkowników i to one są podstawą oceny Core Web Vitals.

Co zmieniło się w Core Web Vitals w latach 2025–2026?

Sam zestaw wskaźników i progi się nie zmieniły: od marca 2024 roku Core Web Vitals to nadal LCP, INP i CLS. Zmieniły się natomiast narzędzia i sposób pomiaru:

• Styczeń 2025: CrUX API udostępnia części składowe LCP dla obrazów, typ zasobu LCP oraz dane o opóźnieniach sieci (RTT). W tym samym miesiącu zakończyło się wsparcie rozszerzenia Web Vitals – jego funkcje (metryki na żywo, porównanie z danymi CrUX) są w panelu Performance w Chrome DevTools.
• Październik 2025: Lighthouse 13 zastąpił dawne audyty wydajności nowymi insights (także w PageSpeed Insights). Sposób liczenia wyniku wydajności się nie zmienił.
• Listopad 2025: wycofanie CrUX Dashboard w Looker Studio – zamiennikiem jest CrUX Vis.
• Lipiec 2026 – Soft Navigations: od Chrome 151 (wydanie stabilne 28 lipca 2026) API Soft Navigations jest domyślnie włączone. Pozwala mierzyć wskaźniki w aplikacjach typu SPA, w których przejście na kolejną podstronę nie przeładowuje całej strony. Google zapowiadało, że o ewentualnym uwzględnieniu tych danych w CrUX zdecyduje dopiero po udostępnieniu API – do tego czasu nie wpływają one na ocenę Core Web Vitals w Search Console.

Ogólne strategie optymalizacji Core Web Vitals

Optymalizacja Core Web Vitals wymaga działań na kilku płaszczyznach naraz. Poniżej zebrałem strategie, które najczęściej poprawiają wyniki – z zaznaczeniem, na który wskaźnik wpływają.

Optymalizacja obrazów

Obrazy są często największymi elementami na stronie, więc mają duży wpływ na LCP, a brak ich wymiarów – na CLS.

• Użycie odpowiednich formatów: WebP i AVIF oferują lepszą kompresję niż JPEG i PNG przy porównywalnej jakości.
• Kompresja i właściwy rozmiar: kompresuj obrazy i nie wysyłaj pliku o szerokości 3000 px tam, gdzie wyświetla się w 800 px. WordPress generuje kilka rozmiarów każdego obrazu i atrybut srcset, pod warunkiem że motyw z nich korzysta.
• Określanie wymiarów: atrybuty width i height pozwalają przeglądarce zarezerwować miejsce i zapobiegają przesunięciom układu (CLS).
• Leniwe ładowanie (Lazy Loading) – tylko poniżej pierwszego ekranu: obrazy, których nie widać od razu, mogą ładować się dopiero przy przewijaniu. To zmniejsza początkowe obciążenie strony. Obraz LCP i inne obrazy widoczne na starcie nie powinny mieć lazy loadingu.
• Priorytetyzacja kluczowych obrazów: dla obrazu LCP użyj atrybutu fetchpriority=”high”, a jeśli obraz nie jest widoczny w HTML (np. jest tłem w CSS) – link rel=”preload”.

Minimalizacja i odraczanie wykonywania JavaScriptu

Nadmiar JavaScriptu spowalnia zarówno ładowanie (LCP), jak i reakcję na kliknięcia (INP).

• Minimalizacja kodu: usuwanie zbędnych znaków, spacji i komentarzy zmniejsza rozmiar plików.
• Odraczanie niekrytycznych skryptów: skrypty niepotrzebne do początkowego renderowania ładuj asynchronicznie (async) lub z odroczeniem (defer), żeby nie blokowały renderowania.
• Usuwanie nieużywanego kodu: regularnie sprawdzaj, które skrypty są naprawdę potrzebne. W WordPressie największym źródłem zbędnego JavaScriptu są zwykle wtyczki i page buildery.
• Rozbijanie długich zadań: długie funkcje JavaScript dziel na mniejsze zadania, aby główny wątek mógł w międzyczasie reagować na interakcje.

Wykorzystanie sieci dostarczania treści (CDN)

Content Delivery Network (CDN) to sieć rozproszonych geograficznie serwerów, która przechowuje kopie zasobów witryny.

• Szybsze dostarczanie treści: CDN dostarcza zasoby z serwera najbliższego użytkownikowi, co skraca czas pobierania plików, a przy cache’owaniu całych stron także TTFB – i w efekcie poprawia LCP.
• Redukcja obciążenia serwera: rozłożenie ruchu na wiele serwerów odciąża serwer główny, co pomaga utrzymać krótki czas odpowiedzi przy dużym ruchu. CDN nie poprawia natomiast INP – responsywność zależy od pracy przeglądarki na urządzeniu użytkownika, a nie od serwera.
• Zwiększona dostępność i bezpieczeństwo: CDN zapewnia redundancję i może chronić przed atakami DDoS.

Wdrożenie skutecznego buforowania (Caching)

Buforowanie polega na przechowywaniu gotowych kopii stron i plików, dzięki czemu nie trzeba ich za każdym razem generować ani pobierać od nowa.

• Buforowanie przeglądarki (Browser Caching): przeglądarka przechowuje statyczne zasoby (obrazy, CSS, JavaScript) lokalnie, więc przy kolejnej wizycie nie pobiera ich ponownie.
• Buforowanie po stronie serwera (Server-Side Caching): cache całych stron (w WordPressie przez wtyczkę cache lub mechanizm serwera) oraz cache obiektów (np. Redis, Memcached) zmniejszają obciążenie bazy danych i skracają TTFB, co przekłada się na LCP.

Optymalizacja CSS

Pliki CSS odpowiadają za wygląd i układ strony, a ich optymalizacja wpływa na LCP i CLS.

• Minimalizacja CSS: podobnie jak w przypadku JavaScriptu, usuwaj zbędne znaki i nieużywane reguły.
• Redukcja blokującego renderowanie CSS: unikaj ładowania w sekcji <head> dużych arkuszy, które nie są potrzebne do wyświetlenia pierwszego ekranu. Krytyczny CSS (dla treści „above the fold”) można umieścić bezpośrednio w HTML.
• Optymalizacja czcionek: jak wspomniałem w sekcji o CLS, wstępne ładowanie czcionek, font-display i dopasowane czcionki zastępcze zapobiegają przesunięciom układu.

Poprawa czasu odpowiedzi serwera (SRT)

Czas odpowiedzi serwera (Server Response Time – SRT), mierzony w praktyce jako TTFB, to pierwsza część LCP – każda milisekunda opóźnienia serwera przesuwa wyświetlenie głównej treści.

• Wybór niezawodnego hostingu: szybki i stabilny hosting z aktualną wersją PHP to fundament dobrego czasu odpowiedzi w WordPressie.
• Optymalizacja zapytań do bazy danych: szybkie zapytania i indeksy są kluczowe dla stron dynamicznych. W WordPressie spowalniają je często rozbudowane wtyczki i nadmiar danych w tabeli opcji ładowanych przy każdym żądaniu.
• Redukcja obciążenia serwera: oprócz CDN i cache można rozważyć mocniejszy serwer lub równoważenie obciążenia (load balancing) przy dużym ruchu.

Wbudowane optymalizacje WordPressa

Część pracy wykonuje dziś sam WordPress – pod warunkiem, że jest aktualny, a motyw i wtyczki tego nie blokują:

• WordPress 6.3: automatyczne fetchpriority=”high” dla obrazu, który najprawdopodobniej jest elementem LCP, i pomijanie lazy loadingu dla obrazów widocznych na starcie.
• WordPress 6.8: wbudowane wstępne pobieranie podstron (Speculative Loading, oparte na Speculation Rules API) – domyślnie włączone dla niezalogowanych użytkowników; przeglądarka zaczyna pobierać podstronę, gdy użytkownik zaczyna klikać w link. Działa w przeglądarkach opartych na Chromium.
• WordPress 6.9: m.in. ładowanie stylów bloków tylko wtedy, gdy są potrzebne, także w motywach klasycznych, możliwość ustawiania priorytetu pobierania dla skryptów oraz wymiary w bloku wideo, które eliminują przesunięcia układu.

Podsumowanie i rekomendacje

Core Web Vitals to trzy wskaźniki – LCP, INP i CLS – które mierzą, jak prawdziwi użytkownicy odbierają szybkość, responsywność i stabilność strony. Google używa ich w systemach rankingowych, ale trafność treści pozostaje ważniejsza, więc traktuj CWV jako element przewagi przy podobnej jakości treści, a przede wszystkim jako sposób na lepsze doświadczenie użytkowników. Zmiana FID na INP w 2024 roku oraz zmiany w narzędziach w latach 2025–2026 pokazują, że to obszar, który trzeba monitorować na bieżąco, a nie poprawić raz.

Praktyczna kolejność działań: sprawdź raport Core Web Vitals w Search Console, wybierz najsłabszy wskaźnik i najważniejsze grupy adresów, zdiagnozuj przyczynę w PageSpeed Insights i panelu Performance w DevTools, wdróż poprawki i obserwuj dane terenowe przez kolejne 28 dni. Jeśli potrzebujesz pomocy przy takiej analizie, zobacz, jak wygląda moja optymalizacja strony.

FAQ – najczęstsze pytania o Core Web Vitals

Czym są Core Web Vitals w skrócie?

To trzy wskaźniki Google mierzące doświadczenie użytkownika: LCP (ładowanie głównej treści, dobry wynik ≤ 2,5 s), INP (reakcja na interakcje, ≤ 200 ms) i CLS (stabilność układu, ≤ 0,1). Ocenia się je na 75. percentylu odsłon z danych prawdziwych użytkowników Chrome.

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

Tak – Google potwierdza, że jego systemy rankingowe używają Core Web Vitals. Jednocześnie zaznacza, że najtrafniejsza treść może wygrać nawet przy słabym doświadczeniu strony. Dobre wyniki CWV pomagają więc głównie wtedy, gdy konkurencyjne strony mają podobnie wartościową treść.

Czym INP różni się od FID?

FID mierzył tylko opóźnienie pierwszej interakcji na stronie. INP, który zastąpił FID 12 marca 2024 roku, uwzględnia wszystkie kliknięcia, stuknięcia i naciśnięcia klawiszy podczas wizyty i mierzy pełny czas do wyświetlenia reakcji na ekranie.

Dlaczego PageSpeed Insights pokazuje inne wyniki niż Search Console?

Search Console pokazuje dane terenowe z CrUX dla grup adresów z ostatnich 28 dni. PageSpeed Insights pokazuje dane terenowe dla konkretnego adresu (lub całej domeny, gdy adres ma za mało danych) oraz osobno jednorazowy test laboratoryjny Lighthouse. Wynik wydajności 0–100 z Lighthouse nie jest oceną Core Web Vitals.

Moja strona nie ma danych w raporcie Core Web Vitals. Co zrobić?

Raport wymaga minimalnej liczby wizyt użytkowników Chrome, więc małe strony często go nie mają. W takiej sytuacji mierz wskaźniki samodzielnie biblioteką web-vitals, a do diagnozy używaj panelu Performance w Chrome DevTools i testu Lighthouse.

Jak szybko widać efekty poprawy Core Web Vitals?

W testach laboratoryjnych – od razu po wdrożeniu. W danych terenowych (Search Console, CrUX) zmiana pojawia się stopniowo, bo wyniki obejmują 28-dniowe okno. Pełny efekt zobaczysz więc po około czterech tygodniach.