Nie zaliczono Core Web Vitals? Jak poprawić LCP, INP i CLS

Krótka odpowiedź: niezaliczona ocena Core Web Vitals oznacza, że co najmniej jeden z trzech wskaźników przekracza próg u prawdziwych odwiedzających: LCP (ładowanie) powinien wynosić najwyżej 2,5 sekundy, INP (reakcja) najwyżej 200 milisekund, a CLS (stabilność układu) najwyżej 0,1, każdy mierzony na 75. percentylu. Słaby wskaźnik znajdź w danych prawdziwych odwiedzających, a nie w ocenie laboratoryjnej, i napraw najpierw właśnie ten. Google mówi, że jego systemy rankingowe używają Core Web Vitals, ale dobre wartości nie gwarantują miejsca na szczycie.

Co oznacza niezaliczona ocena Core Web Vitals?

Core Web Vitals to ta część inicjatywy Web Vitals od Google, która dotyczy każdej strony internetowej. web.dev wymienia trzy wskaźniki, po jednym na każdy aspekt doświadczenia:

Wartości ocenia się na 75. percentylu wczytań strony, osobno dla telefonów i komputerów. Prostymi słowami: w trzech na cztery wizyty wartość musi być dobra, a telefon i komputer dostają osobny werdykt. Według web.dev narzędzia mają uznać stronę za zaliczoną, jeśli na 75. percentylu spełnia cele dla wszystkich trzech wskaźników. Jeden czerwony wskaźnik wystarcza więc, żeby nie zaliczyć.

Szczegół na granicy: web.dev pisze dla INP i CLS „najwyżej”, a dokumentacja Google o wyszukiwarce pisze „less than 200 milliseconds” i „less than 0.1”, czyli „mniej niż”. Celuj wyraźnie poniżej granicy, a różnica przestanie mieć znaczenie.

Jedna zmiana, o której warto wiedzieć: INP zastąpił First Input Delay (FID) jako Core Web Vital w marcu 2024, jak mówi ogłoszenie na web.dev. Poradnik, który nadal wymienia FID, jest nieaktualny. Wszystkie strony wymienione w tym artykule przeczytaliśmy 4 listopada 2026; przegląd na web.dev był ostatnio aktualizowany 31 października 2024.

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

Według Google tak, ale bez podania wagi. Strona Google o doświadczeniu ze strony mówi: „Core Web Vitals are used by our ranking systems.” Zaleca dobre wartości dla sukcesu w wyszukiwarce i dodaje, że nie ma jednego sygnału doświadczenia ze strony.

Ta sama strona równie wyraźnie opisuje granice. Dobre wyniki w raporcie Core Web Vitals w Search Console lub w narzędziach zewnętrznych „doesn't guarantee that your pages will rank at the top of Google Search results”. Pisze też, że pogoń za idealnym wynikiem wyłącznie dla SEO może nie być najlepszym wykorzystaniem czasu. Google zawsze stara się pokazywać najtrafniejszą treść, nawet gdy doświadczenie ze strony jest słabe.

Jak dużą wagę mają te wskaźniki, Google nie publikuje, więc my też nie podajemy żadnej liczby. Nasza interpretacja, a nie informacja od Google: traktuj progi jako poprzeczkę jakości dla swoich odwiedzających, doprowadź wszystkie trzy wskaźniki do „dobrych”, a potem wróć z czasem do treści. Główne systemy rankingowe Google oceniają treść zwykle strona po stronie, więc sprawdź każdy ważny typ strony.

Dane laboratoryjne czy terenowe: które liczą się w Core Web Vitals?

Ocena opiera się na danych terenowych, czyli pomiarach prawdziwych wizyt. Zbiera je Chrome User Experience Report (CrUX) od prawdziwych użytkowników Chrome; pokazują je PageSpeed Insights i raport Core Web Vitals w Search Console. Według web.dev raport CrUX obejmuje okres 28 dni.

Dane laboratoryjne powstają z jednorazowego wczytania strony w kontrolowanych warunkach: jedno urządzenie, jedna sieć, jedna lokalizacja. To idealne do szukania przyczyn i testowania poprawki przed publikacją, ale poradnik o LCP ostrzega: „lab tests alone may not be entirely representative”. Gdy jedne i drugie się rozchodzą, ten sam poradnik o LCP radzi skupić się najpierw na danych prawdziwych użytkowników. Różnią się z dobrych powodów:

• Element LCP może być inny. Przebieg laboratoryjny zawsze znajduje ten sam element. Prawdziwe wizyty mają inne rozmiary ekranów, treści dla zalogowanych albo testy A/B.
• INP potrzebuje prawdziwych ludzi. Lighthouse i inne narzędzia laboratoryjne wczytują stronę bez klikania, więc nie zmierzą INP. Total Blocking Time (TBT) to jego zastępnik w laboratorium; poprawa TBT może poprawić INP.
• CLS liczy się także po wczytaniu. Przebiegi laboratoryjne widzą głównie samo wczytywanie. W terenie układ może przesunąć również treść, która pojawia się podczas przewijania.
• Cache pomaga prawdziwym odwiedzającym. Testy laboratoryjne zwykle zaczynają z pustą pamięcią podręczną, a wracający odwiedzający i pamięć podręczna wstecz/dalej (bfcache) ładują strony szybciej.

Jak odczytać swoje liczby w czterech krokach:

1. Uruchom swój adres w PageSpeed Insights. Sekcja „Discover what your real users are experiencing” zawiera dane terenowe, a „Diagnose performance issues” przebieg laboratoryjny (nazwy z angielskiego interfejsu).
2. Sprawdź, na co patrzysz. Przełączaj się między telefonem a komputerem oraz między pojedynczym adresem a całą witryną (origin). Jeśli adres ma zbyt mało danych, PageSpeed Insights pokazuje zamiast nich dane całej witryny.
3. Znajdź wskaźnik ponad granicą na 75. percentylu. To twój słaby wskaźnik. Przy zbyt małym ruchu danych terenowych nie ma; użyj wtedy wartości laboratoryjnych i mierz własnych odwiedzających małą biblioteką web-vitals z web.dev.
4. Otwórz diagnostykę laboratoryjną dla tego wskaźnika, zobacz przyczynę i napraw najpierw tę jedną rzecz.

Jak poprawić LCP: największy element pojawia się za późno

LCP zgłasza, kiedy zostaje wyrenderowany największy obraz, blok tekstu lub film w widocznym obszarze. Poradnik web.dev o LCP dzieli czas na cztery części, które razem dają LCP: odpowiedź serwera (TTFB), opóźnienie, zanim przeglądarka zacznie ładować zasób LCP, czas ładowania tego zasobu oraz opóźnienie do wyrenderowania elementu. Znajdź największą część, zanim cokolwiek zmienisz: skrócenie jednej części może po prostu przenieść czas do innej. Mocniej skompresowany obraz nie pomoże, jeśli element i tak pozostaje ukryty, dopóki nie wczyta się skrypt.

Lista najskuteczniejszych poprawek od zespołu Chrome zawiera między innymi te:

1. Spraw, by obraz LCP był łatwy do znalezienia, i nadaj mu priorytet. Użyj zwykłego <img> z src lub srcset, a nie data-src, który wymaga JavaScriptu. Lepiej renderuj stronę po stronie serwera, niż buduj ją dopiero w przeglądarce. Dodaj fetchpriority="high" i usuń loading="lazy" z tego jednego obrazu.
2. Skróć odpowiedź serwera. Serwuj i buforuj treść blisko odwiedzających, zwykle przez CDN.

Ten sam znacznik obsługuje LCP i, przez podany rozmiar, także CLS:

<!-- Główny obraz: w HTML, wysoki priorytet, bez lazy, z rozmiarem -->
<img src="/img/hero.webp" width="1200" height="630" alt="Krótki opis" fetchpriority="high">

<!-- Obrazy niżej na stronie: lazy loading jest tu w porządku -->
<img src="/img/team.webp" width="600" height="400" alt="Krótki opis" loading="lazy">

Jak poprawić INP: strona reaguje zbyt wolno

INP obserwuje każde kliknięcie, dotknięcie i naciśnięcie klawisza podczas wizyty i zgłasza mniej więcej najwolniejsze z nich (przy stronach z bardzo wieloma interakcjami wartości odstające są pomijane). Najechanie kursorem i przewijanie się nie liczą. Według poradnika o INP każda interakcja ma trzy części: opóźnienie wejścia, czas działania procedur obsługi zdarzeń oraz opóźnienie do pokazania następnej klatki. Zwykle winny jest JavaScript, który zajmuje główny wątek. Najważniejsze poprawki zespołu Chrome:

1. Dziel długie zadania. Zadanie dłuższe niż 50 milisekund blokuje główny wątek. Oddawaj kontrolę często: przez scheduler.yield() tam, gdzie przeglądarka go obsługuje, a starszym sposobem przez setTimeout.
2. Wysyłaj mniej JavaScriptu. Znajdź nieużywany kod narzędziem Coverage w Chrome DevTools, podziel kod, który na początku nie jest potrzebny, i posprzątaj stare tagi w menedżerze tagów.
3. Unikaj dużych aktualizacji renderowania. Trzymaj DOM małym, unikaj wymuszonego layoutu i używaj CSS containment dla treści poza ekranem.

Jak poprawić CLS: układ skacze

CLS nie ma jednostki. Łączy to, jak dużo widocznej treści się przesunęło, z tym, jak daleko. W terenie liczy się przez całą wizytę, ale przesunięcia w ciągu 500 milisekund od interakcji użytkownika są pomijane. Poradnik web.dev o CLS wymienia typowe przyczyny: obrazy bez wymiarów, reklamy, osadzenia i ramki iframe bez wymiarów, treść wstrzykiwana dynamicznie oraz czcionki internetowe. Co pomaga:

• Zarezerwuj miejsce. Nadaj obrazom i filmom width i height albo użyj właściwości CSS aspect-ratio. Dla treści o nieznanym rozmiarze sensowna wartość min-height jest lepsza niż domyślne zero.
• Animuj przez transform. Animowanie top, left lub margin przesuwa układ. Typowy przypadek to wsuwające się banery cookies.
• Pozwól działać pamięci podręcznej wstecz/dalej. Przywraca w pełni wyrenderowane strony. Częste blokady to dyrektywy cache no-store i nasłuchiwacze zdarzenia unload.
• Okiełznaj czcionki internetowe. font-display: optional, dopasowane czcionki zastępcze z size-adjust i wczytywanie z wyprzedzeniem ważnych czcionek zmniejszają skoki związane z czcionkami.

Jak SEOgrinder sprawdza Core Web Vitals

SEOgrinder to nasze narzędzie, które budujemy. Wpisz publiczny adres w SEOgrinder, a wartości szybkości pochodzą z Google PageSpeed Insights, dla telefonów i dla komputerów. Karta „Core Web Vitals” pokazuje LCP i CLS z laboratoryjnego przebiegu Lighthouse oraz INP od prawdziwych odwiedzających, a osobne pole pokazuje dane prawdziwych użytkowników z ostatnich 28 dni. Jeśli Google ma za mało danych o stronie, raport mówi to wprost zamiast zgadywać. Zadania takie jak „Prawdziwi użytkownicy na telefonie czekają … na treść” podają wskaźnik, wartość i rozwiązanie. Wolna odpowiedź serwera, która wchodzi w LCP, dostaje własne zadanie.

Ograniczenia: SEOgrinder czyta liczby Google i nie zastępuje własnego monitoringu prawdziwych użytkowników. Nie mierzy pozycji. Jeśli dzienny limit Google na pomiar szybkości jest wyczerpany, raport powstaje bez niego.

Najczęstsze błędy

• Ufanie samej ocenie laboratoryjnej. Nie zmierzy INP i może wyglądać inaczej niż to, czego doświadczają odwiedzający. Zacznij od wartości prawdziwych odwiedzających.
• Sprawdzanie tylko jednego urządzenia. Telefon i komputer są oceniane osobno.
• Lazy loading głównego obrazu. loading="lazy" na obrazie LCP dodaje opóźnienie.
• Pomijanie wymiarów obrazów. Bez width i height przeglądarka nie może zarezerwować miejsca.
• Poprawianie złej części LCP. Kompresuj obrazy dopiero wtedy, gdy podział pokaże, że problemem jest czas ładowania.
• Oczekiwanie natychmiastowego wyniku. Dane terenowe obejmują 28 dni, więc zmieniają się stopniowo. Po poprawce od razu sprawdź przebieg laboratoryjny, a wartości prawdziwych odwiedzających w kolejnych tygodniach.

Najczęstsze pytania

Jaki jest dobry wynik Core Web Vitals?

Nie ma jednej oceny. Strona zalicza, gdy na 75. percentylu LCP wynosi najwyżej 2,5 sekundy, INP najwyżej 200 milisekund, a CLS najwyżej 0,1. Liczba od 0 do 100, którą możesz znać z Lighthouse, to wartość laboratoryjna i coś innego.

Dlaczego PageSpeed Insights nie pokazuje danych prawdziwych użytkowników mojej witryny?

Zwykle jest zbyt mało wizyt, by CrUX mógł cokolwiek zgłosić. web.dev radzi w takim przypadku dodać własny pomiar prawdziwych odwiedzających. Do tego czasu pracuj na wartościach laboratoryjnych.

Czy potrzebuję idealnego wyniku?

Nie. Celem jest zaliczenie. Sam Google pisze, że pogoń za idealnym wynikiem wyłącznie ze względów SEO może nie być najlepszym wykorzystaniem czasu.

Twój następny krok

Przepuść swoją najważniejszą stronę przez SEOgrinder, otwórz kartę „Core Web Vitals” i najpierw spójrz na wartości prawdziwych odwiedzających. Napraw ten jeden wskaźnik, który nie przechodzi, kliknij Sprawdź ponownie i przeczytaj wartości laboratoryjne. Szerszy obraz znajdziesz w naszej checkliście SEO.

Zobacz także

• Jak wypozycjonować stronę w Google: 3 zalecenia samego Google
• Linkowanie wewnętrzne: jak znaleźć strony osierocone i je podlinkować
• Dane strukturalne JSON-LD: 2 przykłady do skopiowania i testu