Core Web Vitals wyjaśnione: LCP, INP i CLS prostym językiem

Core Web Vitals nie są testem osobowości dla Twojej strony

Core Web Vitals często traktuje się jak tajemniczą kartę wyników. Strona dostaje czerwony wynik, ktoś wrzuca zrzut ekranu na Slack, a zespół zaczyna kłócić się o frameworki JavaScript.

To nie jest szczególnie użyteczne.

Lepszy sposób myślenia o Core Web Vitals jest prostszy: to trzy pomiary tego, czy strona wydaje się użyteczna dla prawdziwej osoby na prawdziwym urządzeniu. Nie obejmują każdego aspektu wydajności, dostępności ani jakości. Ale wychwytują trzy częste źródła frustracji:

• Główna treść pojawia się zbyt długo.
• Strona reaguje powoli, gdy użytkownik próbuje coś zrobić.
• Układ przesuwa się, gdy użytkownik czyta lub klika.

To właśnie trzy Core Web Vitals: LCP, INP i CLS.

Google używa ich jako części sygnałów dotyczących doświadczenia strony, ale perspektywa SEO nie jest najlepszym powodem, by się nimi przejmować. Lepszy powód jest taki, że wolne, skaczące i niereagujące strony marnują czas użytkowników. Zwykle także gorzej konwertują, są trudniejsze we wsparciu i gorzej się starzeją.

Trzy metryki w jednym zdaniu każda

Zanim przejdziemy do szczegółów, oto wersja prostym językiem:

• LCP, czyli Largest Contentful Paint, mierzy, ile czasu zajmuje załadowanie głównej widocznej treści.
• INP, czyli Interaction to Next Paint, mierzy, jak szybko strona reaguje na interakcje użytkownika w trakcie wizyty.
• CLS, czyli Cumulative Layout Shift, mierzy, jak bardzo strona niespodziewanie się przesuwa.

Typowe progi to:

| Metric | Good | Needs improvement | Poor | |---|---:|---:|---:| | LCP | 2.5s or faster | 2.5s–4.0s | Over 4.0s | | INP | 200ms or faster | 200ms–500ms | Over 500ms | | CLS | 0.1 or lower | 0.1–0.25 | Over 0.25 |

Te liczby zwykle ocenia się na 75. percentylu rzeczywistych wizyt użytkowników. To ważne. Nie próbujesz uzyskać jednego idealnego wyniku w laboratorium. Próbujesz sprawić, by doświadczenie było dobre dla większości użytkowników, w tym osób na wolniejszych telefonach i mniej stabilnych sieciach.

Jeśli patrzysz na automatyczny raport i nie wiesz, od czego zacząć, warto oddzielić diagnozę od paniki. Mamy osobny przewodnik o tym, jak czytać raport Lighthouse bez paniki, który opisuje ten proces bardziej szczegółowo.

LCP: kiedy strona sprawia wrażenie załadowanej?

Largest Contentful Paint mierzy czas renderowania największego widocznego elementu treści w obszarze widoku. W praktyce często jest to:

• obraz hero,
• duży nagłówek,
• wyróżniony obraz artykułu,
• zdjęcie produktu,
• duży blok tekstu.

LCP nie pyta, kiedy zakończyło się ładowanie każdego skryptu, piksela śledzącego i obrazu poniżej pierwszego ekranu. Pyta: kiedy główna rzecz, którą użytkownik przyszedł zobaczyć, stała się widoczna?

To sprawia, że LCP jest metryką bardziej ludzką niż staromodne „czas ładowania strony”. Strona może technicznie skończyć ładowanie późno, ale nadal wydawać się szybka, jeśli główna treść pojawia się szybko. Odwrotna sytuacja też jest możliwa: strona może wywołać zdarzenie load, podczas gdy obszar hero wciąż jest pusty, rozmyty albo zablokowany przez opóźnienie renderowania.

Częste przyczyny słabego LCP

Większość problemów ze słabym LCP wynika z kilku przewidywalnych miejsc:

1. Wolna odpowiedź serwera

Jeśli dokument HTML przychodzi późno, wszystko inne zaczyna się późno.

1. CSS lub JavaScript blokujące renderowanie

Przeglądarka ma treść, ale nie może jej jeszcze namalować.

1. Niezoptymalizowane obrazy hero

Największy element jest zbyt duży, w złym formacie, bez priorytetu albo przez pomyłkę ładowany leniwie.

1. Fonty webowe opóźniające renderowanie tekstu

Duży nagłówek może być elementem LCP, a ładowanie fontu może go opóźnić lub wizualnie zmienić.

1. Opóźnienia renderowania po stronie klienta

Jeśli strona potrzebuje dużego pakietu JavaScript, zanim pokaże sensowną treść, LCP cierpi.

Jak poprawić LCP

Zacznij od rzeczywistego elementu LCP. Nie optymalizuj losowych zasobów, dopóki nie wiesz, co mierzy przeglądarka.

Praktyczne poprawki obejmują:

• Szybko serwuj HTML: stosuj cache tam, gdzie to właściwe, ogranicz pracę backendu, unikaj wolnych przekierowań.
• Zoptymalizuj obraz LCP: użyj właściwych wymiarów, kompresji i formatu.
• Nie ładuj leniwie obrazu hero widocznego na pierwszym ekranie.
• Używaj fetchpriority="high" ostrożnie dla głównego obrazu, gdy naprawdę jest priorytetem.
• Inline'uj krytyczny CSS tylko wtedy, gdy znacząco zmniejsza opóźnienie renderowania.
• Ogranicz JavaScript potrzebny przed pierwszym sensownym renderowaniem.
• Użyj font-display: swap albo innej świadomej strategii dla fontów.

Obrazy i fonty są częstymi winowajcami. W przypadku obrazów kompromis nie sprowadza się do „mały plik = dobrze”. Wybór formatu, wysiłek kodowania i wsparcie przeglądarek również mają znaczenie, dlatego utrzymujemy praktyczne drzewo decyzyjne dla tematu kiedy AVIF wygrywa z WebP, a kiedy nie. W przypadku stron z dużą ilością tekstu fonty webowe nadal należą do najprostszych wygranych wydajnościowych, ponieważ wiele stron wysyła więcej plików fontów, niż faktycznie używa.

INP: czy strona reaguje po dotknięciu?

Interaction to Next Paint mierzy responsywność. Dokładniej: sprawdza opóźnienie między interakcją użytkownika a kolejną aktualizacją wizualną po tym, jak przeglądarka przetworzyła tę interakcję.

Interakcje obejmują między innymi:

• kliknięcie przycisku,
• stuknięcie w menu,
• zaznaczenie checkboxa,
• wpisywanie w pole formularza,
• otwarcie akordeonu.

INP zastąpiło First Input Delay jako Core Web Vital w 2024 roku. To była dobra zmiana. First Input Delay patrzyło tylko na pierwszą interakcję. INP jest szersze: uwzględnia interakcje w trakcie całej wizyty na stronie i raportuje interakcję o wysokim opóźnieniu jako wynik responsywności strony.

Prostym językiem: INP wyłapuje strony, które wyglądają na załadowane, ale sprawiają wrażenie zablokowanych.

Prawdopodobnie zdarzyło Ci się korzystać z takiej strony. Wygląda na gotową. Stukasz w menu. Przez pół sekundy nic się nie dzieje. Stukasz ponownie. Potem dwie rzeczy dzieją się naraz. To problem z INP.

Częste przyczyny słabego INP

INP zwykle jest problemem głównego wątku. Przeglądarka chce odpowiedzieć, ale JavaScript, prace renderowania albo obliczenia układu stoją jej na drodze.

Typowe przyczyny obejmują:

• duże pakiety JavaScript,
• kosztowne obsługi zdarzeń,
• pracę hydratacji w aplikacjach renderowanych po stronie klienta,
• skrypty firm trzecich konkurujące o główny wątek,
• długotrwałe zadania po załadowaniu strony,
• złożone aktualizacje DOM wywoływane przez małe interakcje,
• layout thrashing, czyli sytuację, w której kod wielokrotnie odczytuje i zapisuje wartości układu.

Tagi marketingowe, analityka, widgety czatu i banery zgód mogą mieć w tym udział. To nie znaczy „usuń wszystko”. Oznacza to, że każdy skrypt na stronie ma koszt, a opóźnienie interakcji jest miejscem, w którym ten koszt często staje się widoczny.

Jak poprawić INP

Poprawa INP polega mniej na jednym magicznym atrybucie, a bardziej na zmniejszeniu rywalizacji o główny wątek.

Przydatne podejścia obejmują:

• Dziel długie zadania JavaScript na mniejsze części.
• Odkładaj nieistotną pracę do czasu, aż strona będzie użyteczna.
• Usuwaj nieużywany JavaScript, zamiast jedynie go minifikować.
• Utrzymuj obsługi zdarzeń małe i przewidywalne.
• Unikaj ponownego renderowania dużych części interfejsu dla drobnych zmian stanu.
• Używaj CSS do prostych stanów wizualnych tam, gdzie to możliwe.
• Audytuj skrypty firm trzecich i ładuj je tylko tam, gdzie są potrzebne.

Spójrz też na projektowanie interakcji. Przycisk, który daje natychmiastową informację wizualną, może wydawać się bardziej responsywny, nawet jeśli dalsza praca trwa dłużej. To nie zastępuje wydajności, ale jest częścią dobrej inżynierii interfejsu. Nasza lista kontrolna dla dostępnych przycisków webowych częściowo się z tym pokrywa: jasne stany, właściwa semantyka i przewidywalne zachowanie pomagają zarówno użytkownikom, jak i przeglądarkom.

CLS: czy strona pozostaje tam, gdzie użytkownik się spodziewa?

Cumulative Layout Shift mierzy niespodziewany ruch widocznych elementów. Jeśli użytkownik zaczyna czytać akapit, a reklama, obraz albo baner ładuje się nad nim i spycha tekst w dół, zwiększa to CLS.

CLS nie jest mierzone w sekundach. To wynik oparty na tym, ile treści się przesunęło i jak daleko. Im niżej, tym lepiej.

Kluczowe słowo to niespodziewany. Zmiany układu wywołane działaniem użytkownika zwykle nie są liczone w ten sam sposób. Jeśli ktoś stuknie „pokaż więcej” i treść się rozwinie, to jest oczekiwane. Jeśli baner newslettera pojawi się u góry po trzech sekundach i przesunie wszystko w dół, to już nie.

Częste przyczyny słabego CLS

Problemy z CLS bywają prozaiczne:

• obrazy bez atrybutów width i height,
• reklamy lub osadzenia bez zarezerwowanego miejsca,
• banery cookies wstawiane nad treścią,
• fonty webowe podmieniane na takie o innych metrykach,
• późno ładujące się paski promocyjne,
• dynamicznie wstrzykiwana treść w pobliżu góry strony.

Rozwiązaniem zwykle jest zarezerwowanie miejsca, zanim treść dotrze. Przeglądarka powinna znać kształt strony jak najwcześniej.

Jak poprawić CLS

Zacznij od widocznych przesunięć. Obejrzyj nagranie albo użyj narzędzi przeglądarki, aby zidentyfikować elementy, które się poruszają.

Następnie zastosuj nudne poprawki:

• Dodaj jawne atrybuty width i height do obrazów.
• Użyj CSS aspect-ratio dla responsywnych kontenerów multimediów.
• Zarezerwuj stałą lub minimalną przestrzeń dla reklam, osadzeń i iframe'ów.
• Unikaj wstrzykiwania banerów nad istniejącą treścią po załadowaniu.
• Wybieraj fonty zastępcze o metrykach podobnych do fontu docelowego.
• Unikaj animacji, które zmieniają właściwości układu, takie jak top, left, width lub height; preferuj transformacje.

CLS to jedna z niewielu metryk wydajności, w których dyscyplina wygrywa ze sprytem. Jeśli strona ma stabilne pudełka, zwykle osiąga dobry wynik.

Dane terenowe i laboratoryjne są użyteczne, ale odpowiadają na różne pytania

Częstym źródłem zamieszania jest to, że różne narzędzia pokazują różne liczby. To normalne.

Dane terenowe pochodzą od prawdziwych użytkowników. Odzwierciedlają rzeczywiste urządzenia, sieci, lokalizacje i warunki przeglądarki. Google Chrome User Experience Report jest przykładem danych terenowych.

Dane laboratoryjne pochodzą z kontrolowanego środowiska testowego. Znanym przykładem jest Lighthouse. Są powtarzalne i przydatne do debugowania, ale nie są tym samym, co żywe doświadczenie Twoich użytkowników.

Używaj danych terenowych, aby zdecydować, czy użytkownicy naprawdę mają problem. Używaj danych laboratoryjnych, aby ten problem odtworzyć i debugować.

Pamiętaj też, że Core Web Vitals zwykle ocenia się dla konkretnego URL-a lub grupy URL-i, a nie jako jedną abstrakcyjną właściwość Twojej marki. Strona główna, artykuł na blogu, strona cennika i checkout mogą mieć bardzo różne wąskie gardła.

Rozsądna kolejność prac

Jeśli wszystkie trzy metryki są słabe, pokusa polega na tym, by zacząć wszędzie naraz. Oprzyj się jej.

Praktyczna kolejność to:

1. Najpierw napraw oczywiste CLS

Brakujące wymiary obrazów i niestabilne banery często dają szybkie wygrane.

1. Popraw LCP dla ważnych szablonów

Skup się na stronach, które mają znaczenie: stronach produktów, landing page'ach, artykułach, ścieżkach rejestracji.

1. Zbadaj INP na rzeczywistych interakcjach

Klikaj rzeczy, które użytkownicy naprawdę klikają. Menu, filtry, formularze i kontrolki checkoutu często ujawniają więcej niż początkowy ślad ładowania.

1. Audytuj skrypty firm trzecich

Zostaw te, które uzasadniają swój koszt. Usuń lub opóźnij te, które tego nie robią.

1. Ustal budżet wydajności

Bez budżetu poprawki wydajności z czasem zanikają. Nowe skrypty, obrazy i komponenty projektowe po cichu cofną wykonaną pracę.

Najważniejsze: nie optymalizuj pod odznakę. Optymalizuj pod podróż użytkownika. Marginalna poprawa wyniku na stronie o małym ruchu może mieć mniejsze znaczenie niż nieco niedoskonała, ale znacznie szybsza interakcja w checkoutcie.

<!-- tool-cta:start -->

💡 Wypróbuj to: Ponieważ LCP zwykle jest problemem z obrazem, zmniejsz swoją główną grafikę za pomocą Image Compressor jako pierwszą, łatwą wygraną.

<!-- tool-cta:end -->

Czego Core Web Vitals Ci nie powiedzą

Core Web Vitals są użyteczne, ale niepełne.

Nie powiedzą Ci, czy Twoja treść jest dobra. Nie powiedzą, czy nawigacja ma sens. Nie gwarantują dostępności. Nie mierzą prywatności, bezpieczeństwa, zaufania, czytelności ani tego, czy strona odpowiada na pytanie użytkownika.

Nie zastępują też osądu. Strona może przejść Core Web Vitals i nadal być nieprzyjemna. Złożona aplikacja może nie spełnić progu, a mimo to być odpowiedzialnie zaprojektowana w ramach swoich ograniczeń.

Traktuj LCP, INP i CLS jak czujniki dymu. Gdy się włączają, zbadaj sprawę. Gdy milczą, nadal utrzymuj budynek.