Core Web Vitals w 2026 — kompletny przewodnik po LCP, INP i CLS

Core Web Vitals to zestaw trzech wskaźników, za pomocą których Google ocenia, jak strona zachowuje się z perspektywy realnego użytkownika: jak szybko pojawia się główna treść, jak responsywna jest strona podczas interakcji i czy elementy na ekranie nie „skaczą" w trakcie ładowania. To nie są abstrakcyjne metryki dla programistów — bezpośrednio wpływają na to, czy odwiedzający zostanie na stronie, dokończy zakup lub wypełni formularz kontaktowy.

W tym przewodniku wyjaśniamy, czym są poszczególne wskaźniki, jakie progi uznaje się za dobre, jak je mierzyć oraz jakie działania techniczne realnie poprawiają wyniki. Pokazujemy też, dlaczego wybór technologii — na przykład architektury headless zamiast klasycznego motywu WordPress — ma bezpośrednie przełożenie na to, czy strona spełnia wymagania Core Web Vitals bez ciągłych poprawek.

Czym są Core Web Vitals i dlaczego mają znaczenie

Core Web Vitals powstały jako część szerszej inicjatywy Google Page Experience, której celem jest promowanie stron zapewniających dobre wrażenia użytkownikom. Zamiast oceniać wydajność wyłącznie w warunkach laboratoryjnych, Google opiera się na danych zbieranych z realnych sesji przeglądania — w ramach raportu Chrome User Experience Report (CrUX). Oznacza to, że wynik strony zależy od tego, jak faktycznie zachowuje się ona na urządzeniach i łączach realnych odwiedzających, a nie tylko na szybkim komputerze testowym.

Trzy wskaźniki wchodzące w skład Core Web Vitals to:

• LCP (Largest Contentful Paint) — czas wyrenderowania największego widocznego elementu treści.
• INP (Interaction to Next Paint) — czas reakcji strony na interakcje użytkownika w trakcie całej sesji.
• CLS (Cumulative Layout Shift) — suma niespodziewanych przesunięć elementów w układzie strony.

Wskaźniki te są elementem algorytmu wyszukiwarki, ale ich znaczenie wykracza poza SEO. Strona, która ładuje się szybko i reaguje płynnie, po prostu lepiej konwertuje — niezależnie od tego, czy branża to e-commerce, usługi B2B czy media.

Warto podkreślić, że Google raportuje wyniki Core Web Vitals osobno dla urządzeń mobilnych i desktopowych, ponieważ warunki sieciowe, moc obliczeniowa i sposób interakcji różnią się na tyle mocno, że wspólny wynik zacierałby realny obraz sytuacji. W praktyce strona może osiągać dobre wyniki na desktopie i jednocześnie wymagać poprawy na urządzeniach mobilnych — dlatego audyt wydajności powinien zawsze uwzględniać oba segmenty osobno, a nie tylko uśredniony wynik.

LCP — jak szybko użytkownik widzi treść

Largest Contentful Paint mierzy moment, w którym w widocznym obszarze ekranu (viewport) renderuje się największy element — najczęściej jest to nagłówek, duży blok tekstu, obraz hero lub tło wideo. Im szybciej ten element się pojawia, tym mniej czasu użytkownik spędza, patrząc na pusty lub częściowo załadowany ekran.

Google przyjmuje następujące progi dla LCP mierzonego na 75. percentylu wizyt:

• Dobry wynik: do 2,5 sekundy.
• Wymaga poprawy: od 2,5 do 4 sekund.
• Słaby wynik: powyżej 4 sekund.

Najczęstsze przyczyny wysokiego LCP to zbyt wolny serwer (długi czas odpowiedzi backendu, określany jako TTFB — Time to First Byte), nieoptymalizowane obrazy w dużych rozdzielczościach, blokujące renderowanie arkusze CSS i skrypty ładowane przed właściwą treścią oraz brak wcześniejszego załadowania (preload) kluczowego zasobu, takiego jak czcionka czy obraz hero. W praktyce poprawa LCP najczęściej wymaga kombinacji: lżejszego hostingu lub CDN, kompresji i właściwego formatu obrazów oraz przemyślanej kolejności ładowania zasobów krytycznych dla pierwszego ekranu.

Warto zwrócić uwagę, że sam czas odpowiedzi serwera to dopiero początek ścieżki renderowania. Nawet szybki backend nie pomoże, jeśli przeglądarka musi najpierw pobrać i przetworzyć duży plik CSS, zanim zacznie rysować treść, albo jeśli obraz hero ładuje się dopiero po wykonaniu kilku innych żądań sieciowych. Dlatego skuteczna optymalizacja LCP zaczyna się od analizy tzw. ścieżki krytycznej — kolejności, w jakiej przeglądarka pobiera i przetwarza zasoby niezbędne do wyrenderowania pierwszego ekranu.

INP — responsywność strony podczas całej wizyty

Interaction to Next Paint zastąpił wcześniejszy wskaźnik First Input Delay i mierzy czas, jaki upływa od interakcji użytkownika — kliknięcia, dotknięcia, naciśnięcia klawisza — do momentu, w którym przeglądarka wizualnie odpowiada na tę interakcję. W przeciwieństwie do FID, który sprawdzał tylko pierwszą interakcję, INP ocenia responsywność w całej sesji, co czyni go trudniejszym, ale bardziej wiarygodnym wskaźnikiem jakości.

Progi dla INP wyglądają następująco:

• Dobry wynik: do 200 milisekund.
• Wymaga poprawy: od 200 do 500 milisekund.
• Słaby wynik: powyżej 500 milisekund.

Wysoki INP wynika najczęściej z nadmiaru kodu JavaScript wykonywanego w głównym wątku przeglądarki — długich, blokujących zadań, ciężkich bibliotek analitycznych, reklamowych i marketingowych ładowanych synchronicznie, a także z nieefektywnych handlerów zdarzeń, które przeliczają zbyt wiele w odpowiedzi na proste kliknięcie. Rozwiązaniem jest dzielenie kodu na mniejsze fragmenty, odkładanie w czasie (defer) skryptów niekrytycznych, ograniczanie liczby zewnętrznych tagów oraz stosowanie technik takich jak dzielenie długich zadań na mniejsze części, by wątek główny mógł w każdej chwili obsłużyć interakcję użytkownika.

Ponieważ INP wymaga rzeczywistej interakcji użytkownika, nie da się go bezpośrednio zmierzyć w standardowym teście laboratoryjnym uruchamianym automatycznie, bez klikania w stronę. Z tego powodu narzędzia takie jak Lighthouse posługują się zastępczą metryką Total Blocking Time (TBT), która sumuje czas, przez jaki główny wątek był zablokowany długimi zadaniami podczas ładowania strony. Niski TBT w danych laboratoryjnych jest dobrym wskaźnikiem tego, że strona ma potencjał osiągnąć dobry wynik INP także w danych terenowych, choć nie jest to gwarancja jeden do jednego.

CLS — stabilność wizualna układu strony

Cumulative Layout Shift ocenia, jak bardzo elementy na stronie przesuwają się w sposób nieoczekiwany podczas ładowania lub interakcji — na przykład gdy tekst „skacze" w dół, bo dopiero co załadował się baner reklamowy, albo przycisk przesuwa się w momencie, gdy użytkownik zamierzał go kliknąć. To jeden z najbardziej frustrujących problemów z perspektywy odwiedzającego, bo prowadzi do przypadkowych kliknięć i utraty orientacji na stronie.

Progi CLS są następujące:

• Dobry wynik: do 0,1.
• Wymaga poprawy: od 0,1 do 0,25.
• Słaby wynik: powyżej 0,25.

Najczęstsze źródła przesunięć układu to obrazy i osadzone materiały (wideo, mapy, widżety) bez zarezerwowanego miejsca, dynamicznie wstrzykiwane treści — banery cookie, powiadomienia, reklamy — pojawiające się nad już wyrenderowaną treścią, a także czcionki webowe, które po załadowaniu zmieniają wymiary tekstu. Rozwiązania są stosunkowo proste do wdrożenia: określanie atrybutów szerokości i wysokości dla mediów, rezerwowanie miejsca na elementy ładowane asynchronicznie oraz stosowanie strategii ładowania czcionek, które minimalizują zauważalną zmianę układu.

Jak mierzyć Core Web Vitals

Do oceny wyników warto rozróżniać dwa rodzaje danych. Dane laboratoryjne (lab data) pochodzą z kontrolowanych testów — na przykład z narzędzia Lighthouse — i są przydatne do diagnozowania konkretnych problemów podczas prac deweloperskich. Dane terenowe (field data) pochodzą z realnych wizyt użytkowników i to one decydują o ocenie strony przez Google.

Podstawowe narzędzia do pomiaru:

• PageSpeed Insights — pokazuje jednocześnie dane terenowe (jeśli strona ma wystarczający ruch) i wynik laboratoryjny wraz z listą konkretnych problemów.
• Raport Core Web Vitals w Google Search Console — grupuje adresy URL według wyniku i pokazuje trendy w czasie na poziomie całej witryny.
• Chrome DevTools i Lighthouse — służą do szczegółowej diagnostyki podczas pracy nad konkretną podstroną.
• Biblioteka web-vitals — pozwala zbierać własne dane terenowe i wysyłać je do systemu analitycznego, co daje pełną kontrolę nad monitoringiem.

Pełny audyt techniczny strony powinien obejmować znacznie więcej niż same Core Web Vitals — indeksację, strukturę adresów URL, dane strukturalne czy obsługę przekierowań. Zakres takiego audytu opisaliśmy szczegółowo w liście kontrolnej SEO technicznego, którą warto traktować jako uzupełnienie tego przewodnika.

Jak poprawić Core Web Vitals w praktyce

Poprawa wyników rzadko sprowadza się do jednej zmiany — to zwykle seria działań na poziomie infrastruktury, kodu frontendowego i procesu publikacji treści. Poniżej zestaw działań o największym realnym wpływie:

• Optymalizacja i kompresja obrazów, stosowanie nowoczesnych formatów oraz ładowanie leniwe (lazy loading) dla treści poza pierwszym ekranem.
• Ograniczenie liczby i wagi skryptów zewnętrznych — narzędzi analitycznych, czatów, pikseli reklamowych — oraz ładowanie ich asynchronicznie lub z opóźnieniem.
• Wykorzystanie renderowania po stronie serwera lub generowania statycznego tam, gdzie to możliwe, zamiast polegania wyłącznie na renderowaniu w przeglądarce.
• Wdrożenie sieci CDN i odpowiedniego cache'owania zasobów statycznych, by skrócić czas odpowiedzi niezależnie od lokalizacji użytkownika.
• Rezerwowanie miejsca na elementy dynamiczne i media, by wyeliminować nieoczekiwane przesunięcia układu.
• Regularne monitorowanie wyników po każdej istotnej zmianie na stronie — nowy skrypt marketingowy czy dodatkowy baner potrafią bardzo szybko pogorszyć wskaźniki.
• Stosowanie strategii ładowania czcionek, która pokazuje tekst zapasową czcionką systemową zamiast pozostawiać pusty obszar do czasu pobrania pliku czcionki.

To obszar, w którym warto połączyć pracę techniczną z szerszą strategią widoczności w wyszukiwarce — dobra wydajność wspiera działania SEO, ale nie zastępuje ich. Więcej o tym, jak łączyć oba obszary, można przeczytać w opisie naszej usługi SEO performance.

Core Web Vitals a wybór technologii strony

Wyniki Core Web Vitals w dużej mierze zależą od fundamentu technologicznego strony, a nie tylko od pojedynczych poprawek. Klasyczny motyw WordPress oparty na gotowym szablonie i wielu wtyczkach z natury generuje więcej zapytań do bazy danych, więcej kodu JavaScript i mniej kontroli nad kolejnością ładowania zasobów. Każda kolejna wtyczka — formularz, popup, narzędzie do budowy stron — dokłada swój ciężar, co utrudnia utrzymanie dobrych wyników w dłuższej perspektywie. Różnice między tymi podejściami opisaliśmy szerzej w tekście dedykowany motyw WordPress a gotowy szablon.

Architektura headless, w której WordPress pełni funkcję systemu zarządzania treścią, a warstwa prezentacji budowana jest osobno w technologii takiej jak Next.js, daje znacznie większą kontrolę nad wydajnością. Frontend renderuje dokładnie tyle kodu, ile jest potrzebne, deweloper decyduje o strategii ładowania każdego zasobu, a strona nie jest obciążona kodem wtyczek, których interfejs administracyjny nigdy nie jest odwiedzany przez użytkownika końcowego. Więcej na temat tego podejścia, w tym korzyści i wyzwań wdrożenia, opisujemy w przewodniku po headless WordPress i Next.js.

Dla firm, które planują długoterminową obecność w wyszukiwarce i chcą uniknąć powtarzalnych, kosztownych poprawek wydajności po każdej aktualizacji wtyczek, wybór odpowiedniej architektury od samego początku bywa tańszy niż seria doraźnych optymalizacji nałożonych na istniejącą, przeciążoną instalację.

Najczęstsze pytania

Czy Core Web Vitals to oficjalny czynnik rankingowy Google?

Tak, są elementem sygnału Page Experience wykorzystywanego przez algorytm wyszukiwarki, choć jakość i trafność treści pozostają czynnikiem nadrzędnym. Dobre wskaźniki nie zastąpią wartościowej treści, ale mogą przeważyć szalę między konkurencyjnymi wynikami o podobnej jakości merytorycznej.

Jak często Google aktualizuje wskaźniki Core Web Vitals?

Zestaw wskaźników i ich progi bywają aktualizowane — tak jak stało się to przy zastąpieniu First Input Delay przez INP. Warto śledzić oficjalne komunikaty Google i regularnie sprawdzać raport w Search Console, by wychwycić zmiany metodologii na czas.

Czy dobre wyniki w Lighthouse gwarantują dobry wynik w Search Console?

Nie zawsze. Lighthouse pokazuje dane laboratoryjne z jednego, kontrolowanego przebiegu testu, a Search Console opiera się na danych terenowych zbieranych od realnych użytkowników na różnych urządzeniach i łączach. Rozbieżności między tymi źródłami są normalne i warto je traktować jako uzupełniające się perspektywy.

Ile czasu zajmuje poprawa Core Web Vitals?

Zależy od skali problemów i architektury strony. Proste poprawki, takie jak optymalizacja obrazów czy odroczenie skryptów, mogą przynieść efekt w ciągu dni. Zmiana fundamentu technologicznego, na przykład przejście na architekturę headless, to projekt liczony w tygodniach, ale daje efekt trwalszy niż punktowe łatanie.

Czy małe strony firmowe też powinny dbać o te wskaźniki?

Tak. Niezależnie od skali ruchu, wolno ładująca się lub „skacząca" strona zniechęca odwiedzających i obniża skuteczność każdej kampanii marketingowej, która kieruje na nią ruch. Dbałość o wydajność to inwestycja, która procentuje przy każdym kolejnym źródle ruchu, nie tylko w wyszukiwarce.

Czy wyniki Core Web Vitals różnią się między urządzeniami mobilnymi a desktopowymi?

Tak, i to zwykle znacząco. Urządzenia mobilne mają mniejszą moc obliczeniową, często wolniejsze łącze, a dodatkowo Google ocenia je z uwzględnieniem realnych warunków sieciowych użytkowników, którzy przeglądają stronę poza zasięgiem szybkiego Wi-Fi. Strona zoptymalizowana pod desktop może więc nadal wymagać dodatkowej pracy nad wersją mobilną, zwłaszcza w zakresie wagi obrazów i ilości uruchamianego kodu JavaScript.

Jeśli chcesz sprawdzić, jak Twoja strona wypada pod kątem LCP, INP i CLS oraz jakie konkretne zmiany przyniosą największą poprawę, zapraszamy do zapoznania się z naszą usługą optymalizacji Core Web Vitals — zaczynamy od audytu, a kończymy na wdrożeniu i weryfikacji wyników.