Blog / Wydajność
Core Web Vitals: progi, przyczyny i kolejność napraw
Strona zdaje egzamin z Core Web Vitals, gdy LCP mieści się w 2,5 sekundy, INP w 200 milisekundach, a CLS nie przekracza 0,1 - dla 75 procent wizyt. Poniżej: co dokładnie mierzy każda z tych liczb, skąd najczęściej biorą się złe wyniki i w jakiej kolejności je naprawiać, żeby nie robić pracy dwa razy.
01Krótka odpowiedź
Czym jest Core Web Vitals?
Core Web Vitals to trzy wskaźniki, którymi Google mierzy jakość doświadczenia użytkownika na stronie: LCP opisuje, jak szybko pojawia się główna treść, INP - jak szybko strona odpowiada na kliknięcie, a CLS - jak bardzo układ przesuwa się w trakcie ładowania. Ocena zapada na podstawie danych od realnych użytkowników Chrome, a nie z pojedynczego testu: liczy się wynik 75 procent wizyt z ostatnich 28 dni, osobno dla urządzeń mobilnych i dla komputerów.
Dla właścicieli stron firmowych i sklepów, którzy dostali czerwony raport w Search Console i nie wiedzą, od którego końca zacząć.
02Liczby
Progi Core Web Vitals w jednym miejscu
Trzy zakresy dla każdego wskaźnika: dobry, wymagający poprawy i słaby. Strona zalicza test dopiero wtedy, gdy wszystkie trzy wskaźniki mieszczą się w zakresie dobrym.
- LCP - dobry wynik
- Do 2,5 sekundy. Od 2,5 do 4,0 sekundy wymaga poprawy, powyżej 4,0 sekundy jest słaby.
- INP - dobry wynik
- Do 200 milisekund. Od 200 do 500 milisekund wymaga poprawy, powyżej 500 milisekund jest słaby.
- CLS - dobry wynik
- Do 0,1. Od 0,1 do 0,25 wymaga poprawy, powyżej 0,25 jest słaby.
- Sposób pomiaru
- 75. percentyl wizyt z ruchomego okna 28 dni. Jedna czwarta użytkowników może mieć gorzej i strona nadal zdaje.
- Źródło danych
- Chrome UX Report - telemetria od realnych użytkowników przeglądarki Chrome, którzy zgodzili się na jej wysyłanie.
- Podział na urządzenia
- Mobile i desktop są oceniane osobno. Dobry wynik na komputerze nie ratuje słabego wyniku na telefonie.
- INP zastąpił FID
- 12 marca 2024. FID mierzył opóźnienie tylko pierwszej interakcji, INP bierze pod uwagę najwolniejszą z całej wizyty.
03Wyjaśnienie
Co te trzy liczby naprawdę mierzą
Każdy z trzech wskaźników opisuje inny moment kontaktu ze stroną: LCP dotyczy pierwszego wrażenia, INP - reakcji na działanie użytkownika, CLS - stabilności układu przez cały czas trwania wizyty. Naprawa jednego rzadko poprawia pozostałe, bo przyczyny leżą w zupełnie innych warstwach.
LCP - jak szybko widać treść
LCP (Largest Contentful Paint) to czas od rozpoczęcia ładowania do wyrenderowania największego elementu widocznego w oknie: zwykle jest to obraz w sekcji otwierającej albo blok nagłówka. Google dzieli ten czas na cztery części i to podział, od którego warto zacząć diagnozę, bo każda z nich naprawia się inaczej.
- Czas odpowiedzi serwera (TTFB) - ile trwa, zanim przeglądarka dostanie pierwszy bajt dokumentu.
- Opóźnienie wykrycia zasobu - ile czasu mija, zanim przeglądarka w ogóle dowie się, że ma pobrać element LCP.
- Czas pobierania zasobu - jak długo trwa transfer samego pliku.
- Opóźnienie renderowania - ile czasu mija od pobrania do narysowania elementu na ekranie.
W praktyce dwie pierwsze części odpowiadają za większość problemów i naprawia się je najtaniej. Kompresja obrazu pomoże tylko wtedy, gdy wąskim gardłem jest część trzecia.
INP - jak szybko strona odpowiada
INP (Interaction to Next Paint) mierzy opóźnienie między kliknięciem, dotknięciem albo naciśnięciem klawisza a najbliższym odświeżeniem obrazu. Z całej wizyty raportowana jest jedna z najwolniejszych interakcji, więc jeden zacinający się filtr potrafi zepsuć wynik strony, która poza tym działa płynnie.
Winowajcą jest prawie zawsze JavaScript zajmujący wątek główny przeglądarki. Dopóki trwa długie zadanie, przeglądarka nie może narysować odpowiedzi na kliknięcie - użytkownik widzi zamrożony interfejs, mimo że dane już przyszły.
CLS - jak bardzo układ ucieka spod palca
CLS (Cumulative Layout Shift) sumuje przesunięcia elementów, które nastąpiły bez udziału użytkownika. To jedyny wskaźnik bez jednostki - wynik jest iloczynem tego, jak duża część ekranu się przesunęła i o jaki dystans. Przesunięcia w ciągu pół sekundy od kliknięcia nie są liczone, bo uznaje się je za zamierzoną reakcję na działanie.
Najczęstsze źródła to obrazy bez podanych wymiarów, treść doładowywana nad tym, co użytkownik już czyta, oraz webfonty o innych proporcjach niż font zastępczy.
Dane z laboratorium a dane z terenu
To rozróżnienie tłumaczy większość nieporozumień wokół Core Web Vitals. Wynik z narzędzia i wynik, który liczy się dla Google, to dwie różne rzeczy mierzone w dwóch różnych warunkach.
- Dane laboratoryjne
- Lighthouse i symulacja w PageSpeed Insights. Jeden przebieg, symulowane łącze, symulowane urządzenie. Dają natychmiastową informację zwrotną, ale nie trafiają do oceny.
- Dane z terenu
- Chrome UX Report, raport Core Web Vitals w Search Console i górna część raportu PageSpeed Insights. To one decydują o ocenie i to one aktualizują się z opóźnieniem.
- Dlaczego się różnią
- Laboratorium nie zna Waszych użytkowników: ich urządzeń, jakości łącza, rozszerzeń w przeglądarce ani tego, że połowa ruchu przychodzi z telefonów sprzed czterech lat.
04Diagnoza
Od objawu do przyczyny
Zanim zaczniecie cokolwiek optymalizować, warto dopasować objaw do warstwy, w której naprawdę leży problem.
| Objaw | Najczęstsza przyczyna | Gdzie to potwierdzić |
|---|---|---|
| LCP powyżej 4 sekund na telefonie | Duży obraz w sekcji otwierającej, pobierany bez priorytetu i w rozmiarze przeznaczonym na komputer | PageSpeed Insights, podział LCP na cztery części |
| LCP dobry na komputerze, słaby na telefonie | Ten sam plik wysyłany na oba urządzenia albo wolna odpowiedź serwera przy gorszym łączu | Chrome UX Report z przełącznikiem typu urządzenia |
| Interfejs zacina się po kliknięciu | Długie zadania JavaScriptu blokujące wątek główny przeglądarki | Chrome DevTools, panel Performance, zadania dłuższe niż 50 ms |
| Układ podskakuje w trakcie ładowania | Obrazy, reklamy lub osadzone elementy bez zarezerwowanego miejsca | Lighthouse, pozycja o unikaniu dużych przesunięć układu |
| Tekst mruga i zmienia szerokość | Podmiana fontu systemowego na webfont o innych proporcjach | DevTools, zakładka Network, moment pobrania pliku woff2 |
| Wyniki skaczą z tygodnia na tydzień | Za mało ruchu, żeby 75. percentyl był stabilny statystycznie | Search Console, liczba adresów przypisanych do grupy |
05Plan
Sześć kroków w kolejności, która ma sens
Kolejność nie jest przypadkowa. Każdy krok zmienia warunki dla następnego, więc praca wykonana od końca zwykle wymaga powtórzenia.
01
Zacznij od danych z terenu
Otwórz raport Core Web Vitals w Search Console i wypisz grupy adresów, które nie zdają. Optymalizowanie strony, na którą nikt nie wchodzi, nie zmieni wyniku serwisu.
EfektLista adresów uszeregowana według liczby wizyt
02
Napraw czas odpowiedzi serwera
TTFB wchodzi w skład LCP w całości. Dopóki serwer odpowiada wolno, żadna optymalizacja obrazu nie odrobi tych sekund - one zostały stracone, zanim przeglądarka zobaczyła dokument.
EfektTTFB zmierzony przed i po, dla tych samych adresów
03
Zajmij się elementem LCP
Ustal, który element jest tym największym, i zadbaj o trzy rzeczy: żeby nie był ładowany leniwie, żeby miał wysoki priorytet pobierania i żeby telefon dostawał plik w swoim rozmiarze, a nie w komputerowym.
EfektElement LCP wskazany z nazwy w dokumentacji projektu
04
Zetnij JavaScript blokujący wątek
Usuń skrypty, których nikt nie używa, przenieś resztę poza ścieżkę krytyczną i podziel długie zadania. To jedyna droga do poprawy INP - tego wskaźnika nie da się naprawić po stronie serwera.
EfektLista skryptów zewnętrznych z decyzją: zostaje, przenosimy, usuwamy
05
Zarezerwuj miejsce na wszystko, co doładowuje się później
Wymiary na obrazach i osadzeniach, stała wysokość kontenerów na treść dynamiczną, font zastępczy dobrany proporcjami do docelowego. CLS jest jedynym wskaźnikiem, który da się doprowadzić do zera i utrzymać.
EfektCLS poniżej 0,1 w danych laboratoryjnych na kluczowych szablonach
06
Zmierz ponownie i poczekaj na okno 28 dni
Dane laboratoryjne pokażą efekt od razu. Dane z terenu przesuwają się stopniowo, bo okno pomiaru jest ruchome - pełny obraz zobaczycie dopiero po około czterech tygodniach od wdrożenia.
EfektPorównanie przed i po, osobno dla danych laboratoryjnych i terenowych
06Ostrzeżenia
Cztery rzeczy, które nie działają
Poniższe podejścia pojawiają się w większości projektów, w których ktoś próbował poprawić wyniki przed nami. Żadne z nich nie usuwa przyczyny.
Gonienie za setką w Lighthouse
Wynik Lighthouse to ocena złożona z danych laboratoryjnych i nie jest tym, co Google bierze pod uwagę. Można mieć 100 punktów i czerwony raport w Search Console, bo realni użytkownicy wchodzą na słabszym sprzęcie i wolniejszym łączu niż symulacja.
Przepisanie strony na nowy framework
Zmiana technologii nie usuwa przyczyn sama z siebie. Jeśli problemem był nieskompresowany obraz, wolny hosting i cztery narzędzia analityczne, po migracji będą tam dokładnie te same cztery narzędzia - tylko w nowszej składni.
Leniwe ładowanie wszystkich obrazów
Odraczanie pobierania ma sens poniżej pierwszego ekranu. Nałożone na element LCP działa dokładnie odwrotnie: przeglądarka dowiaduje się o nim później, więc wskaźnik rośnie zamiast maleć.
Wtyczka optymalizacyjna jako cały plan
Wtyczki potrafią pomóc przy pamięci podręcznej i kompresji, ale nie skrócą czasu odpowiedzi serwera, nie usuną skryptu reklamowego, na który ktoś się zgodził, i nie zarezerwują miejsca na element wstrzykiwany przez zewnętrzne narzędzie.
07Jeśli chcecie to zlecić
Robimy to jako usługę
08Pytania
Najczęstsze pytania o Core Web Vitals
Czy Core Web Vitals wpływają na pozycję w Google?
Tak, wchodzą w skład sygnałów jakości strony, ale nie zastępują trafności treści. Google konsekwentnie powtarza, że lepsza odpowiedź na zapytanie wygra ze stroną szybszą, lecz mniej trafną. Core Web Vitals działają raczej jak języczek u wagi między stronami porównywalnymi merytorycznie - i jak realny czynnik konwersji, niezależnie od wyszukiwarki.
Dlaczego PageSpeed Insights pokazuje 95 punktów, a Search Console świeci na czerwono?
Bo to dwa różne pomiary. Punktacja pochodzi z jednego testu laboratoryjnego na symulowanym urządzeniu, a Search Console pokazuje dane od realnych użytkowników Chrome z ostatnich 28 dni. Jeśli Wasi użytkownicy wchodzą na starszych telefonach i wolniejszym łączu niż symulacja, ich wyniki będą gorsze. Dla oceny liczą się dane z terenu.
Po ilu dniach od poprawek zobaczę zmianę w danych?
W danych laboratoryjnych natychmiast, w danych z terenu stopniowo przez około 28 dni. Okno pomiaru jest ruchome, więc zaraz po wdrożeniu wynik nadal zawiera wizyty sprzed poprawki. Pełny obraz pojawia się dopiero wtedy, gdy całe okno składa się z ruchu po zmianie.
Co zrobić, gdy mojej strony nie ma w Chrome UX Report?
To znaczy, że ruch jest za mały, żeby dane były reprezentatywne - i tak bywa przy większości stron firmowych. Zostają dwie drogi: dane laboratoryjne z Lighthouse jako przybliżenie oraz własny pomiar u użytkowników, wpięty w stronę niewielkim skryptem. Bez żadnego z nich optymalizacja jest zgadywaniem.
Czy Core Web Vitals dotyczą też wersji na komputer?
Tak, ale mobile i desktop są oceniane osobno. Dobry wynik na komputerze nie kompensuje słabego na telefonie i odwrotnie. W praktyce to wersja mobilna decyduje częściej, bo tam ograniczenia sprzętu i łącza są większe, a udział ruchu zwykle wyższy.
Czy INP jest trudniejszy do poprawy niż dawny FID?
Tak, i to była intencja zmiany. FID mierzył wyłącznie opóźnienie pierwszej interakcji, więc strona mogła zdać egzamin, a i tak zacinać się przy każdym kolejnym kliknięciu. INP obejmuje całą wizytę i uwzględnia czas potrzebny na narysowanie odpowiedzi. Wymaga realnego ograniczenia pracy JavaScriptu, a nie samego jej odroczenia.
09Czytaj dalej
Powiązane strony
Chcecie wiedzieć, gdzie konkretnie tracicie sekundy?
Podeślijcie adres strony. Odpiszemy, które z trzech wskaźników nie zdają, co jest najbardziej prawdopodobną przyczyną i czy da się to naprawić bez przebudowy serwisu.