Core Web Vitals w Google Search Console – poradnik dla początkujących

Raport Core Web Vitals może pokazać, że użytkownicy długo czekają na załadowanie strony lub jej reakcję na kliknięcie albo że treść przesuwa się w trakcie korzystania ze strony. Sam raport nie wskaże jednak konkretnego wiersza kodu, który spowodował problem. W praktyce warto korzystać z raportu Core Web Vitals w Google Search Console do monitorowania witryny i ustalania kolejności prac, a konkretnych przyczyn szukać za pomocą PageSpeed Insights, Chrome DevTools i innych narzędzi diagnostycznych dla programistów.

Jeśli dopiero poznajesz Search Console, zacznij od pełnego poradnika Google Search Console dla początkujących. Poznasz w nim główne raporty platformy i dowiesz się, jak uwzględnić Core Web Vitals w codziennej pracy nad SEO.

Czym są Core Web Vitals?

Core Web Vitals to podstawowe wskaźniki internetowe. Mierzą trzy aspekty korzystania ze strony w rzeczywistych warunkach: szybkość ładowania, szybkość reakcji na działania użytkownika i stabilność wizualną. Obecnie są to Largest Contentful Paint, Interaction to Next Paint i Cumulative Layout Shift, w skrócie LCP, INP i CLS.

Raport „Podstawowe wskaźniki internetowe” w Google Search Console korzysta z zanonimizowanych danych rzeczywistych pochodzących z Chrome User Experience Report, znanego również jako CrUX. Źródłem tych danych są faktyczne wizyty na stronach, a nie pojedyncza symulacja. Można więc sprawdzić, jak strona działała podczas różnych wizyt użytkowników objętych pomiarem, z uwzględnieniem różnic między urządzeniami, połączeniami sieciowymi i lokalizacjami.

Dobry wynik Core Web Vitals ma znaczenie zarówno dla wygody użytkowników, jak i dla widoczności w wyszukiwarce. Nie da się jednak na jego podstawie wyliczyć pozycji strony. Systemy rankingowe Google uwzględniają wiele sygnałów, a osiągnięcie zalecanych wartości wszystkich trzech wskaźników nie gwarantuje awansu w wynikach wyszukiwania.

Co mierzą LCP, INP i CLS?

LCP mierzy szybkość ładowania

Largest Contentful Paint mierzy czas potrzebny do wyświetlenia największego obrazu, obrazu podglądu filmu lub bloku tekstu w części strony widocznej zaraz po jej otwarciu. W praktyce wskaźnik odpowiada na pytanie, kiedy odwiedzający zobaczy główną treść i będzie mógł z niej skorzystać.

LCP wynoszący 2,5 sekundy lub mniej otrzymuje stan „Dobrej jakości”. Wynik powyżej 2,5 sekundy do 4 sekund włącznie oznacza stan „Wymagana poprawa”, a powyżej 4 sekund — „Słabej jakości”. Do oceny stosuje się 75. percentyl. Oznacza to, że zalecany próg powinien być spełniony podczas co najmniej 75% zmierzonych wizyt.

INP mierzy szybkość reakcji strony

Interaction to Next Paint określa, jak szybko użytkownik zobaczy reakcję strony na takie działania jak kliknięcie, dotknięcie ekranu czy naciśnięcie klawisza. Wskaźnik uwzględnia interakcje z całej wizyty i po odrzuceniu niektórych wartości odstających wskazuje reprezentatywną interakcję o dużym opóźnieniu.

INP wynoszący 200 milisekund lub mniej otrzymuje stan „Dobrej jakości”. Wynik powyżej 200 milisekund do 500 milisekund włącznie oznacza stan „Wymagana poprawa”, a powyżej 500 milisekund — „Słabej jakości”. Wysoki INP często oznacza, że wykonywanie kodu JavaScript, renderowanie lub inne długotrwałe zadania opóźniają reakcję przeglądarki.

CLS mierzy stabilność wizualną

Cumulative Layout Shift mierzy nieoczekiwane przesunięcia widocznych elementów strony. Typowy przykład to przycisk, który przesuwa się właśnie wtedy, gdy użytkownik próbuje go dotknąć, ponieważ nad nim załadował się obraz, reklama, baner lub inny element.

CLS wynoszący 0,1 lub mniej otrzymuje stan „Dobrej jakości”. Wynik powyżej 0,1 do 0,25 włącznie oznacza stan „Wymagana poprawa”, a powyżej 0,25 — „Słabej jakości”. LCP i INP wyraża się w jednostkach czasu, natomiast CLS jest wskaźnikiem bez jednostki.

Jak otworzyć raport „Podstawowe wskaźniki internetowe”

Aby przeglądać raporty witryny w Search Console, musisz mieć dostęp do zweryfikowanej usługi. Gdy uzyskasz dostęp, wykonaj poniższe kroki.

1. Zaloguj się do Google Search Console.
2. Wybierz usługę odpowiadającą witrynie, którą chcesz sprawdzić.
3. W menu nawigacyjnym wybierz Podstawowe wskaźniki internetowe.
4. Przejrzyj osobne podsumowania dla urządzeń mobilnych i komputerów.
5. Przy typie urządzenia, który chcesz sprawdzić, wybierz Otwórz raport.
6. Wybierz stan lub wiersz z opisem problemu, aby zobaczyć grupy adresów URL, których dotyczy, oraz przykładowe adresy.

Widok ogólny pomaga zauważyć prawidłowości w skali witryny. Nie służy do sprawdzania dowolnej strony z osobna. Liczba adresów URL w raporcie może być mniejsza niż łączna liczba stron w witrynie.

Grupy adresów URL o stanach „Dobrej jakości”, „Wymagana poprawa” i „Słabej jakości”

Search Console przypisuje każdej grupie adresów URL objętej pomiarem jeden z trzech stanów. Znajomość tych oznaczeń pomaga ocenić, które ostrzeżenia wymagają pilniejszej reakcji.

• Dobrej jakości — grupa spełnia zalecane progi LCP, INP i CLS.
• Wymagana poprawa — co najmniej jeden wskaźnik mieści się w przedziale między progami stanów „Dobrej jakości” i „Słabej jakości”.
• Słabej jakości — co najmniej jeden wskaźnik przekracza próg, powyżej którego otrzymuje stan „Słabej jakości”.

O ogólnym stanie grupy decyduje najsłabszy ze wskaźników uwzględnionych w ocenie. Jeśli LCP i INP grupy mają stan „Dobrej jakości”, ale CLS ma stan „Słabej jakości”, cała grupa otrzymuje stan „Słabej jakości”. Wyniki dla urządzeń mobilnych i komputerów ocenia się osobno.

Gdy ustalasz kolejność prac nad adresami URL o stanie „Słabej jakości” w Google Search Console, zacznij od problemów, które dotyczą ważnych stron lub dużych grup. Problemy o stanie „Słabej jakości” zwykle są pilniejsze od tych ze stanem „Wymagana poprawa”, ale liczy się też wpływ na firmę. Usterka w kluczowym szablonie strony produktu, strony do pozyskiwania kontaktów sprzedażowych lub strony finalizacji zamówienia może być pilniejsza niż problem obejmujący więcej stron o małym znaczeniu dla firmy.

Raporty dla urządzeń mobilnych i komputerów

Użytkownicy urządzeń mobilnych i komputerów korzystają z różnego sprzętu, różnych połączeń sieciowych i różnych sposobów obsługi strony. Różni się też rozmiar widocznego obszaru strony. Dlatego Search Console tworzy osobne raporty dla obu typów urządzeń. Ta sama grupa adresów URL może mieć stan „Dobrej jakości” na komputerach, a „Słabej jakości” na urządzeniach mobilnych. Oba wyniki mogą być prawidłowe.

Dobry wynik na komputerach nie równoważy słabego wyniku na urządzeniach mobilnych. Otwórz oba raporty. Dla każdego typu urządzenia osobno sprawdź, których wskaźników i grup adresów URL dotyczy problem oraz jak wyniki zmieniają się w czasie. Jeśli większość klientów korzysta z urządzeń mobilnych, zespół programistów może w pierwszej kolejności zająć się problemami na tych urządzeniach. Przy podejmowaniu decyzji uwzględnij dane o odbiorcach i działalności firmy, zamiast kierować się wyłącznie oceną w raporcie.

Brak raportu dla danego typu urządzenia nie oznacza, że strony uzyskały dobrą ocenę. Może po prostu oznaczać, że CrUX ma za mało danych z wizyt na takich urządzeniach, które spełniają kryteria uwzględnienia w raporcie, aby podać miarodajny wynik.

Dlaczego Google Search Console grupuje podobne adresy URL?

Search Console łączy w grupy adresy URL stron, które wydają się działać podobnie z perspektywy użytkownika i mogą mieć wspólną konstrukcję. Takie grupowanie jest przydatne, ponieważ źródłem problemów z wydajnością często są szablony, komponenty, skrypty lub reguły obsługi multimediów używane na wielu stronach.

Jeśli na przykład wiele stron produktów korzysta z tego samego komponentu, który wyświetla zbyt duży obraz główny, wszystkie mogą mieć problem z LCP. Jeśli na każdej stronie kategorii baner jest wstawiany bez wcześniejszego zarezerwowania miejsca, wspólnym problemem może być CLS. Poprawienie wspólnego komponentu daje większą szansę na poprawę wyniku całej grupy niż wprowadzanie zmian po kolei na stronach podanych jako przykłady.

Adres URL widoczny w tabeli problemów jest reprezentatywnym przykładem. Ten sam problem może dotyczyć również innych stron. Poszczególne strony mogą osiągać wyniki lepsze lub gorsze niż wartość podana dla całej grupy. Jeśli dla danej grupy jest za mało danych, Search Console może wykorzystać dane zbiorcze na poziomie źródła (origin).

Jak ustalić przyczynę problemu z Core Web Vitals

Najpierw ustal, jaki problem widać w danych z rzeczywistych wizyt, a następnie zbadaj jego techniczną przyczynę. Grupa stron wskazana w Search Console podpowiada, od czego zacząć poszukiwania. Sama w sobie nie stanowi diagnozy.

1. Wybierz raport dla odpowiedniego typu urządzenia. Sprawdź, czy problem dotyczy urządzeń mobilnych, komputerów czy obu typów urządzeń.
2. Ustal, który wskaźnik nie spełnia wymagań. Sprawdź, czy problem dotyczy ładowania, szybkości reakcji czy stabilności układu strony.
3. Przejrzyj grupę adresów URL. Poszukaj elementów wspólnych, takich jak szablon, typ strony, komponent multimedialny, skrypt, baner lub funkcja dostarczana przez zewnętrzną firmę.
4. Wybierz reprezentatywne przykłady. Przetestuj kilka stron, aby jeden nietypowy adres URL nie wypaczył wniosków.
5. Uruchom PageSpeed Insights. Porównaj dostępne dane z rzeczywistych wizyt z wynikami diagnostyki Lighthouse przeprowadzonej w kontrolowanych warunkach.
6. Odtwórz problem. Skorzystaj z Chrome DevTools i wykonaj czynności typowe dla użytkowników. Jest to szczególnie ważne przy problemach z INP oraz z przesunięciami układu (CLS), które występują po załadowaniu strony.
7. Wprowadź poprawkę w szablonie. Jeśli wyniki testów wskazują, że problem obejmuje grupę stron, usuń jego wspólną przyczynę.
8. Przeprowadź testy przed wdrożeniem. Sprawdź strony objęte problemem na ekranach o odpowiednich rozmiarach. Przetestuj najważniejsze czynności, które wykonują na nich użytkownicy.

Jeśli chcesz sprawdzić, jakie informacje o stronie znajdują się w indeksie Google, który adres Google wybrał jako kanoniczny lub czy Google ma dostęp do konkretnej strony, możesz sprawdzić adres URL objęty problemem. Funkcja „Sprawdzanie adresu URL” nie służy jednak do ustalania przyczyn problemów z Core Web Vitals i nie zastępuje diagnostyki wydajności.

Google Search Console a PageSpeed Insights

Search Console i PageSpeed Insights odpowiadają na powiązane, ale różne pytania. Search Console pozwala zapytać: „W których częściach witryny użytkownicy od dłuższego czasu napotykają problemy?” PageSpeed Insights pomaga odpowiedzieć na pytanie: „Jakie dane z rzeczywistych wizyt i testów laboratoryjnych są dostępne dla tej strony i co może wyjaśniać jej wyniki?”

Search Console zestawia dane z rzeczywistych wizyt dla grup podobnych adresów URL. PageSpeed Insights zazwyczaj analizuje pojedynczy adres URL i może wyświetlać zarówno dane rzeczywiste z CrUX, jak i dane laboratoryjne z Lighthouse. Dane rzeczywiste odzwierciedlają wizyty z okresu, który przesuwa się wraz z upływem czasu. Dane laboratoryjne pochodzą z testu w kontrolowanych warunkach, co pozwala powtarzać pomiary podczas diagnozowania problemu.

Wyniki nie zawsze się pokrywają. Testowana strona może odbiegać od pozostałych stron w swojej grupie w Search Console, a warunki testu Lighthouse mogą różnić się od tych, w których użytkownicy odwiedzają witrynę. Nawet dobry wynik laboratoryjny nie usuwa od razu z raportu danych z wcześniejszych wizyt.

Za pomocą Search Console ustal zasięg problemu i pilność jego rozwiązania. Korzystaj z PageSpeed Insights i narzędzi programistycznych, aby wskazać prawdopodobne przyczyny, przetestować zmiany i porównać wyniki w kontrolowanych warunkach.

Typowe sposoby poprawy LCP, INP i CLS

Nie ma jednej poprawki, która rozwiązuje wszystkie problemy z Core Web Vitals. Wybór zmiany zależy od wskaźnika, budowy strony i wyników testów. Poniższe działania to typowe punkty wyjścia do pracy. Żadne z nich nie gwarantuje rozwiązania problemu.

Jak poprawić LCP

Aby poprawić LCP, zwykle trzeba ustalić, który element jest mierzony, i prześledzić wszystkie etapy prowadzące do jego wyświetlenia. Na wynik mogą wpływać opóźnienia serwera, późne wykrycie zasobu przez przeglądarkę, powolne pobieranie, zasoby blokujące renderowanie oraz zadania wykonywane w głównym wątku przeglądarki.

• Skróć czas odpowiedzi serwera i odpowiednio skonfiguruj pamięć podręczną.
• Skompresuj ważne obrazy i dostosuj ich wymiary do rozmiaru, w jakim są wyświetlane.
• Używaj nowoczesnych formatów obrazów, gdy są odpowiednie dla danej treści.
• Umieść odwołanie do zasobu LCP w początkowym kodzie HTML, aby przeglądarka mogła go wcześnie wykryć.
• Jeśli obraz LCP widać bez przewijania strony, unikaj niepotrzebnego opóźniania jego ładowania (lazy loading).
• Ogranicz ilość kodu CSS blokującego renderowanie oraz liczbę skryptów wykonywanych synchronicznie.
• Usuń zbędne przekierowania występujące podczas ładowania strony.
• Skorzystaj z sieci dostarczania treści (CDN), jeśli odległość między serwerem a użytkownikami znacznie spowalnia dostarczanie zasobów.

Nie obniżaj jakości obrazów bez sprawdzenia przyczyny problemu i nie włączaj wstępnego ładowania każdego dużego zasobu. Przy nadmiernym korzystaniu z tej funkcji zasoby konkurują o dostępną przepustowość łącza. Nadaj pierwszeństwo zasobowi, od którego faktycznie zależy wyświetlenie największego widocznego elementu strony.

Jak poprawić INP

Problemy z INP często występują, gdy w chwili interakcji użytkownika ze stroną główny wątek przeglądarki jest zajęty. Aby poprawić wynik, ustal, na którą czynność strona reaguje zbyt wolno. Osobno sprawdź, ile trwa oczekiwanie na rozpoczęcie obsługi zdarzenia, samo jego przetwarzanie oraz oczekiwanie na wyświetlenie efektu.

• Ogranicz wykonywanie zbędnego kodu JavaScript.
• Podziel długotrwałe zadania na mniejsze części.
• Zadbaj, aby funkcje obsługujące zdarzenia działały sprawnie i wykonywały tylko potrzebne operacje.
• Odłóż uruchamianie skryptów, które nie są od razu potrzebne, do chwili, gdy będą używane.
• Sprawdź widżety, tagi i kody śledzące od zewnętrznych dostawców.
• Ogranicz pracę, którą przeglądarka musi wykonać, aby wyświetlić zmiany po interakcji.
• Testuj interakcje również w trakcie ładowania strony.
• Jeśli nie udaje się odtworzyć problemu w testach laboratoryjnych, rozważ monitorowanie wydajności podczas rzeczywistych wizyt.

INP obejmuje więcej niż początkowe ładowanie strony. Podczas całej wizyty odzwierciedlającej rzeczywiste zachowania użytkownika testuj menu, filtry, formularze, elementy wyboru produktu, wyszukiwarki i inne elementy sterujące.

Jak poprawić CLS

Poprawa CLS polega przede wszystkim na rezerwowaniu miejsca na elementy strony i zapobieganiu ich nieoczekiwanym przesunięciom. Częste przyczyny problemów to obrazy bez określonych wymiarów, dynamicznie osadzane elementy, reklamy, treści dodawane w trakcie wyświetlania strony oraz zmiany układu związane z czcionkami.

• Określ szerokość i wysokość obrazów oraz filmów.
• Zarezerwuj stałe miejsce na reklamy, osadzane treści i ramki iframe.
• Unikaj wstawiania nowej treści nad już wyświetloną, jeśli użytkownik nie zainicjował takiej zmiany.
• Zarezerwuj miejsce za pomocą elementów zastępczych dla komponentów ładowanych asynchronicznie.
• Sprawdź komunikaty o plikach cookie, banery promocyjne oraz elementy służące do wyrażania zgody.
• Skonfiguruj czcionki internetowe tak, aby ich załadowanie w jak najmniejszym stopniu zmieniało układ już widocznego tekstu.
• Przetestuj przewijanie, nawigację, filtrowanie i inne czynności wykonywane po załadowaniu strony.

W krótkim teście ładowania układ strony może wydawać się stabilny, a później jej elementy mogą się przesunąć, gdy użytkownik przewinie stronę lub wykona inną czynność. Przetestuj cały przebieg wizyty, łącznie z tym, co dzieje się po wyświetleniu pierwszego ekranu.

Jak zweryfikować poprawkę dotyczącą Core Web Vitals

Rozpocznij weryfikację dopiero po usunięciu danego problemu w całej grupie stron, których dotyczył. Jeśli przyczyną był wspólny szablon lub komponent, przed włączeniem monitorowania w Search Console upewnij się, że poprawiona wersja działa już pod wszystkimi adresami URL, których dotyczy zmiana.

1. Przetestuj reprezentatywne strony za pomocą PageSpeed Insights i narzędzi programistycznych.
2. Sprawdź działanie na urządzeniach mobilnych i komputerach, jeśli zmiana dotyczy obu typów urządzeń.
3. Potwierdź, że nie da się już odtworzyć usterki technicznej, która pierwotnie powodowała problem.
4. Wdróż zmianę na wszystkich stronach objętych problemem.
5. Otwórz szczegóły problemu w raporcie „Podstawowe wskaźniki internetowe” w Search Console.
6. Wybierz Rozpocznij śledzenie, aby zacząć monitorować problem.
7. Sprawdź stan weryfikacji i przeanalizuj przykładowe adresy, pod którymi nadal występuje problem.

Search Console monitoruje dane z rzeczywistych wizyt przez 28 dni, aby ocenić, czy problem nadal występuje. Rozpoczęcie śledzenia nie powoduje wysłania prośby o zindeksowanie, uruchomienia natychmiastowego testu szybkości ani wymuszenia ponownego skanowania stron przez Google. Uruchamia monitorowanie na podstawie napływających danych CrUX.

Dane z rzeczywistych wizyt są zbiorcze i obejmują również wcześniejsze wizyty. Dlatego od wdrożenia skutecznej poprawki do pojawienia się lepszego wyniku w raporcie może minąć trochę czasu. Krótki czas reakcji lub ładowania w teście laboratoryjnym to obiecujący sygnał. Pełna weryfikacja wymaga jeszcze danych z rzeczywistych wizyt.

Ograniczenia raportu „Podstawowe wskaźniki internetowe”

Raport jest przydatny, jeśli rozumiesz, jakie dane obejmuje. Traktowanie go jako pełnego audytu wydajności może prowadzić do błędnych wniosków.

• Raport nie obejmuje wszystkich adresów URL witryny.
• W raporcie mogą pojawić się tylko zindeksowane adresy URL.
• W przypadku rzadko odwiedzanych stron danych z rzeczywistych wizyt może być za mało.
• Przykładowe adresy URL reprezentują całe grupy. Raport nie podaje osobnej diagnozy dla każdej takiej strony.
• Dane zbiorcze mogą ukrywać różnice między poszczególnymi stronami oraz między doświadczeniami użytkowników.
• Raport wskazuje, których wskaźników dotyczy problem, ale nie wyjaśnia wszystkich jego technicznych przyczyn.
• Poprawa jest widoczna z opóźnieniem, ponieważ okres, z którego pochodzą dane, przesuwa się z każdym dniem.
• Stan „Dobrej jakości” nie oznacza, że strona działa szybko u każdego użytkownika.
• Spełnienie wymagań Core Web Vitals nie gwarantuje wyższej pozycji w wynikach wyszukiwania.

Search Console przypisuje dane z rzeczywistych wizyt do adresu URL, który użytkownicy faktycznie odwiedzili. Nie zawsze więc łączy je pod adresem kanonicznym. W rezultacie raport wydajności może nie pokrywać się dokładnie z raportami, które grupują informacje według stron wybranych przez Google jako kanoniczne.

Najważniejsze wnioski

Raport najlepiej sprawdza się jako element regularnego monitorowania witryny i diagnozowania problemów. Korzystając z niego, pamiętaj o poniższych zasadach.

• LCP, INP i CLS mierzą odpowiednio szybkość ładowania, szybkość reakcji i stabilność wizualną.
• Search Console opiera się na danych z rzeczywistych wizyt użytkowników. Wynik nie pochodzi z pojedynczego testu wydajności wykonywanego na bieżąco.
• Brak danych nie oznacza, że strona pod danym adresem URL uzyskała pozytywną ocenę.
• Grupy adresów URL pomagają wykrywać problemy ze wspólnymi szablonami i komponentami.
• Raporty dla urządzeń mobilnych i komputerów należy oceniać niezależnie.
• Do zbadania prawdopodobnych przyczyn problemu potrzebne są PageSpeed Insights i narzędzia programistyczne.
• Podczas weryfikacji Search Console ocenia nowe dane zbierane z rzeczywistych wizyt przez określony czas. Weryfikacja nie uruchamia ponownego indeksowania.
• Warto poprawiać Core Web Vitals z myślą o użytkownikach. Lepsze wyniki wskaźników nie są gwarantowanym sposobem na szybki awans w wyszukiwarce.

Podsumowanie

Raport „Podstawowe wskaźniki internetowe” w Google Search Console pomaga wykrywać utrzymujące się problemy z wydajnością, których doświadczają odwiedzający witrynę. Zacznij od grup o stanie „Słabej jakości”. Ustal, który wskaźnik nie spełnia wymagań, i poszukaj wspólnych szablonów lub komponentów. Następnie przetestuj reprezentatywne adresy URL za pomocą PageSpeed Insights i narzędzi diagnostycznych dla programistów, zanim wdrożysz poprawkę w całej witrynie.

Kolejność postępowania jest prosta. W Search Console sprawdź, gdzie występuje problem i jaki ma zasięg. Za pomocą narzędzi diagnostycznych ustal, dlaczego występuje. Po wdrożeniu poprawki zweryfikuj na podstawie danych z rzeczywistych wizyt, czy zmiana przyniosła efekt użytkownikom. Daje to bardziej wiarygodny obraz niż dążenie do poprawy pojedynczego wyniku lub założenie, że jeden udany test jest miarodajny dla całej witryny.