Core Web Vitals to trzy wskaźniki, którymi Google opisuje wygodę korzystania ze strony: jak szybko pojawia się jej główna treść, jak sprawnie strona reaguje na działanie użytkownika i czy układ nie przesuwa się w trakcie czytania. Wyniki są dostępne dla każdego właściciela witryny, ale ich odczytanie sprawia kłopot. W jednym narzędziu strona dostaje ocenę „dobrze”, w drugim czerwony wynik punktowy, a w trzecim nie ma żadnych danych.
Źródłem zamieszania jest zwykle to, że obok siebie pokazywane są dwa różne rodzaje pomiarów: dane zebrane od prawdziwych odwiedzających i wynik jednorazowego testu w sztucznych warunkach. Kto ich nie rozróżnia, ten poprawia nie to, co trzeba, albo ogłasza sukces po zmianie, której użytkownicy w ogóle nie odczuli.
Poniżej opisuję, co dokładnie mierzą trzy wskaźniki, jakie progi stosuje Google, jak czytać raporty i od czego zacząć naprawę, żeby praca przyniosła widoczny skutek, a nie tylko ładniejszą liczbę w teście.
Co mierzą trzy wskaźniki Core Web Vitals?
Google wybrało trzy pomiary, ponieważ każdy z nich opisuje inną chwilę wizyty. Pierwszy dotyczy wczytywania, drugi reakcji na działanie, trzeci stabilności tego, co widać na ekranie. Strona może wypadać bardzo dobrze w jednym i słabo w pozostałych, dlatego nie należy ich uśredniać ani traktować jako jednej oceny.
LCP, czyli kiedy widać główną treść
LCP (Largest Contentful Paint) to czas od rozpoczęcia wczytywania strony do wyświetlenia największego elementu widocznego na ekranie bez przewijania. Najczęściej jest to duże zdjęcie na górze strony, grafika produktu albo blok tekstu z nagłówkiem. Wskaźnik odpowiada na proste pytanie odwiedzającego: kiedy widać to, po co przyszedł.
INP, czyli jak szybko strona reaguje
INP (Interaction to Next Paint) mierzy czas między działaniem użytkownika a chwilą, w której ekran pokazuje skutek tego działania. Pod uwagę brane są kliknięcia, dotknięcia ekranu i naciśnięcia klawiszy, natomiast samo przewijanie do nich nie należy. Wskaźnik obserwuje całą wizytę i wybiera jedną z najwolniejszych reakcji, pomijając pojedyncze skrajne przypadki.
W praktyce słaby INP odczuwa się tak: po dotknięciu przycisku menu nic się nie dzieje, użytkownik dotyka ponownie, a po chwili menu otwiera się i od razu zamyka. Strona wygląda na gotową, ale nie odpowiada, ponieważ przeglądarka jest zajęta wykonywaniem skryptów.
CLS, czyli czy układ stoi w miejscu
CLS (Cumulative Layout Shift) opisuje, jak bardzo elementy strony przesuwają się niespodziewanie podczas wizyty. Wynik nie jest podawany w sekundach, lecz jako liczba bez jednostki, która łączy wielkość przesuwanego obszaru z odległością przesunięcia. Im bliżej zera, tym stabilniejszy układ.
Każdy zna to z własnego doświadczenia: tekst nagle zjeżdża w dół, bo nad nim wczytał się baner, albo palec trafia w inny przycisk, niż zamierzał. Przesunięcia, które następują tuż po działaniu użytkownika, na przykład rozwinięcie listy po kliknięciu, nie są liczone, ponieważ są oczekiwane.
Jakie progi Google uznaje za dobre, a jakie za słabe?
Dla każdego wskaźnika Google wyznaczyło dwa progi, które dzielą wyniki na trzy oceny: „dobrze”, „wymaga poprawy” i „słabo”. Wartości są stałe i takie same dla telefonów i komputerów. Wyglądają następująco:
- LCP: dobrze do 2,5 sekundy, wymaga poprawy powyżej 2,5 do 4 sekund, słabo powyżej 4 sekund.
- INP: dobrze do 200 milisekund, wymaga poprawy powyżej 200 do 500 milisekund, słabo powyżej 500 milisekund.
- CLS: dobrze do 0,1, wymaga poprawy powyżej 0,1 do 0,25, słabo powyżej 0,25.
Sama znajomość progów nie wystarcza, bo trzeba jeszcze wiedzieć, do jakiej liczby są przykładane. Google nie liczy średniej ze wszystkich wizyt. Stosuje zasadę 75. percentyla: ustawia wizyty od najszybszej do najwolniejszej i bierze wynik tej, która wypada na trzech czwartych kolejki.
Oznacza to, że strona zalicza wskaźnik dopiero wtedy, gdy co najmniej trzy na cztery wizyty mieszczą się w progu „dobrze”. Zasada jest stosowana osobno dla telefonów i osobno dla komputerów. Dzięki temu ocena nie zależy od garstki osób z najnowszym sprzętem i szybkim łączem, tylko od doświadczenia zdecydowanej większości odwiedzających.
Ma to praktyczną konsekwencję. Właściciel firmy ogląda swoją stronę zwykle w biurze, na dobrym komputerze i z szybkim internetem, więc wszystko działa sprawnie. Tymczasem o ocenie decydują także ci, którzy otwierają stronę na kilkuletnim telefonie, w pociągu albo na słabym zasięgu. To oni najczęściej wypadają poza próg.
Dane od prawdziwych użytkowników a test laboratoryjny: skąd różnice?
Większość nieporozumień bierze się z mieszania dwóch rodzajów danych. Pierwsze to dane terenowe, czyli pomiary zbierane podczas zwykłych wizyt osób korzystających z przeglądarki Chrome, które wyraziły zgodę na udostępnianie statystyk. Drugie to dane laboratoryjne, czyli wynik jednego testu wykonanego przez narzędzie w ustalonych z góry warunkach.
Dane terenowe widać w raporcie w Google Search Console oraz w górnej części wyniku PageSpeed Insights, w części opisującej doświadczenia rzeczywistych użytkowników. To one służą Google do oceny strony. Dane laboratoryjne pochodzą z narzędzia Lighthouse, które działa między innymi w dolnej części PageSpeed Insights oraz w narzędziach dla programistów w przeglądarce Chrome.
Dlaczego te same wskaźniki pokazują inne liczby?
Test laboratoryjny wczytuje stronę jeden raz, udając telefon ze średniej półki na wolniejszym łączu, bez zapisanych wcześniej plików i bez żadnego działania ze strony użytkownika. Dane terenowe są natomiast sumą tysięcy wizyt na różnych urządzeniach, w różnych sieciach, często u osób, które wracają na stronę i część plików mają już zapisaną w przeglądarce.
Z tego powodu wynik laboratoryjny bywa surowszy od terenowego, zwłaszcza w przypadku LCP. Zdarza się też sytuacja odwrotna: test wypada dobrze, a dane od użytkowników słabo. Dotyczy to szczególnie CLS, ponieważ test ocenia tylko pierwszy ekran tuż po wczytaniu, a prawdziwy użytkownik przewija stronę i trafia na przesunięcia, których narzędzie nie widziało.
Osobną sprawą jest INP. Tego wskaźnika nie da się uczciwie zmierzyć w zwykłym teście, bo narzędzie niczego na stronie nie klika. Lighthouse podaje w zamian łączny czas blokowania, czyli informację, jak długo przeglądarka była zajęta i nie mogła odpowiedzieć. To dobra wskazówka, ale nie ten sam pomiar.
Dlaczego wynik punktowy to nie to samo, co zaliczone wskaźniki?
Kolorowe koło z liczbą od 0 do 100 przyciąga wzrok najmocniej i dlatego najczęściej wprowadza w błąd. Ten wynik powstaje wyłącznie z danych laboratoryjnych. Jest ważoną oceną kilku pomiarów z jednego testu, wśród których są także takie, które do Core Web Vitals nie należą. INP nie wchodzi do niego wcale.
Możliwe są więc obie skrajności. Strona z wynikiem punktowym w okolicach połowy skali może mieć wszystkie trzy wskaźniki zaliczone u prawdziwych użytkowników. Strona z wynikiem bliskim maksimum może nie zaliczać INP, bo po wczytaniu uruchamia ciężkie skrypty, których test nie wywołał.
Moim zdaniem należy go traktować jak wskazówkę przy szukaniu przyczyn, a nie jak cel. O tym, czy strona jest w porządku, rozstrzygają dane terenowe z ostatnich tygodni.
Jak czytać raport „Podstawowe wskaźniki internetowe” w Search Console?
Raport w Google Search Console jest najwygodniejszym miejscem do oceny całego serwisu, ponieważ pokazuje wyłącznie dane od prawdziwych użytkowników i obejmuje wszystkie adresy, dla których zebrano wystarczająco dużo pomiarów. Składa się z dwóch osobnych części: dla telefonów i dla komputerów. Należy czytać je oddzielnie, bo ta sama strona często zalicza wskaźniki na komputerze, a nie zalicza na telefonie.
Grupy adresów zamiast pojedynczych stron
Raport nie wymienia każdego adresu z osobna. Łączy strony o podobnej budowie w grupy i dla każdej grupy podaje jeden wynik oraz kilka przykładowych adresów. W sklepie internetowym osobną grupę tworzą zazwyczaj karty produktów, osobną listy kategorii, osobną wpisy na blogu.
To bardzo pomocne, bo problem prawie zawsze tkwi w szablonie, a nie w pojedynczej stronie. Jeśli grupa kilkuset kart produktów ma słaby LCP, nie trzeba poprawiać kilkuset stron, tylko jeden szablon karty produktu. Po kliknięciu w grupę warto otworzyć dwa lub trzy przykładowe adresy i sprawdzić, co mają wspólnego.
Ocenę grupy wyznacza jej najsłabszy wskaźnik. Grupa, która ma dobry INP, LCP wymagający poprawy i słaby CLS, trafia do kategorii „słabo”. Raport wskazuje przy tym, który wskaźnik jest przyczyną, więc od razu wiadomo, czego szukać.
Okno 28 dni, czyli dlaczego poprawy nie widać od razu
Dane w raporcie obejmują okres około 28 ostatnich dni i są przeliczane na bieżąco. Jeśli poprawka została wdrożona wczoraj, w wyniku nadal dominują wizyty sprzed zmiany. Linia na wykresie zaczyna się przesuwać stopniowo, a pełny skutek widać dopiero po upływie całego okresu.
Z tego samego powodu nie ma sensu sprawdzać raportu codziennie ani wyciągać wniosków po trzech dniach. Po wdrożeniu poprawki można w raporcie zgłosić ją do sprawdzenia. Google obserwuje wtedy grupę przez kolejne 28 dni i dopiero po tym czasie potwierdza, że problem zniknął, albo informuje, że nadal występuje.
Kto na tym etapie woli nie zajmować się tym samodzielnie, może po prostu zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl. Chętnie przejmę sprawę: odczytam wyniki Core Web Vitals, wskażę przyczyny i ustalę kolejność poprawek.
Jaki jest realny wpływ na pozycje i na sprzedaż?
Wokół Core Web Vitals narosło sporo przesady, dlatego wolę postawić sprawę jasno. Wskaźniki są jednym z wielu sygnałów, które Google bierze pod uwagę przy ustalaniu kolejności wyników. Nie są sygnałem najważniejszym. Google samo podkreśla, że dobre wyniki nie gwarantują wysokich pozycji, a strona z lepszą, trafniejszą treścią może wyprzedzić szybszego konkurenta.
W praktyce szybkość nie zastąpi treści, struktury serwisu ani linków. Jeśli strona nie odpowiada na pytanie, z którym przychodzi użytkownik, zaliczenie trzech wskaźników niczego nie zmieni. Znaczenie rośnie wtedy, gdy kilka stron odpowiada na zapytanie podobnie dobrze. Wówczas wygoda korzystania może przeważyć.
Z tego powodu poprawę wskaźników warto planować jako część szerszych prac, a nie zamiast nich. Kolejność działań najlepiej ustalić po całościowym przeglądzie, o czym piszę szerzej we wpisie o tym, co sprawdzić w audycie SEO i w jakiej kolejności.
Znacznie pewniejszy jest wpływ na sprzedaż i liczbę zapytań. Tu nie trzeba żadnych obliczeń, wystarczy obserwacja. Osoba, która czeka kilka sekund na zdjęcie produktu, wraca do wyników i wybiera kolejną stronę. Osoba, której przycisk „do koszyka” nie reaguje, rezygnuje z zakupu. Osoba, której formularz przesunął się pod palcem, wysyła go z błędem albo nie wysyła wcale.
Co najczęściej psuje LCP i jak to naprawić?
Zanim zacznie się cokolwiek zmieniać, trzeba ustalić, który element jest na danej stronie tym największym. PageSpeed Insights wskazuje go wprost w części z diagnozą, pokazuje też, na co składa się czas oczekiwania: odpowiedź serwera, opóźnienie przed rozpoczęciem pobierania, samo pobieranie i narysowanie elementu. Bez tej wiedzy łatwo poprawiać nie to, co trzeba.
Ciężki obraz na górze strony
To przyczyna najczęstsza. Na górze strony stoi duże zdjęcie albo pokaz slajdów, zapisane w rozmiarze znacznie większym, niż potrzebuje ekran telefonu, często w starszym formacie. Naprawa polega na trzech rzeczach: przygotowaniu obrazu w kilku rozmiarach, tak aby telefon pobierał mniejszą wersję, zapisaniu go w nowoczesnym formacie, takim jak WebP lub AVIF, oraz rozsądnym stopniu kompresji.
Druga część problemu to kolejność pobierania. Przeglądarka powinna dowiedzieć się o głównym obrazie jak najwcześniej i potraktować go jako najważniejszy. Tymczasem często jest on objęty odroczonym wczytywaniem, które ma sens tylko dla zdjęć położonych niżej. Główny obraz pierwszego ekranu należy z odroczonego wczytywania wyłączyć i oznaczyć jako zasób o wysokim priorytecie.
Częstym błędem jest też umieszczanie głównego zdjęcia jako tła w arkuszu stylów albo wstawianie go dopiero przez skrypt. Przeglądarka odkrywa je wtedy późno, po pobraniu i przetworzeniu innych plików. Zwykły znacznik obrazu w kodzie strony działa pod tym względem najlepiej. Pokaz slajdów na górze strony radzę zastąpić jednym dobrze przygotowanym zdjęciem.
Wolna odpowiedź serwera
Jeśli serwer długo zwleka z wysłaniem pierwszych danych strony, na resztę zostaje niewiele czasu. Przyczyną bywa tani, przeciążony hosting, brak pamięci podręcznej, przez co każda wizyta wymaga budowania strony od zera, albo powolne zapytania do bazy danych.
Naprawę zaczyna się od włączenia pamięci podręcznej całych stron, tak aby serwer wysyłał gotowy dokument. Kolejne kroki to aktualna wersja oprogramowania serwera, uporządkowanie bazy oraz, przy ruchu z wielu regionów, sieć serwerów pośredniczących, która przechowuje pliki bliżej odwiedzających. Jeśli mimo to odpowiedź pozostaje wolna, zmiana hostingu jest uzasadnionym wydatkiem.
Style i skrypty, które blokują wyświetlanie
Przeglądarka nie narysuje niczego, dopóki nie pobierze i nie przetworzy arkuszy stylów oraz skryptów umieszczonych w nagłówku strony. Gdy jest ich kilkanaście, w tym takie, które służą funkcjom używanym na innych podstronach, pierwszy ekran czeka bez potrzeby.
Rozwiązaniem jest porządek: wczytywanie tylko tych stylów, których dana strona naprawdę używa, opóźnienie skryptów niepotrzebnych do pokazania pierwszego ekranu oraz usunięcie tych, z których nikt już nie korzysta. Sama zmiana kolejności potrafi dać więcej niż wymiana serwera.
Czcionki
Gdy największym elementem jest nagłówek lub akapit, o wyniku decydują czcionki. Jeśli przeglądarka czeka z pokazaniem tekstu do chwili pobrania pliku czcionki, użytkownik patrzy na pustą przestrzeń. Należy ustawić wyświetlanie tak, aby tekst pojawiał się od razu czcionką zastępczą, a właściwa podmieniała ją po wczytaniu.
Skąd bierze się słaby INP i co z nim zrobić?
Przeglądarka wykonuje skrypty strony w jednej kolejce. Dopóki trwa długie zadanie, kliknięcie użytkownika czeka na swoją kolej. Słaby INP oznacza więc prawie zawsze jedno: na stronie działa za dużo kodu albo kod jest napisany tak, że zajmuje przeglądarkę na długie, nieprzerwane odcinki czasu.
Ciężkie skrypty i nadmiar wtyczek
Każda wtyczka, każdy efekt wizualny i każda rozbudowana biblioteka dokładają swoją część. Pojedynczo żadna nie szkodzi, razem tworzą ciężar, z którym przeciętny telefon sobie nie radzi. Szczególnie kosztowne są rozbudowane kreatory stron, animacje uruchamiane przy przewijaniu, pokazy slajdów i filtry produktów przeliczające całą listę po każdym kliknięciu.
Pierwszym krokiem jest przegląd tego, co na stronie naprawdę jest potrzebne. Wtyczki nieużywane należy wyłączyć i odinstalować. Skrypty potrzebne tylko na wybranych podstronach, na przykład obsługa formularza kontaktowego, powinny wczytywać się wyłącznie tam. To, co zostaje, programista może podzielić na krótsze zadania, między którymi przeglądarka zdąży odpowiedzieć użytkownikowi.
Kody zewnętrzne: statystyki, reklamy, czaty i mapy
Drugą dużą grupę stanowią kody dostarczane przez inne firmy: narzędzia statystyczne, kody reklamowe, nagrywanie sesji, okna czatu, osadzone mapy i filmy, przyciski serwisów społecznościowych. Właściciel strony nie ma wpływu na ich jakość, a często nie wie nawet, ile ich jest, bo przez lata dokładały je kolejne osoby.
Warto zrobić spis wszystkich takich kodów i przy każdym zadać pytanie, kto w firmie korzysta z danych, które zbiera. Kody po zakończonych kampaniach i porzuconych narzędziach należy usunąć. Pozostałe można uruchamiać z opóźnieniem, po wczytaniu strony albo dopiero po zgodzie użytkownika.
Okno czatu i mapę najlepiej wczytywać na żądanie. W miejscu mapy wystarczy obraz z adresem i przyciskiem, a właściwa mapa pojawia się po kliknięciu. Podobnie czat: ikona jest lekka, a cały mechanizm uruchamia się dopiero wtedy, gdy ktoś chce napisać. Użytkownik nie traci żadnej funkcji, a strona przestaje dźwigać ciężar, z którego większość odwiedzających nie korzysta.
Dlaczego układ strony się przesuwa? Przyczyny słabego CLS
Przesunięcia układu mają jedną wspólną przyczynę: przeglądarka nie wie z góry, ile miejsca zajmie element, który dopiero się wczyta. Rysuje więc stronę bez niego, a po jego pojawieniu się musi rozsunąć wszystko, co leży niżej. Naprawa polega niemal zawsze na tym samym, czyli na zarezerwowaniu miejsca zawczasu.
Obrazy i filmy bez podanych wymiarów
Jeśli w kodzie obrazu brakuje szerokości i wysokości, przeglądarka do chwili pobrania pliku przyjmuje, że obraz nie zajmuje nic. Gdy plik dotrze, tekst pod nim przeskakuje w dół. Wystarczy podać wymiary każdego obrazu w kodzie, a przeglądarka sama obliczy proporcje i zostawi odpowiednią przestrzeń, także na wąskim ekranie telefonu.
Reklamy, banery i paski wstawiane po wczytaniu
Pasek z promocją nad nagłówkiem, zachęta do zapisania się na listę odbiorców, baner reklamowy w środku tekstu: jeśli pojawiają się z opóźnieniem i odpychają treść, każdy z nich pogarsza wynik. Rozwiązania są dwa. Można zarezerwować dla nich stałe miejsce w układzie albo wyświetlać je jako warstwę nałożoną na stronę, która niczego nie przesuwa.
Czcionki zmieniające szerokość tekstu
Podmiana czcionki zastępczej na docelową, zalecana przy LCP, ma swoją cenę. Jeśli obie różnią się szerokością znaków, tekst po podmianie łamie się inaczej i nagłówek z dwóch wierszy robi się trzywierszowy. Rozwiązaniem jest dobranie czcionki zastępczej o zbliżonych proporcjach i dopasowanie jej wielkości, tak aby zamiana była prawie niewidoczna.
Baner zgód na pliki cookie
Baner zgód jest obowiązkowym elementem wielu stron i częstym winowajcą. Jeśli wsuwa się na górę strony i spycha całą treść, powoduje duże przesunięcie przy każdej pierwszej wizycie. Powinien być wyświetlany jako warstwa nad stroną, zwykle u dołu ekranu lub na środku, bez zmiany położenia treści.
Od czego zacząć prace i jak sprawdzić, czy poprawka zadziałała?
Lista zaleceń z narzędzi bywa długa i łatwo utknąć na drobiazgach. Dobra kolejność prac opiera się na dwóch prostych pytaniach: gdzie jest najwięcej użytkowników i która poprawka da im najwięcej.
Najpierw szablony z największym ruchem
Punktem wyjścia jest raport w Search Console dla telefonów. Należy wypisać grupy adresów z oceną „słabo” i „wymaga poprawy”, a następnie zestawić je z ruchem i ze znaczeniem dla sprzedaży. Szablon karty produktu, strona usługi czy strona główna są ważniejsze od archiwum wpisów sprzed lat.
W obrębie wybranego szablonu zaczyna się od wskaźnika najdalszego od progu oraz od przyczyny, która ma największy udział. Jedno zbyt ciężkie zdjęcie na górze strony albo brak pamięci podręcznej znaczą zwykle więcej niż dziesięć drobnych zaleceń razem wziętych. Drobiazgi zostawia się na koniec albo pomija.
- Wybór szablonu z największym ruchem i słabą oceną na telefonach.
- Ustalenie, który wskaźnik odstaje i co jest jego główną przyczyną.
- Wdrożenie jednej poprawki naraz, najpierw na kopii testowej strony.
- Test laboratoryjny przed zmianą i po niej, w tych samych warunkach.
- Obserwacja danych terenowych przez kolejne tygodnie.
Gdy naraz wdraża się pięć poprawek, nie wiadomo, która pomogła, a która coś zepsuła. Większą przebudowę szablonów lub zmianę serwera warto zaplanować równie starannie jak przenosiny serwisu, które opisałem we wpisie o migracji strony bez utraty pozycji w Google.
Sprawdzenie od razu: test laboratoryjny
Skutek poprawki można wstępnie ocenić tego samego dnia. Wystarczy kilka razy uruchomić test w PageSpeed Insights dla tej samej strony przed zmianą i po niej oraz porównać wyniki środkowe, a nie najlepsze. Patrzy się przy tym na konkretne wskaźniki, czyli na LCP, CLS i łączny czas blokowania, a nie na wynik punktowy.
Równie ważna jest zwykła próba na telefonie, najlepiej starszym i z wyłączoną siecią bezprzewodową. Należy otworzyć stronę, przewinąć ją do końca, rozwinąć menu, dodać produkt do koszyka i wypełnić formularz. Jeśli coś się przesuwa albo reaguje z opóźnieniem, będzie to widać bez żadnego narzędzia.
Potwierdzenie po czasie: dane terenowe
Ostateczną odpowiedź dają dane od użytkowników. Część terenowa w PageSpeed Insights i raport w Search Console pokazują okres około 28 dni, więc pierwsze drgnięcie widać po kilku lub kilkunastu dniach, a pełny wynik po miesiącu. W raporcie Search Console warto zgłosić poprawkę do sprawdzenia i poczekać na potwierdzenie.
Na co zwrócić uwagę w WordPressie?
WordPress sam w sobie nie jest wolny. Spowalniają go decyzje podejmowane po drodze: ciężki motyw z dziesiątkami funkcji, z których używa się trzech, kreator stron generujący bardzo rozbudowany kod, kilkadziesiąt wtyczek i hosting dobrany wyłącznie według ceny. Sposób ustalenia, który z tych elementów szkodzi najbardziej, opisałem osobno we wpisie o tym, jak sprawdzić, co spowalnia WordPressa.
Z punktu widzenia trzech wskaźników najwięcej dają cztery rzeczy. Pierwsza to wtyczka pamięci podręcznej dopasowana do serwera i poprawnie ustawiona. Druga to automatyczne przygotowywanie obrazów w kilku rozmiarach i w nowoczesnym formacie. Trzecia to wyłączenie odroczonego wczytywania dla głównego zdjęcia pierwszego ekranu, bo wiele wtyczek obejmuje nim wszystkie obrazy bez wyjątku. Czwarta to ograniczenie liczby wtyczek do tych naprawdę potrzebnych.
Ostrożność jest wskazana przy funkcjach łączenia, zmniejszania i opóźniania skryptów. Potrafią wyraźnie pomóc, ale ustawione zbyt śmiało psują menu, formularze, koszyk albo kody statystyk. Każdą taką opcję należy włączać osobno i po każdej zmianie sprawdzić najważniejsze ścieżki na stronie, w tym złożenie zamówienia i wysłanie zapytania.
Czego nie robić przy poprawianiu wskaźników?
Najczęstszym błędem jest pogoń za wynikiem 100 punktów. Ostatnie kilkanaście punktów kosztuje zwykle najwięcej pracy, a użytkownik nie odczuwa żadnej różnicy. Celem jest zaliczenie trzech wskaźników w danych terenowych na telefonach i komputerach. Po jego osiągnięciu czas i pieniądze lepiej przeznaczyć na treść i ofertę.
Drugim błędem jest wyłączanie funkcji, które są firmie potrzebne. Usunięcie czatu, przez który przychodzi wiele zapytań, albo statystyk, na podstawie których ocenia się reklamy, poprawi wynik w teście i pogorszy wynik firmy. Potrzebne funkcje należy odciążać i opóźniać, a nie usuwać.
- Nie warto oceniać strony po jednym teście ani po wyniku na własnym komputerze.
- Nie należy wdrażać zmian od razu na działającej stronie, bez kopii zapasowej i wersji testowej.
- Nie należy ukrywać treści przed narzędziem ani podawać mu innej wersji strony niż użytkownikom.
- Nie warto ufać ofertom obiecującym zielony wynik w jeden dzień bez wglądu w kod strony.
Osobnej uwagi wymagają rozmaite „przyspieszacze”, czyli wtyczki i usługi, które obiecują natychmiastową poprawę po jednym kliknięciu. Część z nich opóźnia wszystkie skrypty do pierwszego ruchu użytkownika. Test, który niczego nie klika, pokazuje wtedy znakomity wynik, a prawdziwy odwiedzający przy pierwszym dotknięciu ekranu czeka, aż wszystko uruchomi się naraz. Wynik laboratoryjny rośnie, INP w danych terenowych się pogarsza.
Najczęstsze pytania
Czy strona musi mieć zaliczone wszystkie trzy wskaźniki?
Tak, ocena całości jest pozytywna dopiero wtedy, gdy LCP, INP i CLS jednocześnie mieszczą się w progu „dobrze”. Ocena jest ustalana osobno dla telefonów i osobno dla komputerów, więc strona może zaliczać wskaźniki na jednym rodzaju urządzeń, a na drugim nie. Jeden słaby wynik obniża ocenę całej grupy adresów. Dlatego pracę zaczyna się od wskaźnika, który odstaje najbardziej.
Dlaczego PageSpeed Insights pokazuje słaby wynik, a Search Console ocenę „dobrze”?
Oba narzędzia mogą mieć rację, ponieważ mówią o czymś innym. Wynik punktowy w PageSpeed Insights pochodzi z jednego testu w trudnych, sztucznych warunkach, a raport w Search Console z prawdziwych wizyt z około 28 dni. Jeśli dane od użytkowników są dobre, strona spełnia wymagania Google. Wynik testu warto wtedy traktować jako listę możliwych usprawnień, a nie jako alarm.
Po jakim czasie od poprawki zmieni się raport w Search Console?
Raport obejmuje około 28 ostatnich dni, więc przez pierwsze dni po zmianie w wyniku nadal przeważają starsze wizyty. Pierwsze oznaki poprawy pojawiają się zwykle po kilku lub kilkunastu dniach. Pełny skutek jest widoczny po upływie całego okresu. Sprawdzenie poprawki zgłoszone w raporcie również trwa 28 dni.
Co oznacza brak danych w raporcie?
Brak danych oznacza, że strona ma zbyt mało wizyt z przeglądarki Chrome, aby Google mogło wiarygodnie policzyć wskaźniki. Nie jest to błąd ani kara i nie wpływa negatywnie na ocenę witryny. W takiej sytuacji pozostają testy laboratoryjne oraz własne próby na telefonie. Dane pojawią się same, gdy ruch na stronie wzrośnie.
Czy poprawa Core Web Vitals podniesie pozycje w Google?
Może pomóc, ale nie należy oczekiwać dużej zmiany po samej poprawie szybkości. Wskaźniki są jednym z wielu sygnałów i ustępują znaczeniem trafności oraz jakości treści. Najwięcej znaczą wtedy, gdy konkurencyjne strony odpowiadają na zapytanie podobnie dobrze. Pewniejszą korzyścią jest wygoda użytkowników, która przekłada się na zapytania i zamówienia.
Który wskaźnik poprawiać jako pierwszy?
Ten, który w danych terenowych dla telefonów ma najgorszą ocenę na najczęściej odwiedzanych szablonach. W wielu serwisach jest to LCP, a jego poprawa zwykle sprowadza się do głównego obrazu i czasu odpowiedzi serwera. CLS bywa najprostszy do naprawy, bo często wystarcza podanie wymiarów obrazów i uporządkowanie banerów. INP wymaga najwięcej pracy programisty, ponieważ dotyczy skryptów.
Brak czasu albo ochoty, żeby zająć się tym samodzielnie?
To zupełnie zrozumiałe. Opisane czynności wymagają spokoju i kilku wolnych godzin, a w firmie zwykle brakuje jednego i drugiego. Chętnie zrobię to od początku do końca: odczytam wyniki Core Web Vitals, wskażę przyczyny i ustalę kolejność poprawek.
Wystarczy zadzwonić pod numer 533 525 168 albo napisać na adres info@lukaszwudyka.pl i w kilku zdaniach opisać sprawę. Odpowiadam osobiście i od razu mówię, co da się zrobić.
