Są strony, które wyglądają nowocześnie, mają dopracowaną warstwę wizualną i świetne treści, a mimo to przegrywają w praktyce. Ładują się zbyt długo, reagują z opóźnieniem albo „skaczą” podczas przewijania. Właściciel firmy widzi estetyczny serwis. Użytkownik widzi irytację. Google widzi słabe Core Web Vitals.
To właśnie dlatego temat Core Web Vitals nie jest techniczną ciekawostką dla programistów, tylko realnym zagadnieniem biznesowym. Te wskaźniki opisują, czy strona szybko pokazuje najważniejszą treść, czy sprawnie reaguje na działania użytkownika i czy układ pozostaje stabilny. A to bezpośrednio wpływa na doświadczenie użytkownika, skuteczność strony internetowej i szanse w wynikach wyszukiwania.
Czym są Core Web Vitals i dlaczego Google traktuje je jako czynnik rankingowy?
Core Web Vitals to zestaw trzech metryk jakości doświadczenia użytkownika: LCP (Largest Contentful Paint), INP (Interaction to Next Paint) i CLS (Cumulative Layout Shift). Google opisuje je jako metryki mierzące rzeczywiste doświadczenie użytkownika w zakresie szybkości ładowania, interaktywności i stabilności wizualnej strony.
Google potwierdza też wprost, że Core Web Vitals są wykorzystywane przez systemy rankingowe. Jednocześnie zaznacza, że nie są jedynym czynnikiem decydującym o pozycji. Mówiąc prościej: dobra treść nadal jest kluczowa, ale kiedy kilka stron odpowiada podobnie dobrze na intencję użytkownika, lepsze doświadczenie strony może pomóc wygrać.
To ważne, bo wiele firm nadal patrzy na wydajność tylko przez pryzmat „wyniku w narzędziu”. Tymczasem Google ocenia doświadczenie bardziej praktycznie: czy użytkownik naprawdę widzi treść szybko, może wejść w interakcję bez frustracji i nie walczy z uciekającym układem strony.
Jak Google ocenia wyniki Core Web Vitals?
Google stosuje trzy progi jakości dla każdej metryki: good, needs improvement i poor. Ocena opiera się na 75. percentylu wszystkich odsłon danej strony lub witryny, co oznacza, że wynik musi być dobry dla zdecydowanej większości użytkowników, a nie tylko w idealnych warunkach testowych.
Praktycznie wygląda to tak:
Dobre wartości Core Web Vitals
- LCP (Largest Contentful Paint): do 2,5 s
- INP (Interaction to Next Paint): do 200 ms
- CLS (Cumulative Layout Shift): do 0,1
Wymagające poprawy
- LCP: od 2,5 s do 4,0 s
- INP: od 200 ms do 500 ms
- CLS: od 0,1 do 0,25
Słabe
- LCP: powyżej 4,0 s
- INP: powyżej 500 ms
- CLS: powyżej 0,25
To oznacza, że jednorazowy szybki test z biura nie wystarczy, żeby uznać temat za zamknięty. Liczy się realne doświadczenie użytkowników na różnych urządzeniach, w różnych lokalizacjach i przy różnych warunkach sieciowych.
LCP (Largest Contentful Paint) – co mierzy i co najczęściej je psuje?
Co mierzy LCP?
LCP (Largest Contentful Paint) mierzy czas renderowania największego obrazu, bloku tekstu albo wideo widocznego w obszarze ekranu od momentu wejścia na stronę. W praktyce jest to zwykle główny baner, duże zdjęcie hero albo nagłówek z treścią otwarcia. To dlatego LCP tak mocno wpływa na pierwsze wrażenie użytkownika.
Google podkreśla też, że LCP w danych rzeczywistych obejmuje nie tylko samo renderowanie elementu, ale również opóźnienia wynikające z czasu odpowiedzi serwera, przekierowań i innych opóźnień TTFB. Dlatego strona może wyglądać dobrze lokalnie, a słabiej wypadać w danych terenowych.
Jakie wartości LCP są dobre, a jakie złe?
Dobry LCP to wynik 2,5 sekundy lub mniej dla co najmniej 75% wizyt. Wynik powyżej 4 sekund jest słaby. Między tymi progami strona wymaga poprawy.
Co najczęściej pogarsza LCP?
Najczęściej LCP psują cztery rzeczy. Po pierwsze: wolny dokument HTML i wysoki TTFB. Drugie: za późne wykrycie zasobu LCP przez przeglądarkę. Po trzecie: zbyt ciężki obraz lub tekst zależny od późno ładowanych fontów. Po czwarte: opóźnienie renderowania, gdy element jest ukrywany lub czeka na JavaScript.
Bardzo częsty błąd to hero wstawione przez JavaScript albo obraz główny osadzony wyłącznie w CSS. W takiej sytuacji przeglądarka odkrywa kluczowy zasób za późno. Chrome rekomenduje, aby zasób LCP był wykrywalny bezpośrednio z HTML, a jeśli to niemożliwe, należy go preloadować i nadać mu wysoki priorytet.
Inny częsty problem to niewłaściwe użycie lazy loadingu. Lazy loading jest dobry dla obrazów poniżej pierwszego ekranu, ale nie dla obrazu odpowiadającego za LCP. Google wprost ostrzega, że obrazu LCP nie należy lazy-loadować, bo powoduje to niepotrzebne opóźnienie pobrania.
Swoje robią też fonty. Jeżeli LCP jest blokiem tekstu, font ładowany zbyt późno może opóźnić pokazanie najważniejszej treści albo wywołać wrażenie pustego ekranu. Web.dev wskazuje, że font requests są odkrywane dopiero po zbudowaniu render tree, dlatego bez preloadu i dobrej konfiguracji potrafią istotnie spowalniać pierwszy render tekstu.
Jak naprawić LCP?
Najpierw trzeba sprawdzić, co faktycznie jest elementem LCP. W PageSpeed Insights i Lighthouse można zobaczyć, który obraz lub blok tekstu został uznany za największy. To ważne, bo firmy bardzo często optymalizują nie ten element, który realnie odpowiada za wynik.
Najskuteczniejsze działania naprawcze są zwykle proste w założeniu:
1. Spraw, aby zasób LCP był odkrywalny od razu
Najlepiej, żeby główny obraz lub treść były obecne w HTML od początku. Chrome rekomenduje SSR zamiast pełnego polegania na CSR oraz preload dla zasobów odkrywanych zbyt późno.
2. Nadaj priorytet głównemu obrazowi
Dla obrazu LCP warto użyć fetchpriority="high" i unikać loading="lazy". To pomaga przeglądarce szybciej rozpocząć pobieranie kluczowego zasobu.
3. Zmniejsz wagę głównego hero
Lżejszy format, lepsza kompresja i rozmiar dopasowany do urządzenia zwykle dają szybki efekt. Web.dev wskazuje, że optymalizacja samego pliku może skrócić ładowanie zasobu, choć ostateczny efekt zależy też od innych części LCP.
4. Ogranicz render-blocking CSS i JavaScript
Jeżeli strona długo czeka, zanim pokaże główny element, problemem mogą być style lub skrypty blokujące renderowanie albo sam fakt, że element LCP trafia do DOM dopiero po wykonaniu kodu.
5. Popraw TTFB
Google wskazuje, że TTFB wpływa na wszystkie późniejsze etapy ładowania. CDN, lepszy hosting, mniej przekierowań i sensowne cache’owanie potrafią poprawić LCP szybciej niż kosmetyczne zmiany frontendowe.
INP (Interaction to Next Paint) – co mierzy i skąd biorą się opóźnienia?
Co mierzy INP?
INP (Interaction to Next Paint) mierzy ogólną responsywność strony wobec interakcji użytkownika. Obserwuje opóźnienie wszystkich kwalifikujących się kliknięć, tapnięć i interakcji klawiaturą podczas całej wizyty, a końcowy wynik odpowiada najdłuższej interakcji, czasem z pominięciem skrajnych odstających przypadków.
To duża zmiana względem dawnego FID. Dziś nie liczy się tylko pierwszy kontakt z interfejsem, ale to, jak strona zachowuje się przez całą sesję. Jeśli formularz, filtr, rozwijane menu lub koszyk reagują z opóźnieniem, INP to pokaże. INP zastąpił FID jako metrykę Core Web Vitals w marcu 2024.
Jakie wartości INP są dobre, a jakie złe?
Dobry INP to 200 ms lub mniej. Wynik między 200 ms a 500 ms oznacza potrzebę poprawy, a wynik powyżej 500 ms jest słaby. Google rekomenduje ocenę na poziomie 75. percentyla osobno dla mobile i desktop.
Co najczęściej psuje INP?
Najczęściej winny jest przeciążony główny wątek przeglądarki. Gdy strona ładuje zbyt dużo JavaScriptu, odpala ciężkie callbacki po kliknięciu albo przebudowuje duże fragmenty DOM, użytkownik naciska przycisk, ale odpowiedź wizualna pojawia się za późno. Web.dev rozbija INP na trzy części: input delay, processing duration i presentation delay. Problem może powstać w każdej z nich.
W praktyce źródła problemu są zwykle powtarzalne: zbyt dużo narzędzi zewnętrznych, ciężkie popupy, chaty, skrypty analityczne, rozbudowane filtry, dynamiczne formularze i długi kod wykonywany natychmiast po interakcji. Dodatkowo duży DOM może spowalniać zarówno pierwszy render, jak i późniejsze aktualizacje po kliknięciach.
Core Web Vitals – Jak naprawić INP?
Najważniejsze jest zrozumienie, że INP rzadko poprawia się jedną zmianą. To zwykle efekt odchudzenia logiki interakcji.
1. Ogranicz JavaScript, który nie jest naprawdę potrzebny
Chrome rekomenduje unikanie niepotrzebnego JavaScriptu. Z perspektywy właściciela strony oznacza to proste pytanie: czy naprawdę potrzebujesz każdego popupu, każdego widgetu i każdego zewnętrznego skryptu na stronie głównej?
2. Rozbij długie zadania
Długie zadania blokują główny wątek. Web.dev wprost zaleca dzielenie ich na mniejsze części, aby przeglądarka mogła szybciej wracać do obsługi użytkownika.
3. Ogranicz pracę wykonywaną po kliknięciu
Jeżeli kliknięcie uruchamia walidację, animację, zmianę widoku, śledzenie i dodatkowe przeliczenia naraz, strona robi za dużo w jednym momencie. Web.dev pokazuje, że input delay, czas przetwarzania i presentation delay sumują się do finalnego opóźnienia interakcji.
4. Zmniejsz złożoność renderowania
Duży DOM, rozbudowane widoki i ciężkie aktualizacje interfejsu zwiększają czas potrzebny na pokazanie nowej klatki po interakcji. Chrome wprost wskazuje, że duży DOM podnosi koszt renderowania i może pogarszać INP.
5. Diagnozuj realne interakcje, nie tylko ładowanie strony
INP najlepiej analizować na podstawie danych terenowych, a dopiero potem odtwarzać problem w warunkach laboratoryjnych. Web.dev rekomenduje rozpoczęcie od field data, bo to one pokazują, która interakcja faktycznie odpowiada za słaby wynik.
CLS (Cumulative Layout Shift) – dlaczego strona „skacze” i jak to zatrzymać?
Co mierzy CLS?
CLS (Cumulative Layout Shift) mierzy największą serię nieoczekiwanych przesunięć elementów w trakcie całego życia strony. Nie chodzi więc tylko o pierwsze sekundy ładowania, ale również o przesunięcia pojawiające się później, na przykład podczas scrollowania, doładowywania treści lub pokazania banera.
Jakie wartości CLS są dobre, a jakie złe?
Dobry CLS to 0,1 lub mniej. Wynik między 0,1 a 0,25 wymaga poprawy. Powyżej 0,25 wynik jest słaby. CLS nie jest podawany w sekundach ani milisekundach, tylko jako wartość bez jednostki.
Co najczęściej powoduje wysoki CLS?
Web.dev wskazuje cztery klasyczne przyczyny: obrazy bez wymiarów, reklamy i iframe’y bez zarezerwowanego miejsca, dynamicznie wstrzykiwaną treść oraz web fonty. To właśnie te elementy najczęściej powodują nagłe „zjazdy” treści pod kursorem użytkownika.
W praktyce do tej listy bardzo często dochodzą bannery cookies, sticky bary promocyjne i formularze wyskakujące z góry lub dołu ekranu. Google rekomenduje, aby dla takich elementów rezerwować miejsce z wyprzedzeniem albo wyświetlać je jako overlay, jeśli to ma sens, zamiast przepychać resztę treści.
Źródłem problemu bywają też animacje. Zmiany właściwości takich jak top i left mogą powodować re-layout, a przez to layout shift. Web.dev zaleca używanie transformacji, które nie wpływają na układ innych elementów w ten sam destrukcyjny sposób.
Jak naprawić CLS?
1. Zawsze ustawiaj rozmiary obrazów i osadzeń
Najprostsza i często najskuteczniejsza naprawa to podanie szerokości i wysokości albo utrzymanie przewidywalnych proporcji. Dzięki temu przeglądarka może zarezerwować miejsce, zanim zasób się pobierze.
2. Rezerwuj miejsce na dynamiczne komponenty
Jeżeli masz reklamę, embed, formularz, banner albo sekcję doładowywaną z opóźnieniem, nie zaczynaj od wysokości 0 px. Web.dev sugeruje użycie placeholdera albo min-height, aby ograniczyć skalę przesunięcia.
3. Nie wstrzykuj nowej treści nad aktualnie czytaną zawartość
Treść pojawiająca się blisko górnej części viewportu zwykle powoduje największy efekt wizualny. Jeżeli nie możesz zarezerwować miejsca, lepiej ładować takie elementy niżej albo po świadomej akcji użytkownika, na przykład po kliknięciu „Pokaż więcej”.
4. Popraw ładowanie fontów
FOIT i FOUT mogą powodować przesunięcia tekstu. Web.dev zaleca preload kluczowych fontów, dobranie sensownego fallbacku, użycie font-display oraz — w bardziej dopracowanych wdrożeniach — narzędzi takich jak size-adjust.
5. Uważaj na zmiany po załadowaniu strony
Jeżeli Lighthouse pokazuje dobry CLS, a CrUX i Search Console słaby, problem może dotyczyć przesunięć po załadowaniu strony. Web.dev wyraźnie zaznacza, że rozbieżności między laboratorium a danymi terenowymi często wynikają właśnie z post-load CLS.
Jak mierzyć Core Web Vitals: Google Search Console, PageSpeed Insights, Lighthouse, CrUX
Google Search Console
Raport Core Web Vitals w Search Console pokazuje dane z rzeczywistego użycia, czyli field data. Grupuje adresy URL według statusu, typu metryki i grup podobnych stron. Trzeba jednak pamiętać, że raport pokazuje próbkę, a nie pełną listę wszystkich adresów, i obejmuje tylko URL-e zaindeksowane.
Dla właściciela firmy to najlepszy punkt startowy do oceny skali problemu. Jeśli w raporcie wiele podstron wpada do kategorii „Poor” lub „Need improvement”, to znak, że problem nie dotyczy jednego przypadku, tylko całego szablonu albo sposobu budowania strony.
PageSpeed Insights
PageSpeed Insights łączy dwa światy: dane terenowe z CrUX oraz dane laboratoryjne z Lighthouse. W górnej części pokazuje, jak stronę widzą realni użytkownicy, a niżej podpowiada, co technicznie można poprawić. To jedno z najpraktyczniejszych narzędzi do pracy nad Core Web Vitals.
Jeżeli dany URL nie ma wystarczającej ilości danych, PSI może pokazać dane na poziomie całego originu. To ważne, bo wynik dla domeny głównej nie zawsze odzwierciedla problem konkretnej podstrony.
Lighthouse
Lighthouse to otwarte, zautomatyzowane narzędzie audytowe do oceny jakości stron, dostępne między innymi w Chrome DevTools. Świetnie nadaje się do diagnozy i testów przed wdrożeniem, ale jest narzędziem laboratoryjnym, więc nie zastępuje danych od realnych użytkowników.
CrUX
CrUX, czyli Chrome UX Report, to publiczny zbiór danych od realnych użytkowników Chrome. Jest oficjalnym datasetem programu Web Vitals i stanowi źródło danych dla wielu narzędzi Google. Nie obejmuje jednak każdej strony — potrzebna jest odpowiednia liczba odwiedzin i publiczna dostępność zasobu.
Co może zrobić właściciel firmy lub manager marketingu bez pisania kodu?
Nie musisz samodzielnie wdrażać fetchpriority, analizować waterfalli i przepisywać frontendu, żeby realnie poprawić Core Web Vitals. Ale możesz bardzo skutecznie ustawić priorytety.
Po pierwsze, pilnuj zasady: najpierw funkcja, potem ozdobniki. Jeśli nowy baner, widget lub animacja nie daje wyraźnej wartości biznesowej, nie warto nim obciążać strony. Wiele problemów z INP i LCP bierze się nie z jednego dużego błędu, tylko z sumy małych dodatków.
Po drugie, wymagaj od wykonawcy raportowania na danych terenowych, a nie tylko „zielonego wyniku” w jednym teście. Search Console, CrUX i PSI pokazują, czy poprawa działa dla użytkowników, a nie tylko w idealnych warunkach laboratoryjnych.
Po trzecie, traktuj wydajność jako część briefu. Jeżeli zespół projektuje nową stronę, landing page albo sekcję kampanii, warto od razu określić ograniczenia: maksymalna liczba skryptów, zasady dla obrazów hero, sposób wdrażania fontów i zakaz wstrzykiwania elementów, które powodują CLS. To prostsze niż naprawianie szkód po publikacji.
Najczęstsze błędy przy poprawie Core Web Vitals
Najczęstszy błąd to skupienie się na jednym wyniku zamiast na realnym doświadczeniu użytkownika. Google wprost zaznacza, że dobre wyniki w raportach nie gwarantują top pozycji, a sama pogoń za perfekcyjnym wynikiem „dla SEO” nie zawsze jest najlepszym wykorzystaniem czasu.
Drugi błąd to ignorowanie różnicy między field data a lab data. Jeśli PageSpeed albo Lighthouse pokazują coś innego niż Search Console, nie oznacza to, że któreś narzędzie „się myli”. Oznacza to zwykle, że użytkownicy doświadczają strony inaczej niż warunki laboratoryjne.
Trzeci błąd to poprawianie skutku zamiast przyczyny. Na przykład CLS często pokazuje elementy, które się przesunęły, ale niekoniecznie one były źródłem problemu. Web.dev podkreśla, że trzeba szukać rzeczywistego powodu, takiego jak nowy blok dodany wyżej, brak miejsca na reklamę albo późno załadowany font.
Core Web Vitals – Podsumowanie
Core Web Vitals to nie trzy techniczne skróty, ale prosty test jakości strony z perspektywy użytkownika. LCP odpowiada na pytanie, czy główna treść pojawia się szybko. INP pokazuje, czy strona reaguje sprawnie na działania użytkownika. CLS mówi, czy interfejs pozostaje stabilny i przewidywalny.
Jeśli chcesz poprawić wyniki, nie zaczynaj od przypadkowych mikrooptymalizacji. Najpierw ustal, która metryka naprawdę boli, potem sprawdź źródło problemu w danych terenowych i dopiero wtedy wdrażaj poprawki. W większości przypadków największy efekt dają: szybsze ładowanie głównego zasobu, mniej zbędnego JavaScriptu, rezerwowanie miejsca dla dynamicznych elementów i rozsądne ładowanie fontów.
Core Web Vitals – FAQ
Czym są Core Web Vitals?
Core Web Vitals to trzy metryki Google mierzące jakość doświadczenia użytkownika: LCP dla ładowania głównej treści, INP dla responsywności interakcji i CLS dla stabilności układu.
Czy Core Web Vitals wpływają na pozycje w Google?
Tak. Google potwierdza, że Core Web Vitals są używane przez jego systemy rankingowe, ale nie są jedynym czynnikiem wpływającym na pozycję strony.
Core Web Vitals – Jaki wynik LCP jest dobry?
Dobry wynik LCP to 2,5 sekundy lub mniej w 75. percentylu odsłon. Powyżej 4 sekund wynik jest słaby.
Core Web Vitals – Jaki wynik INP jest dobry?
Dobry wynik INP to 200 ms lub mniej. Wynik powyżej 500 ms oznacza słabą responsywność strony.
Core Web Vitals – Jaki wynik CLS jest dobry?
Dobry wynik CLS to 0,1 lub mniej. Wynik powyżej 0,25 jest uznawany za słaby.
Co najczęściej pogarsza LCP?
Najczęściej są to: wolny serwer lub wysoki TTFB, zbyt późno wykryty obraz hero, lazy loading obrazu LCP, ciężkie zasoby oraz renderowanie zależne od JavaScriptu lub fontów.
Co najczęściej pogarsza INP?
Najczęściej winne są: zbyt duży JavaScript, długie zadania blokujące główny wątek, ciężkie callbacki po kliknięciu i kosztowne aktualizacje DOM po interakcji.
Co najczęściej powoduje wysoki CLS?
Najczęstsze przyczyny to obrazy bez wymiarów, embedy i iframe’y bez zarezerwowanego miejsca, dynamicznie dodawane elementy oraz fonty powodujące zmianę układu po załadowaniu.
Core Web Vitals – Z którego narzędzia najlepiej korzystać?
Najlepiej łączyć kilka narzędzi: Search Console do oceny problemu w skali serwisu, PageSpeed Insights do analizy konkretnego URL-a, Lighthouse do diagnozy laboratoryjnej i CrUX do zrozumienia danych terenowych.
Czy da się poprawić Core Web Vitals bez przebudowy całej strony?
Tak, bardzo często. Największy efekt dają zwykle: poprawa ładowania zasobu LCP, ograniczenie niepotrzebnych skryptów, rozbijanie długich zadań, ustawienie wymiarów dla obrazów i osadzeń oraz lepsze ładowanie fontów.
