Core Web Vitals - jak poprawić wyniki?

Ocena dotyczy 75 percentyla, czyli trzech czwartych wizyt. Nie wystarczy, że stronę da się szybko otworzyć na dobrym łączu; liczy się doświadczenie większości odwiedzających.

Osobno oceniane są wersje mobilna i komputerowa. W praktyce problemem jest prawie zawsze ta pierwsza, bo telefon ma słabszy procesor i gorsze łącze, a to właśnie na nim wypada dziś większość ruchu.

PageSpeed Insights pokazuje dwie osobne sekcje wyników, a mylenie jednej z drugą prowadzi do złych decyzji i do naprawiania nie tego, co trzeba.

Dane od prawdziwych użytkowników pochodzą z przeglądarki Chrome i obejmują okno 28 dni. To one decydują o ocenie w Search Console i to one są sygnałem dla wyszukiwarki. Zmiana wdrożona dziś pojawi się tam stopniowo, przez kolejne tygodnie.

Dane z laboratorium to symulacja na standardowym urządzeniu i łączu. Są dostępne od ręki i nadają się do sprawdzenia, czy poprawka zadziałała, ale nie opisują tego, co przeżywają Twoi klienci.

Największym elementem jest zwykle zdjęcie nagłówkowe albo blok tekstu na pierwszym ekranie. Na czas jego pojawienia się składają się cztery odcinki: odpowiedź serwera, pobranie plików blokujących, pobranie samego zasobu i jego wyświetlenie.

Najczęstsze przyczyny, w kolejności występowania:

• wolna odpowiedź serwera, powyżej pół sekundy, przy braku cache
• ciężkie zdjęcie nagłówkowe bez kompresji i we właściwym formacie
• objęcie pierwszego obrazu opóźnionym ładowaniem
• czcionki z zewnętrznego serwera blokujące wyświetlenie tekstu
• karuzela, która przed pokazaniem pierwszego slajdu ładuje bibliotekę

Kolejność napraw wynika z tej listy: najpierw cache i serwer, potem obraz nagłówkowy, na końcu czcionki. Odwrotna kolejność daje kosmetyczne zyski przy nienaruszonym wąskim gardle.

INP zastąpiło dawne FID i jest znacznie trudniejsze do oszukania, bo mierzy wszystkie interakcje w trakcie wizyty, a nie tylko pierwszą.

Przyczyną jest zwykle jeden wątek przeglądarki zajęty wykonywaniem skryptów. Kliknięcie trafia do kolejki i czeka, aż kod skończy pracę. Użytkownik widzi to jako zawieszenie menu albo przycisku dodania do koszyka.

Typowi winowajcy to skrypty zewnętrzne: piksele reklamowe, narzędzia analityczne, czaty, mapy ciepła. Każde z nich działa w tle podczas przewijania i klikania.

Naprawa polega na trzech rzeczach: usunięciu narzędzi, których nikt nie analizuje, odłożeniu reszty do momentu pierwszej interakcji oraz ograniczeniu pracy wykonywanej przy zdarzeniach. W WordPressie sporą część zysku daje samo wyłączenie wtyczek dokładających skrypty na wszystkich podstronach.

To najtańszy do naprawy wskaźnik, bo przyczyny są policzalne i powtarzalne.

Baner zgody na pliki cookie odpowiada za znaczną część problemów z tym wskaźnikiem w polskich witrynach. Wyświetlany na wierzchu, bez przesuwania treści, przestaje cokolwiek psuć i nadal spełnia swoją funkcję.

Zacznij od Search Console, raport Core Web Vitals. Pokazuje adresy pogrupowane w problemy, a nie pojedynczą stronę, więc od razu widać skalę.

Potem PageSpeed Insights dla konkretnych adresów: strony głównej, karty produktu, wpisu na blogu. To trzy różne szablony i każdy może mieć inny problem.

Trzecim narzędziem jest zakładka wydajności w przeglądarce, która pokazuje, co dokładnie blokuje wątek. Przydaje się przy INP, bo tylko tam widać, który skrypt zajmuje czas.

Mierz zawsze w trybie prywatnym i z wyłączonymi rozszerzeniami. Blokery reklam i wtyczki przeglądarki potrafią zmienić wynik bardziej niż niejedna optymalizacja.

Przy sklepie warto mierzyć osobno ścieżkę zakupu, bo koszyk i kasa nie korzystają z cache strony i zachowują się zupełnie inaczej niż strona główna. To tam użytkownik jest najbliżej decyzji, więc opóźnienie kosztuje najwięcej.

Raport w Search Console grupuje adresy w problemy, więc łatwo wpaść w pułapkę poprawiania tego, czego jest najwięcej, zamiast tego, co przynosi ruch.

Sensowna kolejność bierze pod uwagę dwie rzeczy naraz: liczbę adresów w grupie i to, ile wejść na nie przychodzi. Grupa z tysiącem podstron bez ruchu jest mniej pilna niż pięć kart produktów, na które trafia połowa klientów.

W praktyce najczęściej naprawia się szablony, a nie pojedyncze adresy. Karta produktu, wpis na blogu i strona kategorii to trzy szablony i poprawka w każdym z nich obejmuje od razu setki podstron.

• Włącz jedną warstwę cache strony i sprawdź, czy czas odpowiedzi zszedł poniżej 200 ms
• Wyklucz pierwszy obraz z opóźnionego ładowania i nadaj mu wysoki priorytet
• Przenieś czcionki na własny serwer i ogranicz je do dwóch odmian
• Wyłącz wtyczki ładujące swoje skrypty na wszystkich podstronach
• Podaj wymiary wszystkich obrazów, także tych wstawianych kreatorem
• Zamień osadzone wideo na miniaturę uruchamiającą odtwarzacz po kliknięciu

Przy WooCommerce dochodzi jeszcze jedna warstwa: koszyk i kasa nie korzystają z cache strony, więc tam liczy się wydajność serwera i bazy. Szerzej piszemy o tym w poradniku wolny WooCommerce.

Kolejność całości opisujemy w poradniku jak przyspieszyć wolną stronę.

Same Core Web Vitals mówią, że jest źle, ale nie mówią dlaczego. Do tego służą trzy liczby pomocnicze.

Czas do pierwszego bajtu opisuje, jak długo serwer myśli, zanim zacznie odpowiadać. Powyżej pół sekundy przy działającym cache oznacza, że wąskim gardłem jest hosting. Według ofert popularnych hostingów pakiety za 20-30 zł miesięcznie dzielą zasoby między wiele kont i to na nich ta liczba najczęściej rośnie w godzinach szczytu.

Czas pierwszego wyrenderowania pokazuje, kiedy pojawia się cokolwiek. Duża różnica między nim a LCP wskazuje, że problemem jest konkretny ciężki element, zwykle zdjęcie nagłówkowe.

Czas blokowania wątku zdradza, ile przeglądarka spędza na wykonywaniu skryptów. Wysoka wartość przy dobrym LCP oznacza, że treść pojawia się szybko, ale strona jest przez chwilę martwa.

Te trzy liczby wskazują warstwę, którą trzeba ruszyć: serwer, zasoby albo skrypty.

Wskaźniki mają to do siebie, że psują się same, bez żadnej awarii. Wystarczy kilka miesięcy dodawania treści.

Najczęstsze przyczyny regresu to zdjęcia wgrywane prosto z aparatu, kolejne narzędzie marketingowe dołożone do witryny i wtyczka dokładająca skrypty na wszystkich podstronach. Każda z osobna kosztuje niewiele, razem przywracają stan sprzed optymalizacji.

Sensowna profilaktyka to trzy rzeczy: instrukcja dla osoby dodającej treści, przegląd raportu Core Web Vitals raz na kwartał i zasada, że każde nowe narzędzie zewnętrzne wchodzi dopiero po pomiarze przed i po.

Robimy to w ramach stałej opieki nad stroną WordPress, razem z aktualizacjami i monitoringiem. Jeśli chcesz zacząć od sprawdzenia stanu, napisz przez formularz na stronie kontakt - analizę PageSpeed odsyłamy w ciągu 24 godzin.

Core Web Vitals są jednym z sygnałów rankingowych, ale nie najważniejszym. Strona z gorszymi wskaźnikami i lepszą treścią zwykle wygrywa z szybką stroną bez wartości.

Praktyczne znaczenie jest inne i większe: wskaźniki opisują to, co przeżywa użytkownik. Wolne wczytywanie i skaczący układ zwiększają odsetek osób, które wychodzą przed obejrzeniem oferty, a to przekłada się na sprzedaż niezależnie od pozycji.

Rozsądny cel to zaliczenie progów na urządzeniach mobilnych, a nie wynik 100 w narzędziu. Ostatnie kilkanaście punktów kosztuje zwykle więcej pracy niż całe wcześniejsze przyspieszenie i bywa okupione wyłączeniem funkcji, które sprzedają.

Sama optymalizacja to zwykle jeden do dwóch tygodni pracy, zależnie od tego, ile warstw trzeba ruszyć. Na aktualizację danych w Search Console trzeba potem poczekać pełne okno 28 dni.

Według naszego cennika podstawowa optymalizacja, czyli cache, obrazy i minifikacja, to 500-1500 zł. Dane z większych wdrożeń, gdzie dochodzi analiza skryptów, czcionek i zmiana hostingu, pokazują 2000-5000 zł.

Bezpłatną analizę PageSpeed robimy w ciągu 24 godzin i na jej podstawie widać, czy problem leży w serwerze, w obrazach czy w skryptach. To decyduje o zakresie i cenie.

Nie goń za wynikiem 100. To narzędzie diagnostyczne, nie cel.

Nie włączaj wszystkich opcji wtyczki optymalizującej naraz. Łączenie plików i opóźnianie skryptów potrafią zepsuć suwaki, formularze i koszyk, a przy dziesięciu przełącznikach naraz nie wiadomo, który zawinił.

Nie usuwaj narzędzi analitycznych bez sprawdzenia, kto z nich korzysta. Lepszym ruchem jest odłożenie ich ładowania niż wycięcie danych, na których ktoś opiera decyzje.

Nie oceniaj efektu po jednym pomiarze. Wyniki w narzędziu wahają się o kilka punktów bez żadnej zmiany na stronie, więc rozstrzygają serie i dane od prawdziwych użytkowników.