Jak poprawić Core Web Vitals i czy to pomaga w Google?

Ten poradnik obejmuje interpretację metryk, diagnozę i wybór poprawek, natomiast wszelkie szczegóły wdrożenia w React, Next.js i Astro znajdziesz w podlinkowanych artykułach.

Czym są Core Web Vitals i jakie mają progi?

Core Web Vitals to trzy metryki doświadczenia użytkownika i każda z nich opisuje coś innego. LCP opisuje ładowanie głównej treści, INP responsywność interfejsu, a CLS stabilność wizualną strony internetowej. Warto też odnotować, że INP zastąpił FID w marcu 2024 roku, więc mój poradnik to uwzględnia i dotyczy obecnego zestawu CWV.

CLS to bezwymiarowa punktacja przesunięć, a TTFB, FCP i TBT służą do diagnozy wydajności poza trójką Core Web Vitals. Progi i sposób ich oceny podaję za dokumentacją web.dev, gdzie w 2026 roku nadal obowiązują te same wartości.

Jak interpretować 75. percentyl i zaliczenie CWV?

75. percentyl, czyli p75, to wartość, której nie przekracza 75% zebranych pomiarów danej metryki. W sytuacji, kiedy p75 LCP wynosi 2,4 s, co najmniej trzy czwarte pomiarów mieści się w tej wartości. Najwolniejsza ćwiartka wejść leży powyżej tej granicy, a sama próba obejmuje tylko użytkowników kwalifikujących się do CrUX.

CrUX zbiera dane od kwalifikujących się użytkowników Chrome na komputerach i Androidzie, więc nie ma w nim Safari, Chrome na iOS, Edge ani stron otwieranych w aplikacjach przez WebView. W PageSpeed Insights widzisz kroczące okno ostatnich 28 dni, osobno dla mobile i desktop. Ten podział dotyczy urządzeń użytkowników i nie ma związku z mobile-first indexing, które opisuje sposób pobierania treści przez Googlebota.

Według dokumentacji PageSpeed Insights zaliczenie oceny przy komplecie danych wymaga dobrego p75 dla wszystkich trzech metryk. Istnieje natomiast jeden wyjątek, ponieważ jeśli brakuje wystarczających danych INP, PSI ocenia stronę na podstawie samych LCP i CLS. Brak INP oznacza wtedy lukę w pomiarze responsywności, a gdy zabraknie danych LCP albo CLS, PSI w ogóle nie wystawia oceny.

Czy Core Web Vitals poprawiają pozycje i wpływają na indeksację?

Dokumentacja Google Search Central potwierdza wykorzystanie CWV w systemach rankingowych, ale jednocześnie nie podaje ich wagi ani przelicznika milisekund na pozycje. Nie mamy więc konkretnych odpowiedzi, jak metryki wpływają na SERP. Dobre doświadczenie użytkownika pomaga, gdy wyszukiwarka ma do wyboru wiele przydatnych odpowiedzi, bo pierwszeństwo nadal ma trafna, wartościowa treść.

Jednocześnie trzeba pamiętać, że zaliczenie CWV nie jest warunkiem technicznym indeksacji. Lista wymagań technicznych Google obejmuje między innymi dostęp dla robota, działającą stronę z odpowiedzią HTTP 200 i treść nadającą się do indeksowania, ale spełnienie tych warunków nie gwarantuje dodania strony do indeksu. Moim zdaniem kryteria dodania strony do indeksu są cały czas zaostrzane, choćby ze względu na pojawienie się modeli LLM (czyli AI), które potrafią tworzyć treść masowo.

W sytuacji, kiedy artykułu nie ma w Google, zacznij od inspekcji URL. Musisz określić powód wykluczenia, ostatnie pobranie, noindex, link kanoniczny oraz treść dostępną dla robota. W dalszej kolejności musisz przeanalizować też linki prowadzące do wpisu i to, czy odpowiada na odrębną potrzebę względem innych artykułów. Kolejne kroki opisuję w poradniku Google Search Console i diagnozowania indeksacji.

Jedno powiązanie wydajności z indeksacją jednak istnieje i dotyczy crawlowania. W sytuacji, gdy serwer odpowiada wolno albo zwraca błędy 5xx, Googlebot zmniejsza tempo pobierania stron, co w dużym serwisie opóźnia odkrywanie nowych adresów. Co o tym decyduje? Czas odpowiedzi i stabilność serwera, niezależnie od oceny Core Web Vitals. Jak śledzić ten efekt w logach, pokazuję w artykule o analizie logów Cloudflare pod kątem crawl budgetu.

Jak mierzyć Core Web Vitals: CrUX, Lighthouse i RUM

Dobór narzędzia zależy od pytania, na które szukasz odpowiedzi.

Według pomocy Search Console raport opiera się na danych CrUX i grupuje adresy o podobnym doświadczeniu i dlatego poprawkę szablonu warto sprawdzić na kilku reprezentatywnych stronach, a nie opierając się na pierwszym przykładzie z raportu. Jak czytać statusy grup i dlaczego o statusie decyduje najsłabsza metryka, pokazuję w przewodniku po Search Console w Next.js.

Warto nadmienić, że brak danych terenowych nie oznacza słabej strony internetowej. Najczęściej witryna ma po prostu za mało wizyt, ale CrUX pomija też strony, które nie zwracają kodu HTTP 200 albo mają noindex, więc landing z noindex nigdy nie dostanie danych dla swojego URL-a. PSI pokazuje wtedy dane całego originu, obejmującego protokół, host i port, np. https://strivelab.pl, czyli zbiorcze doświadczenie z całego serwisu. Gdy również origin nie ma danych, nadal możesz wykonać test laboratoryjny i uruchomić RUM.

Dlaczego Lighthouse jest zielony, a Search Console czerwone?

Lighthouse sprawdza pojedynczy scenariusz w określonych warunkach, a CrUX obejmuje różne urządzenia, sieci i zachowania z wielu dni, dlatego dane terenowe często wskazują zupełnie inne problemy niż test laboratoryjny. Użytkownik może otworzyć filtr po minucie albo zobaczyć przesunięcie reklamy podczas czytania, a zwykły audyt ładowania żadnej z tych sytuacji nie odtworzy.

Standardowy audyt nawigacyjny Lighthouse nie mierzy INP. Pokazuje za to TBT, czyli Total Blocking Time, który wskazuje blokowanie głównego wątku podczas ładowania, więc menu, formularze i filtry trzeba sprawdzić osobno. Służy do tego panel Performance w Chrome DevTools, do którego wraz z Chrome 132 trafiły funkcje wycofanego rozszerzenia Web Vitals. Według dokumentacji Chrome DevTools widok Live metrics mierzy LCP, INP i CLS podczas Twojej wizyty, po włączeniu danych terenowych pokazuje obok wyniki CrUX dla tego samego adresu, a log interakcji rozbija każde kliknięcie na fazy.

Warto tutaj omówić własny RUM, który przydaje się do znalezienia konkretnej interakcji lub elementu odpowiedzialnego za problem. Przy wdrożeniu zbieraj kontekst adresu, urządzenia, przeglądarki i wersji aplikacji, a wynik licz jako p75 z pomiarów, bo średnia ukrywa najwolniejsze wizyty. Samo wysłanie zdarzenia do GA4 nie tworzy jeszcze poprawnego raportu CWV, a przykład własnego reportera w Next.js pokazuję w artykule o monitorowaniu aplikacji Next.js na produkcji.

Podział na przeglądarki ma dziś konkretne uzasadnienie. Od Safari 26.2, wydanego w grudniu 2025 roku, LCP i INP mierzą wszystkie duże przeglądarki, więc RUM widzi też użytkowników iPhone'ów, których w CrUX nie ma i według web.dev nie będzie. CLS nadal raportują tylko przeglądarki oparte na Chromium, a wyniki z różnych silników różnią się o pojedyncze milisekundy, bo Chrome liczy LCP do chwili prezentacji klatki, a Safari i Firefox do momentu jej namalowania. Zielony raport w Search Console nic nie mówi o tym, jak Twoja strona działa na iPhone'ach.

Jak CrUX mierzy aplikacje Next.js z nawigacją po stronie klienta?

W aplikacji z nawigacją po stronie klienta, na przykład w Next.js albo innym SPA, przeglądarka pobiera dokument HTML tylko raz i ma to miejsce przy pierwszym wejściu. Metodologia CrUX mówi wprost, że całe takie doświadczenie jest przypisywane do pierwszego wyświetlenia strony. INP i CLS z kolejnych widoków trafiają więc do adresu, od którego zaczęła się wizyta, a LCP dotyczy wyłącznie pierwszego, pełnego ładowania. Dlatego Search Console potrafi wskazać szablon artykułu, choć wolny filtr działa na liście produktów, do której użytkownik przeszedł z tego artykułu.

Od Chrome 151 przeglądarka domyślnie rozpoznaje takie przejścia dzięki Soft Navigations API, a biblioteka web-vitals z opcją reportSoftNavs raportuje metryki osobno dla każdego widoku. Sposób ujęcia miękkich nawigacji w CrUX Google nadal określa jako otwarty, więc Search Console przypisuje całą wizytę do strony wejścia. W przypadku własnego RUM zapisuj trasę z chwili interakcji. INP i CLS są zwykle wysyłane dopiero przy ukryciu karty, więc adres odczytany w momencie wysyłki wskaże ostatnią odwiedzoną podstronę, która nie musi być miejscem wolnej interakcji.

LCP: jak przyspieszyć wyświetlenie głównej treści?

LCP (Largest Contentful Paint) to czas od rozpoczęcia ładowania strony do wyrenderowania największego elementu treści w widocznym obszarze ekranu. Do tej kategorii zaliczają się obrazy, bloki tekstu oraz materiały wideo. Warto pamiętać, że w wersji mobilnej i stacjonarnej może to być zupełnie inny element, w związku z czym najpierw zidentyfikuj go w nagraniu w zakładce Performance.

Z jakich części składa się LCP?

Dla LCP opartego na obrazie przydaje się podział na cztery części:

Trzeba pamiętać, że nie istnieje jakaś uniwersalna proporcja tych części, która wskazuje jedną przyczynę, a gdy LCP jest tekstem, podział wygląda inaczej niż dla osobno pobieranego obrazu – co wyjaśnia poradnik optymalizacji LCP. Ten sam podział znajdziesz w narzędziu PageSpeed Insights w sekcji „LCP breakdown”. Obok wyświetla się wskazówka „LCP request discovery”, która weryfikuje, czy obraz LCP jest widoczny bezpośrednio w początkowym kodzie HTML, nie posiada atrybutu loading="lazy" oraz ma przypisany priorytet fetchpriority="high".

Które poprawki wdrożyć najpierw?

1. Nie stosuj lazy loadingu do obrazu LCP. Obrazy poza początkowym widokiem mogą ładować się później.
2. Ułatw pobranie właściwego zasobu. Dla obrazu LCP rozważ fetchpriority="high"; preload przydaje się zwłaszcza przy późnym odkrywaniu zasobu. Nie nadawaj wysokiego priorytetu całej galerii.
3. Dostarczaj obraz odpowiadający rozmiarowi wyświetlania. Mały ekran nie powinien bez potrzeby pobierać grafiki przygotowanej dla dużego monitora.
4. Sprawdź serwer i renderowanie. Buforowanie w cache lub generowanie statyczne skutecznie skracają TTFB. Z kolei samo SSR nie zapewnia automatycznie wysokiej wydajności — czas generowania odpowiedzi przez serwer i zasoby blokujące nadal robią swoje. Jak streaming i Suspense przyspieszają pierwszą treść w Next.js, opisuję w poradniku o streamingu.

Konfigurację obrazów, sizes, fill i preload opisuję w porównaniu next/image, srcset i CDN. Kiedy problem wynika z dostępności treści dopiero po wykonaniu JavaScript, przeczytaj kiedy Next.js daje przewagę pod SEO.

Jak bfcache i prerendering skracają LCP kolejnych wejść?

CrUX od danych za marzec 2024 roku raportuje typy nawigacji, w tym powroty obsłużone z pamięci podręcznej wstecz/dalej (bfcache) i strony wyrenderowane z wyprzedzeniem (prerender). Takie wejścia mają LCP bliskie zeru i realnie obniżają p75 całego adresu, a strona wykluczona z bfcache przy każdym powrocie przyciskiem „Wstecz” ładuje się od nowa.

Stan sprawdzisz w Chrome DevTools, w zakładce Application → Back/forward cache, która podaje też powody odrzucenia strony. Nagłówek Cache-Control: no-store przestał być bezwarunkową blokadą, bo Chrome od 2025 roku wpuszcza do bfcache część takich stron i usuwa je z pamięci, gdy zmienią się ciasteczka, co opisuje dokumentacja bfcache dla no-store. Prerendering kolejnych podstron umożliwia z kolei Speculation Rules API, obsługiwane przez przeglądarki oparte na Chromium.

INP: jak poprawić reakcję na kliknięcia i wpisywanie?

INP (Interaction to Next Paint) to czas od interakcji użytkownika do wyświetlenia kolejnej klatki, raportowany dla praktycznie najwolniejszej interakcji podczas wizyty. Metryka obejmuje kliknięcia, dotknięcia ekranu oraz użycie klawiatury. Definicja ta pomija samo przewijanie strony i najechanie kursorem. Co do zasady wynik odzwierciedla najwolniejszą interakcję, przy czym na każde 50 zdarzeń pomiar odrzuca jedną wartość skrajną. W sytuacji, kiedy użytkownik nie wykona żadnej z tych akcji, wskaźnik INP po prostu nie zostanie zmierzony.

INP mierzy całą drogę od interakcji do kolejnej klatki. Najdłuższe zadanie JavaScript to tylko fragment tej drogi, na którą składają się:

• Input delay: oczekiwanie na rozpoczęcie obsługi, np. gdy główny wątek zajmuje inny skrypt.
• Processing duration: wykonanie procedur obsługi zdarzeń.
• Presentation delay: czas do wyświetlenia kolejnej klatki, obejmujący potrzebną pracę nad renderowaniem.

Kiedy nie wiesz, które działanie nagrać, zacznij od danych terenowych. Wersja attribution biblioteki web-vitals dołącza do INP selektor elementu i trzy powyższe fazy, a w przeglądarkach opartych na Chromium także wpisy Long Animation Frames z listą skryptów, które blokowały klatkę. Po adresie skryptu od razu widać, czy winny jest Twój kod, czy widżet zewnętrzny.

Poradnik optymalizacji INP zaleca potem prostą metodę, by nagrać w Performance konkretne działanie, np. otwarcie menu lub zmianę filtra, i następnie sprawdzić, która część trwa najdłużej. Następnie dobierz odpowiednią poprawkę:

• Ogranicz zbędny JavaScript i koszt uruchamiania zewnętrznych widżetów. Odkładanie wszystkich widżetów do pierwszego kliknięcia może przerzucić ich koszt właśnie na tę interakcję, a async i defer przesuwają tylko moment pobrania i uruchomienia skryptu, więc koszt ich wykonania zostaje. Opóźnione ładowanie GTM na realnym projekcie pokazuję w case study PageSpeed 100/100 w Next.js.

• Dziel długie zadania na mniejsze i oddawaj sterowanie przeglądarce przez scheduler.yield(), dostępne w Chrome i Edge od wersji 129 oraz w Firefoksie od 142. W Safari zostaje fallback na setTimeout. Ciężkie obliczenia niewymagające DOM mogą trafić do Web Workera.

• Skróć handlery oraz ogranicz niepotrzebne renderowanie i rozmiar aktualizowanego DOM.

• Pokaż informację zwrotną natychmiast, na przykład stan „Wyszukiwanie…”, a mniej pilną pracę odłóż. Przy wyszukiwaniu debounce może ograniczyć żądania, ale wpisywany tekst powinien pojawiać się od razu.

Pomiar INP kończy się na kolejnym odmalowaniu, więc czas do pojawienia się wyników wyszukiwania albo zapisu formularza leży poza nim i wymaga osobnej metryki.

Przykłady pracy ze stanem i dużymi listami znajdziesz w artykule o wzorcach pogarszających INP w React. Gdy problem zaczyna się od ilości kodu, przejdź do analizy i zmniejszania paczki JavaScript w Next.js.

CLS: jak ograniczyć przesunięcia układu?

CLS (Cumulative Layout Shift) to bezwymiarowa miara nieoczekiwanych przesunięć widocznych elementów strony. Obecna definicja bierze pod uwagę największą sumę punktacji przesunięć w jednym oknie sesji: maksymalnie pięć sekund, z przerwami krótszymi niż sekunda między przesunięciami. Wynik odzwierciedla więc najsłabszy moment całej wizyty, a kolejne okna czasowe już go nie zwiększają. Co istotne, pomiar obejmuje też zachowanie strony po jej załadowaniu. Zgodnie z dokumentacją CLS przesunięcia występujące w ciągu 500 ms od akcji użytkownika są traktowane jako oczekiwane i nie wpływają na wynik. Pamiętaj jednak, że samo przewijanie strony takiego wyłączenia nie daje.

Jak znaleźć i usunąć źródło przesunięcia?

Nagraj w panelu Performance ładowanie i przewijanie strony, a potem porównaj zdarzenia przesunięć na klatkach przed zmianą i po niej. Element, który się przesunął, nie zawsze jest przyczyną, ponieważ tekst potrafi się obniżyć ze względu na reklamę wczytaną powyżej. Sekcja „Layout shift culprits” w Lighthouse i DevTools wskazuje typowych sprawców tego zjawiska i mogą to być np. obrazy bez określonych wymiarów, wstrzyknięte iframe'y czy przeskoki przy ładowaniu fontów.

• Obrazy i wideo: podawaj prawidłowe width i height albo rezerwuj proporcje przez aspect-ratio. Dla responsywnego obrazu CSS powinien zachowywać te proporcje.

• Reklamy, embedy i dane z API: rezerwuj miejsce odpowiadające docelowemu układowi. Zbyt małe min-height nie zapobiegnie późniejszemu powiększeniu kontenera.

• Fonty: dobierz fallback o zbliżonych metrykach. Samo font-display: swap pozwala wcześniej pokazać tekst, ale nie zapobiega przesunięciu przy zmianie kroju. Jak next/font z size-adjust sprowadził CLS z fontów do zera, pokazuję w case study PageSpeed 100/100.

• Banery i animacje: unikaj niespodziewanego przesuwania już czytanej treści. Animowanie transform zamiast właściwości zmieniających układ pomaga ograniczać takie zmiany. Przykłady dla Framer Motion pokazuję w artykule o wydajnych animacjach w Next.js.

Poradnik optymalizacji CLS szczegółowo omawia odpowiednie techniki i przykłady. Warto pamiętać, że dedykowane komponenty frameworka rozwiążą problem tylko częściowo: optymalizacja obrazu nie pomoże, gdy brak przestrzeni na reklamę lub dynamiczny baner i tak rozbije układ strony. Wdrożenie dla Astro opisuję w artykule o technicznym fundamencie SEO w Astro.

Jak baner zgód na cookies wpływa na LCP, INP i CLS?

Baner zgód ma dziś niemal każda strona firmowa w Polsce, a co ciekawe, według web.dev potrafi on pogorszyć wszystkie trzy metryki naraz. Na telefonie baner z długim tekstem zajmuje dużą część ekranu i bywa elementem LCP, więc wynik zależy wtedy od chwili, w której skrypt platformy zgód (CMP) go wyświetli. Baner wstawiony u góry już po wyrenderowaniu strony spycha treść w dół i podbija CLS, dlatego pokazuj go jako nakładkę (przyklejoną stopkę lub okno modalne) albo zarezerwuj dla niego miejsce w układzie. W wypadku strony StriveLab zdecydowałem się na mały, już przeskalowany pod mobile banerek, który przede wszystkim nie powinien być nadmiernie kłopotliwy.

W przypadku INP problem pojawia się w momencie, którego standardowy test ładowania strony po prostu nie wywoła. Kliknięcie „Akceptuj wszystkie” uruchamia jednocześnie analitykę, piksele reklamowe i czat, zrzucając cały ten ciężar na jedną interakcję. Aby temu zapobiec, skrypt CMP ładuj z atrybutem async bezpośrednio w HTML-u strony (z pominięciem menedżera tagów), a mniej pilne tagi odpalaj po uzyskaniu zgody etapami. Kolejność sygnałów Consent Mode opisuję w artykule o konfiguracji GA4 i Google Tag Manager w Next.js, a współpracę CMP z pomiarem konwersji w poradniku o landing page dla Google Ads.

Które poprawki pomagają na którą metrykę?

Poniższa tabela zbiera najczęstsze przyczyny słabych wyników i pierwsze kroki opisane w poprzednich sekcjach. Zanim wybierzesz poprawkę, potwierdź przyczynę w nagraniu z panelu Performance albo w danych RUM.

Jak wygląda diagnoza Core Web Vitals w praktyce?

Poniższy przykład jest tylko i wyłącznie ilustracyjny i nie pochodzi z pomiaru konkretnego klienta. Załóżmy, że szablon artykułów ma mobilne p75: LCP 3,6 s, INP 160 ms i CLS 0,04. Pierwszym naszym zadaniem jest zbadanie LCP na kilku wpisach korzystających z tego szablonu. W nagraniu jednego wejścia wychodzi tak: TTFB 0,5 s, opóźnienie rozpoczęcia pobierania obrazu 1,7 s, pobieranie 0,6 s i opóźnienie renderowania 0,8 s. Te części sumują się do LCP 3,6 s tego wejścia, co nie oznacza, że można sumować percentyle poszczególnych faz z wielu wizyt.

Największa zwłoka występuje przed pobraniem obrazu, dlatego wtedy trzeba sprawdzić, czy grafika trafia do HTML dopiero po uruchomieniu aplikacji i czy nie ma loading="lazy". Następnie po poprawce porównujesz kilka testów w tych samych warunkach, a po wdrożeniu przechodzisz do obserwacji danych użytkowników. Sama konwersja pliku na AVIF nie rozwiąże problemu tak dużego opóźnienia rozpoczęcia pobierania.

Jak ustalić priorytety i potwierdzić efekt optymalizacji?

• Zapisz punkt wyjścia. Zanotuj p75, okres, urządzenie oraz zakres raportu: URL, origin czy grupa stron. Przy braku CrUX zapisz scenariusze i warunki testów lokalnych.

• Wybierz problem o największym znaczeniu. Uwzględnij przekroczenie progu, liczbę dotkniętych stron i znaczenie interakcji dla użytkownika. Wolne wysłanie formularza może być pilniejsze niż drobna poprawa już dobrego LCP.

• Sformułuj hipotezę i wprowadź ograniczoną zmianę. Przykładowo: filtr listy przelicza wszystkie produkty bezpośrednio w obsłudze kliknięcia. Przeniesienie tej pracy za kolejne odrysowanie klatki skróci czas przetwarzania i obniży wskaźnik INP.

• Powtórz reprezentatywne scenariusze. Testuj build produkcyjny, mobile i desktop, wolniejsze CPU oraz sieć. Sprawdź również interakcje podczas ładowania i stan po uruchomieniu skryptów marketingowych.

• Oceń dane po wdrożeniu. RUM pozwala wcześniej porównać nowe pomiary. CrUX i GSC odzwierciedlają zmianę stopniowo: każde kolejne 28-dniowe okno zawiera więcej wizyt po wdrożeniu, dlatego pierwsze przesunięcie zobaczysz przed upływem pełnych 28 dni. Trend śledź w CrUX Vis, które pokazuje tygodniowe punkty z ostatnich 40 tygodni, a w raporcie CWV w Search Console kliknij „Rozpocznij śledzenie”, żeby uruchomić 28-dniowe monitorowanie poprawki.

• Zabezpiecz poprawkę przed regresją. Ustal budżet wydajności i kontroluj ważne szablony po zmianach. Konfigurację opisuję w poradniku blokowania zmian pogarszających LCP i INP w Next.js.

Szybsza i stabilniejsza strona internetowa może ułatwiać zakupy i wysyłanie formularzy, zmniejszać frustrację użytkowników i ograniczać problemy na słabszych urządzeniach. Ocena wpływu na biznes musi jednak zostać przeprowadzona oddzielnie od wyniku testu: należy sprawdzić konwersję, ukończenie formularzy i błędy, uwzględniając zmiany ruchu. Sposób liczenia opłacalności opisuję w artykule o koszcie opóźnienia strony i Core Web Vitals.

Audyt techniczny i optymalizacja pod kątem SEO i GEO.

Audyt techniczny SEO