Core Web Vitals: LCP, INP i CLS - jak sprawdzić i poprawić wyniki

Dobre, średnie i słabe progi LCP, INP oraz CLS

Aby zestaw został uznany za dobry, wszystkie trzy metryki muszą spełniać dobry próg na 75 percentylu. Oznacza to, że co najmniej 75 procent zarejestrowanych doświadczeń mieści się w granicy. Wyniki ocenia się osobno dla telefonu i komputera.

Dane polowe a test laboratoryjny

Dane polowe pochodzą z realnych wizyt użytkowników Chrome, którzy zgodzili się na raportowanie. Są agregowane w Chrome UX Report w okresie 28 dni. Mogą dotyczyć konkretnego URL-a albo całej domeny, jeśli podstrona ma zbyt mało próbek.

Lighthouse uruchamia kontrolowany test na jednej stronie. Pomaga znaleźć zasoby i blokady, ale pojedynczy wynik jest podatny na obciążenie komputera oraz sieci. Używaj go do diagnozy, a danych polowych do oceny rzeczywistego rezultatu. RUM na własnej stronie może dostarczyć jeszcze dokładniejsze dane z podziałem na szablony.

LCP - kiedy pojawia się główna treść

Largest Contentful Paint mierzy czas renderowania największego widocznego obrazu, bloku tekstu lub filmu w pierwszym ekranie. Problemy można podzielić na cztery odcinki: odpowiedź serwera, opóźnienie odkrycia zasobu, czas pobierania i opóźnienie renderowania.

• skróć TTFB przez cache, lepszy hosting i optymalizację backendu
• nie ładuj obrazu LCP przez lazy loading
• dodaj preload lub fetchpriority high, gdy zasób jest odkrywany zbyt późno
• przygotuj właściwy rozmiar WebP lub AVIF
• usuń blokujący CSS i JavaScript
• renderuj najważniejszy tekst w HTML, a nie po wykonaniu skryptu

Najpierw potwierdź, który element jest LCP na badanej podstronie. Inny może być na telefonie, a inny na szerokim ekranie.

INP - jak szybko strona reaguje po kliknięciu

Interaction to Next Paint obserwuje opóźnienie interakcji, czas obsługi zdarzenia i renderowanie następnej klatki. Na stronach z małą liczbą interakcji zwykle raportuje najgorszą lub bliską najgorszej. Wolna reakcja często wynika z długich zadań JavaScript, zbyt rozbudowanego DOM i kosztownego ponownego układania strony.

• usuń nieużywane biblioteki i dziel duże paczki
• odkładaj kod, który nie jest potrzebny do pierwszej interakcji
• dziel długie zadania i oddawaj sterowanie przeglądarce
• ogranicz liczbę elementów oraz złożone selektory
• nie wykonuj ciężkich obliczeń bezpośrednio w obsłudze kliknięcia
• testuj menu, filtry, formularze i koszyk na realnym telefonie

CLS - dlaczego elementy przesuwają się podczas ładowania

Cumulative Layout Shift sumuje nieoczekiwane przesunięcia widocznych elementów. Najczęstsze przyczyny to obrazy bez wymiarów, reklamy bez zarezerwowanego miejsca, późno dołączone komunikaty i font, który znacząco zmienia szerokość tekstu.

Ustaw width i height obrazów albo aspect-ratio kontenera. Rezerwuj miejsce dla iframe, mapy i reklamy. Baner cookies najlepiej wyświetlać jako warstwę, która nie przepycha całej strony. Animuj transform i opacity, a nie właściwości zmieniające układ. Przy fontach wybierz podobne metryki fallbacku i rozsądne font-display.

Jak czytać raport Core Web Vitals w Search Console?

Search Console grupuje podobne URL-e według typu problemu i stanu. Kliknij grupę, sprawdź przykładowe adresy, a następnie zbadaj kilka reprezentantów w PageSpeed Insights. Jedna poprawka w szablonie może rozwiązać problem na setkach stron.

Po wdrożeniu uruchom weryfikację, ale nie oczekuj natychmiastowego efektu. Raport korzysta z danych polowych i musi zebrać nowe doświadczenia. Jeżeli serwis ma mały ruch, dane na poziomie konkretnej strony mogą być niedostępne. Wtedy laboratorium i własny pomiar użytkowników są szczególnie ważne.

Jak ustalić priorytet optymalizacji?

Zacznij od szablonów generujących ruch i konwersje: strona główna, usługi, kategorie, produkt i koszyk. Wybierz problem dotykający największej liczby URL-i i odpowiadający za największą część opóźnienia. Usunięcie jednego skryptu z całego serwisu jest często bardziej wartościowe niż ręczne strojenie pojedynczego poradnika.

Nie rezygnuj z ważnej funkcji tylko dla punktu w teście. Najpierw spróbuj opóźnić jej ładowanie, uprościć kod lub zmienić sposób osadzenia. Szczegółową listę przyczyn zawiera poradnik wolna strona na telefonie.

Core Web Vitals a SEO i konwersja

Google podkreśla, że Core Web Vitals są częścią szerszej oceny doświadczenia, a osiągnięcie dobrych progów nie gwarantuje wysokiej pozycji. Trafniejsza i bardziej pomocna treść może rankować mimo gorszej metryki. Nie oznacza to, że wydajność jest nieważna.

Szybka reakcja, stabilny układ i krótsze oczekiwanie ograniczają frustrację. W sklepie mogą zmniejszać porzucenia, a na stronie usługowej ułatwiają kontakt. Optymalizacja powinna więc łączyć cele techniczne z wynikiem biznesowym i może być elementem audytu SEO.

Kryteria odbioru optymalizacji Core Web Vitals

Przed pracą ustal zestaw reprezentatywnych URL-i i środowisko testowe. Zapisz dane polowe, trzy powtarzalne testy laboratoryjne, element LCP, największe zadania JavaScript i źródła przesunięć. Jedna liczba ze strony głównej nie wystarcza do odbioru zmiany obejmującej cały sklep.

Po wdrożeniu porównaj medianę testów, a nie najlepszy pojedynczy wynik. Sprawdź, czy optymalizacja nie zepsuła analityki, zgód, formularzy, koszyka i dostępności. Usunięcie skryptu może poprawić INP, ale jednocześnie zablokować płatność albo pomiar. Kryterium techniczne musi mieć test funkcjonalny.

Dane polowe oceniaj po zebraniu odpowiedniego okresu. Jeśli strona miała LCP 4,2 s, sensownym pierwszym celem może być zejście poniżej 2,5 s na kluczowym szablonie, a nie wynik 100 w każdej kategorii Lighthouse. Zapisz również budżet wydajności dla nowych obrazów i skryptów, aby kolejne wdrożenie nie cofnęło efektu.