Core Web Vitals: co naprawdę porusza wskaźniki
Core Web Vitals to trzy terenowe pomiary tego, jak strona się odczuwa: jak długo pojawia się główna treść, jak bardzo skacze w trakcie ładowania i jak szybko strona reaguje na dotyk.
Ten przewodnik omawia, co mierzy każda metryka, konkretne przyczyny słabych wyników i poprawki, które ruszają dane terenowe, a nie tylko wyniki laboratoryjne.
Co mierzą trzy metryki#
Każda ma próg «dobrze» i niewielki zbiór typowych przyczyn. Zauważ, że dla pozycji liczą się dane terenowe od realnych odwiedzających, a nie wynik z twojego laptopa.
| Metryka | Dobrze | Mierzy | Typowa przyczyna słabego wyniku |
|---|---|---|---|
| LCP | Poniżej 2,5 s | Czas do narysowania największego widocznego elementu | Niezoptymalizowany obraz główny, wolny serwer, blokujący CSS |
| CLS | Poniżej 0,1 | Jak bardzo układ skacze przy ładowaniu | Obrazy bez wymiarów, wstawiane banery, późne kroje |
| INP | Poniżej 200 ms | Szybkość reakcji na interakcję | Długie zadania JavaScriptu blokujące główny wątek |
Narzędzia laboratoryjne mierzą jedno ładowanie na jednej maszynie. Dane terenowe to 75. percentyl realnych wizyt, w tym starych telefonów w słabych sieciach — czyli dokładnie tych odwiedzających, którzy odchodzą najszybciej.
Poprawianie LCP#
LCP to niemal zawsze obraz albo nagłówek zablokowany przez coś innego. Przejdź te punkty po kolei; dwa pierwsze rozwiązują większość stron.
- Ustal, który element jest faktycznie elementem LCP w danych terenowych. Optymalizowanie złego obrazu to najczęstsza strata wysiłku.
- Nigdy nie ładuj obrazu LCP z opóźnieniem. Nadaj mu fetchpriority="high".
- Serwuj go w nowoczesnym formacie, w rozmiarze wyświetlania, z srcset dla mniejszych ekranów.
- Wstępnie załaduj krój pisma tekstu LCP i użyj font-display: swap.
- Usuń blokujący CSS i JavaScript z head; wstaw krytyczny CSS w treści, jeśli strona jest mała.
- Obniż Time to First Byte cache'em i CDN-em — żadna praca front-endowa nie nadrobi wolnego serwera.
- Wytnij zewnętrzne skrypty ze ścieżki krytycznej. Każdy to zapytanie DNS, połączenie i nieprzewidywalny plik.
Poprawianie CLS#
Skakanie układu jest niemal całkowicie do uniknięcia, a poprawki są tanie. To także metryka najbardziej odczuwalna, bo to ona sprawia, że ludzie klikają nie to, co chcieli.
- Ustaw width i height na każdym obrazie i filmie, żeby przeglądarka zarezerwowała miejsce.
- Zarezerwuj miejsce na reklamy, osadzenia i ramki kontenerem o stałych proporcjach.
- Nigdy nie wstawiaj treści nad istniejącą po załadowaniu — baner cookies należy na dół albo jako nakładka.
- Dopasuj metryki kroju zapasowego do krojów webowych albo użyj size-adjust, żeby podmiana nie przebudowała strony.
- Unikaj animowania właściwości układu. Animuj transform i opacity, które nie wymuszają przeliczenia.
- Nadaj min-height sekcjom ładowanym dynamicznie, żeby nie rozwijały się od zera.
Poprawianie INP#
INP zastąpił First Input Delay i jest trudniejszy, bo mierzy każdą interakcję w trakcie wizyty, a nie tylko pierwszą. Słabe INP to niemal zawsze za dużo JavaScriptu na głównym wątku.
| Przyczyna | Poprawka |
|---|---|
| Duża paczka przetwarzana przy ładowaniu | Podziel kod; ładuj tylko to, czego strona używa |
| Długie zadania powyżej 50 ms | Podziel pracę i oddaj wątek |
| Kosztowne obsługi zdarzeń | Debounce i wyniesienie ciężkiej pracy poza ścieżkę interakcji |
| Ciężkie zewnętrzne tagi | Ładować po interakcji albo usunąć — sprawdź, co każdy daje |
| Duży DOM, powyżej 10 000 węzłów | Wirtualizuj długie listy; uprość głębokie zagnieżdżenia |
| Naprzemienne odczyty i zapisy układu | Grupuj odczyty i zapisy zamiast przeplatać |
Na stronach treściowych najcenniejsza interwencja w INP to zwykle usunięcie JavaScriptu, a nie jego optymalizacja. Pytaj, co każdy skrypt daje; menedżery tagów zbierają skrypty, których nikt nie pamięta dodawać.
Najczęstsze pytania
Jak bardzo Core Web Vitals wpływają na pozycje?
To sygnał realny, ale umiarkowany, działający raczej jak rozstrzygnięcie remisu niż zastępstwo trafności. Szybka strona o niewłaściwym temacie nie pokona wolniejszej, która odpowiada na pytanie. Mocniejszy argument za poprawą jest behawioralny: wolne i skaczące strony tracą odwiedzających, zanim pozycje w ogóle wejdą do gry.
Dlaczego mam dobry wynik w Lighthouse i słabe dane terenowe?
Bo Lighthouse symuluje jedno ładowanie na twojej maszynie i twoim łączu, a dane terenowe to 75. percentyl realnych wizyt — w tym trzyletnich telefonów w zatłoczonych sieciach. Gdy oba się rozjeżdżają, liczą się dane terenowe. Używaj laboratorium do diagnozy, nie do punktacji.
Czy muszę poprawić wszystkie trzy metryki?
Popraw te, które zawodzą, w kolejności odczuwalnej przez odwiedzających. CLS jest zwykle najtańszy w naprawie i najbardziej irytujący dla użytkownika, więc to dobry start. LCP ma największy wpływ na to, czy ludzie poczekają. INP liczy się najbardziej na stronach interaktywnych i najmniej przy statycznych artykułach.
Po jakim czasie widać poprawę?
Dane terenowe to przesuwne okno 28 dni, więc znaczący ruch zajmuje około czterech tygodni od momentu, gdy poprawka dotrze do wszystkich odwiedzających. Nie oceniaj zmiany po trzech dniach. Sprawdź od razu wartości laboratoryjne, by potwierdzić, że poprawka zrobiła to, czego oczekiwałeś.
core web vitalslcpclsinpszybkość stronywydajność web
