Core Web Vitals - poradnik jak poprawić wskaźniki

Od czego zaczynam, czyli dane z terenu i laboratorium

Zanim cokolwiek poprawię, sprawdzam, skąd pochodzi ocena. Google ocenia strony na podstawie danych od prawdziwych użytkowników Chrome (raport CrUX), zbieranych przez 28 dni i liczonych dla 75% wizyt. Te dane widać w Search Console i w górnej części raportu PageSpeed Insights. Lighthouse i niższa część PageSpeed Insights to test laboratoryjny na symulowanym urządzeniu, przydatny do diagnozy, ale nie decydujący o ocenie.

Najczęstsza sytuacja w praktyce: Lighthouse pokazuje zielony wynik, a Search Console czerwony. Laptop i szybkie łącze nie oddają tego, co dzieje się na średnim telefonie w sieci komórkowej, a test laboratoryjny w ogóle nie mierzy interakcji, czyli INP. Dlatego zawsze zaczynam od danych z terenu, a test laboratoryjny służy mi do znalezienia przyczyny.

W jakiej kolejności poprawiam wskaźniki

1. Grupy adresów w Search Console. Raport grupuje podobne strony. Najpierw biorę grupy z największym ruchem, zwykle stronę produktu, kategorię i wpis, bo poprawa jednego szablonu poprawia tysiące adresów naraz.
2. Serwer i TTFB. Jeśli serwer odpowiada wolno, poprawki w przeglądarce niewiele dadzą, bo LCP nie może być krótsze niż czas oczekiwania na HTML.
3. LCP i CLS. Zwykle dają się poprawić najszybciej, bo wymagają zmian w zdjęciach, stylach i szablonie.
4. INP. Najczęściej wymaga zmian w JavaScripcie i decyzji o skryptach zewnętrznych, więc trwa najdłużej.

Każdy szablon analizuję w narzędziach deweloperskich: nagranie w zakładce Performance pokazuje, który etap ładowania trwa najdłużej. Pomaga w tym znajomość kolejności tych etapów, którą opisuje działanie strony internetowej w przeglądarce.

Serwer i TTFB

Przy TTFB powyżej ok. 0,8 s zaczynam od serwera: pamięć podręczna całych stron, aktualna wersja PHP lub Node.js, poprawa najwolniejszych zapytań do bazy i CDN dla plików statycznych. Wolne zapytania i błędy, które spowalniają odpowiedzi, najszybciej wskazuje analiza logów serwera. Gdy problemem jest sam serwer, a nie aplikacja, wracam do pytania, jaki hosting pasuje do projektu.

Jak poprawić LCP

Najpierw ustalam, który element jest LCP na telefonie i na komputerze, bo często są to różne elementy. Potem dzielę czas LCP na etapy: czas odpowiedzi serwera, opóźnienie pobrania zasobu, czas pobrania i opóźnienie wyświetlenia. Poprawiam ten etap, który trwa najdłużej: zdjęciu nadaję wysoki priorytet i nowoczesny format, usuwam leniwe ładowanie z pierwszego ekranu, wydzielam style potrzebne na starcie. Cały proces na przykładzie z projektu pokazuje optymalizacja LCP, a usuwanie zbędnego CSS refaktoryzacja CSS pod kątem FCP.

Jak poprawić INP

INP pogarsza każde długie zadanie w głównym wątku przeglądarki, które przypada na moment kliknięcia. Najczęściej winne są skrypty zewnętrzne, page buildery i obsługa zdarzeń wykonująca zbyt dużo pracy naraz. Nagrywam w DevTools typowe interakcje ze spowolnionym procesorem, znajduję długie zadania i decyduję: usunąć skrypt, odłożyć go, rozbić pracę na mniejsze części albo przenieść obliczenia do Web Workera. Przykład takiej pracy krok po kroku to refaktoryzacja JavaScript pod kątem INP.

Jak poprawić CLS

CLS poprawiam, rezerwując miejsce dla wszystkiego, co pojawia się później niż reszta strony:

• atrybuty width i height albo aspect-ratio dla zdjęć, filmów i ramek,
• stała wysokość dla banerów, reklam, sliderów i powiadomień o cookies,
• nowe treści doładowywane pod obecną, a nie nad nią,
• czcionka zastępcza dopasowana wymiarami do docelowej, co wymaga przemyślanego ładowania czcionek.

W raporcie Performance ścieżka Layout Shifts pokazuje dokładnie, który element się przesunął i kiedy, więc nie trzeba zgadywać.

Core Web Vitals w sklepach internetowych

Sklepy mają więcej elementów, które psują wyniki: filtry, warianty produktów, mini koszyk, rekomendacje, czaty i skrypty reklamowe. W takich projektach najwięcej dają mi:

• przegląd wtyczek i skryptów zewnętrznych, bo w WooCommerce czy PrestaShopie część z nich ładuje się na każdej podstronie, choć potrzebna jest na jednej,
• ładowanie modułów, takich jak czat czy opinie, dopiero po interakcji lub przewinięciu,
• zdjęcia produktów w kilku rozmiarach i nowoczesnych formatach,
• osobna analiza strony kategorii z filtrami, bo to tam najczęściej powstają problemy z INP.

Najczęstsze błędy przy optymalizacji Core Web Vitals

• Praca pod wynik Lighthouse. Wynik 100 w laboratorium nie oznacza dobrej oceny w Search Console.
• Poprawa jednego wskaźnika kosztem innego. Leniwe ładowanie wszystkich zdjęć poprawia wagę strony, ale psuje LCP, a ukrywanie strony do czasu załadowania skryptu testów A/B psuje i LCP, i CLS.
• Pomijanie serwera. Żadna optymalizacja przeglądarki nie nadrobi TTFB na poziomie sekundy.
• Ocena efektów po kilku dniach. Dane z terenu to średnia z 28 dni, więc pełny efekt zmian widać dopiero po około miesiącu.

Checklista poprawy Core Web Vitals