Core Web Vitals na stronie firmowej: co oznaczają LCP, INP i CLS i jak je poprawić

Krótka odpowiedź: Core Web Vitals to trzy metryki, które mierzą, jak strona zachowuje się z punktu widzenia użytkownika: LCP (jak szybko pojawia się główna treść), INP (jak szybko strona reaguje na kliknięcia) i CLS (czy elementy nie przeskakują podczas ładowania). Według web.dev dobry wynik to LCP do 2,5 s, INP do 200 ms i CLS do 0,1. Poprawa zwykle zaczyna się od obrazów, skryptów zewnętrznych i jakości hostingu, a nie od skomplikowanej optymalizacji kodu.

Ten artykuł jest techniczną pogłębioną wersją tekstu Dlaczego szybkość strony wpływa na sprzedaż bardziej niż myślisz. Tam piszę o tym, po co mierzyć szybkość. Tutaj pokazuję, co oznaczają poszczególne wskaźniki i co konkretnie poprawić.

Spis treści

• Czym są Core Web Vitals
• LCP: jak szybko pojawia się główna treść
• INP: jak szybko strona reaguje
• CLS: czy strona przeskakuje
• Jak sprawdzić swoje wyniki
• Kolejność poprawek, która ma sens
• Typowe winowajcy w WordPressie i sklepach
• Czego nie obiecywać sobie po optymalizacji

Czym są Core Web Vitals

Core Web Vitals to zestaw trzech metryk, które Google uznaje za kluczowe dla jakości doświadczenia użytkownika (web.dev: Web Vitals). Każda z nich odpowiada na inne pytanie klienta:

Progi dotyczą 75. percentyla wizyt, osobno dla telefonów i komputerów. W praktyce oznacza to, że trzy czwarte odwiedzin powinno mieścić się w dobrym zakresie, a nie tylko "średnio".

Warto o tym pamiętać, ale też nie przeceniać. Core Web Vitals to element doświadczenia użytkownika, a nie magiczny przycisk pozycjonowania. Strona z doskonałymi wynikami i słabą treścią nie wskoczy na szczyt. Z drugiej strony wolna, rozjeżdżająca się strona traci klientów niezależnie od tego, co sądzi o niej wyszukiwarka.

LCP: jak szybko pojawia się główna treść

LCP mierzy czas, po którym na ekranie pojawia się największy element widoczny na starcie: zwykle zdjęcie w nagłówku, duży baner albo blok tekstu. Web.dev rozkłada go na cztery części (Optimize LCP):

1. TTFB - czas do otrzymania pierwszego bajtu odpowiedzi z serwera.
2. Opóźnienie rozpoczęcia pobierania - czas między TTFB a startem pobierania głównego zasobu.
3. Czas pobierania zasobu.
4. Opóźnienie renderowania - czas od pobrania do pokazania elementu.

To rozbicie jest przydatne, bo pokazuje, gdzie tracisz czas. Wolny serwer to pierwsza część. Ogromne zdjęcie to trzecia. Skrypt blokujący renderowanie to czwarta.

Co zwykle poprawia LCP

• Zadbaj, by główny obraz był widoczny w kodzie HTML. Web.dev zaleca, żeby atrybuty src lub srcset obrazu LCP były w początkowym HTML, a nie dodawane skryptem.
• Nie ładuj leniwie głównego obrazu. Opóźnienie ładowania (lazy-loading) jest dobre dla obrazów poniżej linii zgięcia, ale dla obrazu, który jest LCP, dokumentacja jednoznacznie odradza takie rozwiązanie.
• Nadaj priorytet właściwemu obrazowi. Atrybut fetchpriority="high" ustawia się dla obrazu, który najpewniej jest LCP, i tylko dla jednego, dwóch.
• Zmniejsz obrazy. Odpowiedni rozmiar, nowoczesny format i kompresja skracają czas pobierania.
• Ogranicz czas odpowiedzi serwera. Mniej przekierowań, cache i CDN skracają TTFB. Tu wchodzi w grę jakość hostingu, o czym piszę w artykule Hosting dla małej firmy - jak wybrać.
• Ogranicz skrypty i style blokujące renderowanie. Im mniej ich w <head>, tym szybciej przeglądarka może narysować stronę.

INP: jak szybko strona reaguje

INP zastąpił wcześniejszy wskaźnik FID i mierzy opóźnienie między interakcją użytkownika (kliknięcie, dotknięcie, naciśnięcie klawisza) a kolejną klatką z efektem. Według web.dev składa się z opóźnienia wejścia, czasu przetwarzania i opóźnienia prezentacji (Optimize INP).

Zły INP czuć "w palcach": klikasz menu i nic się nie dzieje przez chwilę, wpisujesz w pole formularza i litery pojawiają się z opóźnieniem. Przyczyna to zwykle zajęty główny wątek przeglądarki.

Co zwykle poprawia INP

• Skracaj długie zadania JavaScript. Długie zadania blokują wątek, więc przeglądarka nie może zareagować na kliknięcie.
• Dziel ciężką pracę na mniejsze kawałki. Najpierw aktualizacja tego, co widzi użytkownik, a pozostałe obliczenia później.
• Ogranicz liczbę i wagę skryptów. Każdy czat, widget, narzędzie analityczne i piksel reklamowy to dodatkowy kod, który konkuruje o czas procesora.
• Pilnuj rozmiaru DOM. Bardzo rozbudowana struktura strony zwiększa koszt renderowania po każdej interakcji.

Na zwykłej stronie firmowej problem INP pojawia się rzadko, chyba że jest przeładowana wtyczkami i skryptami zewnętrznymi. W sklepach z filtrami, koszykiem i rozbudowanymi funkcjami warto go sprawdzić dokładnie.

CLS: czy strona przeskakuje

CLS mierzy, jak bardzo elementy zmieniają położenie w trakcie ładowania i użytkowania strony. Klasyczny przykład: chcesz kliknąć przycisk, a w ostatniej chwili nad nim ładuje się baner i trafiasz w coś innego.

Najczęstsze przyczyny i poprawki według web.dev (Optimize CLS):

• Obrazy bez wymiarów. Ustaw atrybuty width i height albo użyj aspect-ratio, żeby przeglądarka zarezerwowała miejsce, zanim obraz się pobierze.
• Reklamy, osadzenia i ramki iframe. Zarezerwuj dla nich miejsce, na przykład przez minimalną wysokość.
• Treści wstawiane dynamicznie, jak banery cookies, formularze zapisu czy paski z promocją. Rezerwuj dla nich miejsce albo nakładaj je jako okno poza przepływem treści.
• Czcionki internetowe. Zbyt późna podmiana czcionki może przesuwać tekst. Pomaga dobór czcionki zapasowej o podobnych metrykach i odpowiednie ustawienia ładowania fontów.
• Animacje. Do ruchu używaj właściwości transform, a nie zmieniaj położenia elementów w sposób, który wymusza ponowne przeliczenie układu.

CLS jest często najtańszy do poprawy: wystarczy zadbać o wymiary obrazów i miejsce na elementy dynamiczne.

Jak sprawdzić swoje wyniki

Nie trzeba kupować żadnych narzędzi.

1. PageSpeed Insights. Wpisz adres strony. Narzędzie pokazuje dane z realnych wizyt (jeśli ruch jest wystarczający) i test laboratoryjny. Sprawdź osobno wersję mobilną i komputerową.
2. Raport Core Web Vitals w Google Search Console. Pokazuje grupy adresów z problemami na podstawie danych terenowych. To najlepsze miejsce do śledzenia trendu po wdrożeniu poprawek.
3. Lighthouse w przeglądarce Chrome. Test laboratoryjny uruchamiany lokalnie, przydatny w trakcie pracy nad poprawkami.
4. DevTools (panel Performance). Dla osób technicznych: pozwala zobaczyć, co dokładnie blokuje wątek lub powoduje przesunięcie.

Pamiętaj, że test laboratoryjny i dane terenowe mogą się różnić. Web.dev zaznacza, że narzędzia laboratoryjne pokazują głównie przesunięcia z czasu ładowania, a dane terenowe obejmują całe życie strony. Jeśli wyniki się rozjeżdżają, wierz danym terenowym i szukaj problemów, które pojawiają się po załadowaniu.

Kolejność poprawek, która ma sens

Nie ma sensu zaczynać od najtrudniejszych rzeczy. Proponuję taką kolejność, od najtańszych do najdroższych:

1. Obrazy: właściwy rozmiar, kompresja, nowoczesny format, wymiary w kodzie, brak lazy-loadingu dla głównego obrazu.
2. Skrypty zewnętrzne: przejrzyj, co ładuje się na stronie, i usuń to, czego nie używasz. Każdy zbędny widget to koszt.
3. Wtyczki i dodatki: na stronach opartych o WordPress wyłącz lub zamień te, które dokładają dużo kodu do każdej podstrony.
4. Elementy dynamiczne: zarezerwuj miejsce dla banerów i okien, żeby nie przesuwały treści.
5. Hosting i cache: jeżeli TTFB jest wysoki, problemem bywa serwer lub brak cache.
6. Kod strony: dopiero na końcu, jeśli powyższe nie wystarczą, optymalizacja kodu, podział skryptów i krytyczny CSS.

Typowe winowajcy w WordPressie i sklepach

Z doświadczenia przy stronach firmowych i sklepach najczęściej widać:

• Zdjęcia wgrane w oryginalnym rozmiarze prosto z aparatu lub telefonu.
• Rozbudowane szablony z wieloma efektami, które ładują dużo skryptów na każdej podstronie.
• Zbyt wiele wtyczek do rzeczy, które da się zrobić jednym fragmentem kodu.
• Skrypty analityczne i reklamowe wczytywane bez potrzeby w zbyt wielu miejscach.
• Brak cache albo przypadkowo skonfigurowany cache, który nie działa.
• Tani, przeładowany hosting, na którym czas odpowiedzi rośnie w godzinach szczytu.

Szersze porównanie WordPressa i strony pisanej od zera, także pod kątem wydajności, opisuję w artykule Strona na WordPressie czy pisana od zera. A listę typowych błędów projektowych, które odbijają się na szybkości i klientach, znajdziesz w tekście 10 błędów przy projektowaniu strony internetowej.

Czego nie obiecywać sobie po optymalizacji

• Pozycji w Google. Core Web Vitals to część doświadczenia użytkownika, ale nie gwarantują wyższych pozycji. Google w swoich materiałach podkreśla, że nie ma tajnych sposobów na pierwsze miejsce.
• Wyników od razu. Dane terenowe zbierają się z kilku tygodni wizyt, więc efekt w raporcie Search Console pojawia się z opóźnieniem.
• Zielonych wyników za wszelką cenę. Niektóre funkcje (czat, rozbudowana galeria, mapa) kosztują czas ładowania. Warto zdecydować, które są dla Ciebie naprawdę ważne.

Najbardziej rozsądne podejście to poprawić to, co proste, zmierzyć efekt i dopiero wtedy decydować o dalszych krokach. Ogólne podstawy widoczności w wyszukiwarce opisuję w artykule SEO dla małej firmy: od czego zacząć.