Pomiar szybkości strony: dlaczego wynik testu różni się od danych od użytkowników

Czym różni się pomiar laboratoryjny od danych od użytkowników

Pomiar laboratoryjny powstaje wtedy, gdy narzędzie samo otwiera stronę w kontrolowanym środowisku, a dane od użytkowników powstają wtedy, gdy przeglądarki prawdziwych odwiedzających zapisują, jak strona zachowała się u nich. Pierwszy rodzaj danych daje powtarzalny wynik jednej próby, drugi pokazuje rozkład wielu różnych doświadczeń. W dokumentacji Google oba rodzaje mają ustalone nazwy: dane laboratoryjne (ang. lab data) oraz dane z rzeczywistego użytkowania, nazywane też danymi terenowymi (ang. field data).

Zespół Chrome w serwisie web.dev opisuje to wprost w opracowaniu o różnicach między danymi laboratoryjnymi a terenowymi: test laboratoryjny ma dawać spójny, odtwarzalny wynik, natomiast dane terenowe nie są jedną liczbą, tylko rozkładem. Jedni odwiedzający mają nowy telefon i szybkie łącze domowe, inni kilkuletni aparat i słaby zasięg w pociągu. W tym samym opracowaniu podano przykład strony, u której 75. percentyl czasu LCP u użytkowników wynosił 1,8 sekundy, a pomiar laboratoryjny pokazał 3,0 sekundy. Obie liczby były prawdziwe, tylko odpowiadały na inne pytania.

Nie wszystkie wskaźniki da się zmierzyć w obu trybach. Czas reakcji na działanie odwiedzającego, czyli INP, wymaga prawdziwego kliknięcia lub dotknięcia ekranu, dlatego w teście zastępuje go wskaźnik TBT (łączny czas blokowania). Szerzej opisujemy to we wpisie o tym, dlaczego strona reaguje z opóźnieniem na kliknięcie.

Skąd pochodzą dane od użytkowników i kogo obejmują

Dane od użytkowników w narzędziach Google pochodzą z raportu CrUX, do którego trafiają pomiary z przeglądarki Chrome tylko od części odwiedzających. Według metodologii raportu na temat użytkowania Chrome pomiar jest uwzględniany, gdy osoba korzystająca z przeglądarki ma włączone raportowanie statystyk użytkowania, synchronizuje historię przeglądania, nie ustawiła hasła synchronizacji i używa obsługiwanej platformy.

Obsługiwane platformy to Chrome na komputerach z systemami Windows, macOS, ChromeOS i Linux oraz Chrome na Androidzie. Poza zbiorem pozostaje Chrome na iOS, aplikacje na Androida wyświetlające strony w oknie wbudowanym (WebView), a także inne przeglądarki, w tym te zbudowane na tym samym silniku co Chrome. Jeśli więc większość klientów sklepu z Poznania kupuje z telefonów z systemem iOS, to ich wizyt w tych danych nie ma, a obraz dotyczy pozostałej części ruchu.

Strona również musi spełnić warunki. Metodologia wymienia dwa podstawowe: adres ma być publicznie dostępny na takich zasadach, jakie stosują wyszukiwarki, oraz mieć wystarczającą liczbę odwiedzających. Dokładnego progu Google nie podaje. Adresy wyłączone z indeksowania są pomijane. Dane zbiera się na dwóch poziomach: dla pojedynczego adresu oraz dla całej witryny w obrębie jednego protokołu i hosta, co w dokumentacji nazywa się źródłem (ang. origin).

Okno 28 dni i 75. percentyl

Dane od użytkowników zawsze opisują ostatnie 28 dni i są przedstawiane jako 75. percentyl. Dokumentacja narzędzia PageSpeed Insights wyjaśnia, że ten percentyl wybrano po to, aby pokazać także mniej udane wizyty i upewnić się, że strona działa dobrze również w trudniejszych warunkach sprzętowych i sieciowych. Jeśli więc 75. percentyl LCP wynosi 2,4 sekundy, oznacza to, że trzy czwarte wizyt miało ten czas nie gorszy, a pozostała jedna czwarta dłuższy.

Z okna 28 dni wynika rzecz, która często zaskakuje właścicieli stron. Po wdrożeniu poprawki dane nie zmieniają się z dnia na dzień, ponieważ w zbiorze nadal znajdują się wizyty sprzed zmiany. Pełny obraz widać dopiero wtedy, gdy miną cztery tygodnie i stare pomiary wypadną z okna.

Gdzie sprawdzić oba rodzaje danych

Oba rodzaje danych najwygodniej porównać w PageSpeed Insights, ponieważ to narzędzie pokazuje je na jednym ekranie, a obraz całej witryny daje raport w Google Search Console. Sam test laboratoryjny można też uruchomić w przeglądarce Chrome za pomocą Lighthouse. Wszystkie trzy narzędzia są dostępne bez opłat.

PageSpeed Insights: dwa bloki w jednym raporcie

Po wpisaniu adresu i uruchomieniu analizy raport PageSpeed Insights układa się w dwie części. Górna zawiera dane z rzeczywistego użytkowania: wskaźniki LCP, INP i CLS, a obok nich FCP oraz eksperymentalnie TTFB, razem z informacją, czy ocena podstawowych wskaźników internetowych jest zaliczona. Dolna część to wynik Lighthouse: punktacja wydajności od 0 do 100, wartości wskaźników z jednego symulowanego wczytania i lista zaleceń. Każdą część warto czytać osobno, bo liczby o tej samej nazwie, na przykład LCP, znaczą w nich co innego.

Dokumentacja narzędzia podaje, że ocena jest zaliczona, gdy 75. percentyl LCP, INP i CLS mieści się w przedziale dobrym. Jeśli danych o INP jest za mało, wystarczą dobre wartości LCP i CLS. Punktacja laboratoryjna ma własną skalę: od 90 punktów wynik uznaje się za dobry, od 50 do 89 za wymagający poprawy, a poniżej 50 za słaby. Ta sama dokumentacja zastrzega, że dobry wynik laboratoryjny nie gwarantuje równie dobrych wrażeń u prawdziwych odwiedzających.

Trzeba również zwrócić uwagę, czego dotyczy górna część raportu. Gdy dla wpisanego adresu jest za mało pomiarów, PageSpeed Insights pokazuje dane dla całej witryny, a gdy i tych brakuje, nie pokazuje danych od użytkowników wcale. Raport informuje, który z tych przypadków zachodzi. Kancelaria z Krakowa, która testuje mało odwiedzaną podstronę o prawie spadkowym, widzi więc w górnej części liczby wspólne dla całego serwisu, a w dolnej wynik tej jednej podstrony. Porównywanie ich wprost prowadzi do błędnych wniosków. Dokładne omówienie wszystkich pól zawiera nasz wpis o tym, jak czytać raport PageSpeed Insights.

Search Console: raport podstawowych wskaźników internetowych

W Google Search Console dane od użytkowników znajdują się w raporcie Podstawowe wskaźniki internetowe (w pomocy Google nazywanym też raportem dotyczącym Core Web Vitals), osobno dla urządzeń mobilnych i dla komputerów. Zgodnie ze stroną pomocy Search Console poświęconą temu raportowi jego jedynym źródłem jest CrUX, a więc nie ma w nim żadnych pomiarów laboratoryjnych. Wykres dzieli adresy na trzy karty: Słabej jakości, Wymagana poprawa i Dobrej jakości. Pod wykresem znajduje się tabela zatytułowana „Dlaczego adresy URL nie są uważane za prawidłowe”, a po wejściu w wybrany wiersz widać przykładowe adresy oraz kolumny z wartościami LCP grupy, INP grupy i CLS grupy.

Raport nie ocenia każdego adresu osobno. Search Console łączy podstrony o podobnym działaniu w grupy i przypisuje wartości wskaźników całej grupie, a status grupy odpowiada jej najgorszemu wskaźnikowi na danym typie urządzenia. Jeśli więc grupa ma słaby CLS i wymagający poprawy LCP, otrzymuje status słabej jakości. Lista adresów jest przykładowa, tabela szczegółów mieści najwyżej 200 wierszy, a sam raport, jak zaznacza pomoc Google, nie służy do ustalania stanu pojedynczego adresu. Do tego lepiej nadaje się PageSpeed Insights.

Lighthouse w przeglądarce Chrome

Lighthouse uruchomiony w przeglądarce daje wyłącznie pomiar laboratoryjny, wykonany na komputerze osoby, która prowadzi test. To wygodne przy pracy nad poprawkami, ponieważ wynik pojawia się od razu i można testować także wersję strony, której jeszcze nie opublikowano. Sposób uruchamiania opisujemy we wpisie o audycie strony w Chrome za pomocą Lighthouse.

Dlaczego test wypada słabo, a dane od użytkowników są dobre

Test wypada gorzej niż dane od użytkowników najczęściej dlatego, że symuluje warunki trudniejsze niż te, w jakich stronę otwiera większość odwiedzających. Jest to częstszy z dwóch scenariuszy i zwykle nie świadczy o awarii. Poniżej omawiamy przyczyny, które opisuje zespół Chrome.

Pierwsza przyczyna to urządzenie i łącze. Według dokumentacji PageSpeed Insights test mobilny odwzorowuje telefon średniej klasy w sieci komórkowej o ograniczonej przepustowości, a sam pomiar wykonywany jest z jednego z regionów: Azji, Europy lub Ameryki Północnej. Jeśli klienci hydraulika z Łodzi otwierają jego stronę głównie na nowszych telefonach, w domowej sieci bezprzewodowej i z serwera w Polsce, ich rzeczywiste wizyty będą szybsze niż symulacja.

Druga przyczyna to pamięć podręczna przeglądarki. Test laboratoryjny zwykle wczytuje stronę tak, jakby odwiedzający był na niej pierwszy raz, czyli pobiera wszystkie pliki od zera. Osoby powracające mają już w przeglądarce zapisane grafiki, czcionki i skrypty, więc kolejne wczytania trwają krócej.

Trzecia przyczyna to pamięć podręczna stron poprzednich i następnych w przeglądarce (ang. bfcache). Gdy odwiedzający wraca przyciskiem wstecz do strony, którą widział przed chwilą, przeglądarka może przywrócić ją niemal natychmiast. Takie wizyty wliczają się do danych od użytkowników, a test laboratoryjny ich nie odtwarza.

Czwarta przyczyna dotyczy samego sposobu liczenia LCP. Największy element na ekranie może być inny na różnych urządzeniach, dla osób zalogowanych albo przy treściach dopasowanych do odwiedzającego. Poza tym przeglądarka przestaje szukać większego elementu w chwili, gdy odwiedzający przewinie stronę lub wykona inne działanie, przez co LCP u ludzi bywa krótszy niż w teście, który czeka do końca wczytywania. Sposoby skracania tego czasu opisujemy we wpisie o tym, co opóźnia wyświetlenie największego elementu.

Dlaczego test wypada dobrze, a Search Console pokazuje problemy

Sytuacja odwrotna, czyli wysoka punktacja w teście przy słabych wskaźnikach w Search Console, wynika zwykle z tego, że test kończy się po wczytaniu strony, a odwiedzający dopiero wtedy zaczynają z niej korzystać. Ten scenariusz wymaga więcej uwagi, ponieważ oznacza, że prawdziwi ludzie mają gorsze doświadczenia, niż sugeruje narzędzie.

Przesunięcia układu po wczytaniu strony

W danych od użytkowników wskaźnik CLS obejmuje nieoczekiwane przesunięcia układu z całego czasu, jaki odwiedzający spędza na stronie, a test laboratoryjny rejestruje tylko te, które wystąpiły podczas wczytywania w widocznej części ekranu. Jeśli więc baner z informacją o plikach cookie, okno z ofertą albo reklama pojawia się dopiero po przewinięciu, test tego nie zauważy, a przeglądarki odwiedzających tak. Podobnie działają treści dopasowywane do odwiedzającego i testy różnych wersji strony: symulowany, anonimowy odwiedzający może ich w ogóle nie otrzymać. Typowe źródła takich przeskoków omawiamy we wpisie o tym, skąd biorą się przesunięcia układu strony.

Reakcja na kliknięcia i dotknięcia

Wskaźnika INP nie da się zmierzyć bez działania człowieka, dlatego test podaje zastępczo TBT, a ten przybliża rzeczywistość tylko w pewnym stopniu. TBT opisuje obciążenie przeglądarki w trakcie wczytywania, natomiast INP zależy od tego, w którym momencie i w co odwiedzający faktycznie kliknie. Sklep może mieć lekkie wczytywanie i dobry TBT, a mimo to wolno reagować na otwarcie filtrów, zmianę wariantu produktu albo wysunięcie koszyka, bo dopiero wtedy uruchamiają się ciężkie skrypty. Web.dev zwraca też uwagę na strony bez poprawnie ustawionego widoku mobilnego, na których przeglądarka wprowadza opóźnienie dotknięcia sięgające 300 milisekund. Takie opóźnienie wlicza się do INP, a w TBT go nie widać.

Wolniejsze urządzenia i sieci niż w teście

Zdarza się również, że odwiedzający mają warunki gorsze niż symulacja. Dotyczy to zwłaszcza testu w widoku dla komputerów, który odwzorowuje komputer z połączeniem przewodowym, oraz testów wykonywanych na własnym, wydajnym sprzęcie w Lighthouse. Jeśli firma z Bydgoszczy sprzedaje części do maszyn rolniczych, a jej klienci otwierają stronę w terenie, przy słabym zasięgu, to dane od użytkowników mogą być wyraźnie gorsze niż pomiar wykonany w biurze. Tu szczególnie liczy się czas odpowiedzi serwera, o którym piszemy we wpisie o TTFB i jego przyczynach.

Testowany adres a grupa adresów

Ostatnia przyczyna jest organizacyjna, nie techniczna. Search Console ocenia grupy podobnych adresów, a w teście sprawdza się zwykle jeden, najczęściej stronę główną. Strona główna bywa dopracowana i lekka, a problem dotyczy kart produktów, wpisów z dużą liczbą zdjęć albo podstron z mapą. Dlatego przy rozbieżności należy otworzyć w raporcie wiersz z problemem, przejrzeć przykładowe adresy z tej grupy i przetestować w PageSpeed Insights właśnie je, a nie stronę startową.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl

Które dane Google bierze pod uwagę w rankingu

W wyszukiwarce liczą się podstawowe wskaźniki internetowe, a te Google ocenia na podstawie danych od rzeczywistych użytkowników, nie na podstawie punktacji z testu. Wynika to z kilku dokumentów czytanych razem. Strona Centrum wyszukiwarki Google o jakości strony w wynikach wyszukiwania stwierdza, że systemy rankingowe używają Core Web Vitals. Z kolei web.dev wyjaśnia, że to właśnie dane terenowe służą Google do ustalenia, czy witryna spełnia progi tych wskaźników, a pomoc Search Console potwierdza, że raport w tym narzędziu opiera się wyłącznie na CrUX.

Punktacja wydajności Lighthouse nie jest w tych dokumentach wymieniana jako sygnał rankingowy. Przeciwnie, strona o jakości strony zaznacza, że dążenie do idealnego wyniku wyłącznie ze względu na SEO może nie być najlepszym wykorzystaniem czasu. Sto punktów w teście nie jest więc celem samym w sobie, a kilkadziesiąt punktów przy dobrych danych od użytkowników nie jest powodem do niepokoju o widoczność.

Trzeba też zachować proporcje co do znaczenia samych wskaźników. Google podaje, że wyszukiwarka stara się pokazywać najbardziej trafne treści nawet wtedy, gdy jakość strony jest słaba, a dobre wrażenia mogą pomóc tam, gdzie na dane zapytanie odpowiada wiele przydatnych stron. Dobre wyniki w raportach nie gwarantują wysokich pozycji. Szybkość jest zatem jednym z wielu elementów, co szerzej opisujemy we wpisie o tym, co wiadomo na pewno o czynnikach rankingowych Google.

Na których danych opierać decyzje

O tym, czy i co poprawiać, powinny decydować dane od użytkowników, a test laboratoryjny powinien służyć do znalezienia przyczyny i sprawdzenia poprawki. Takie rozdzielenie ról zaleca zespół Chrome: dane terenowe wyznaczają priorytety, bo pokazują faktyczne doświadczenia ludzi, a dane laboratoryjne pomagają w diagnozie i w testach przed wdrożeniem. Poniżej przedstawiamy kolejność działań, którą stosujemy w pracach technicznych.

1. Ustalenie stanu w Search Console

   W raporcie Podstawowe wskaźniki internetowe należy osobno przejrzeć urządzenia mobilne i komputery oraz zanotować, które grupy adresów mają status słabej jakości lub wymagają poprawy i z powodu którego wskaźnika.

2. Wskazanie konkretnych adresów

   Z każdej grupy z problemem warto wziąć dwa lub trzy przykładowe adresy, najlepiej te o największym ruchu, i sprawdzić je w PageSpeed Insights. Górna część raportu potwierdzi, czy dane dotyczą tego adresu, czy całej witryny.

3. Diagnoza w teście laboratoryjnym

   Dolna część raportu i Lighthouse w Chrome pokazują, co spowalnia wczytywanie: który element jest największy, które skrypty blokują przeglądarkę, gdzie układ się przesuwa. Test warto powtórzyć kilka razy, ponieważ pojedyncze uruchomienia różnią się między sobą.

4. Poprawka i kontrola w teście

   Po wprowadzeniu zmiany pomiar laboratoryjny od razu pokazuje, czy dany wskaźnik się poprawił. To jedyny sposób, aby ocenić zmianę przed upływem kilku tygodni.

5. Potwierdzenie w danych od użytkowników

   W Search Console można uruchomić sprawdzanie poprawki przyciskiem rozpoczynającym śledzenie. Narzędzie obserwuje wtedy problem przez 28 dni i uznaje go za naprawiony, jeśli w tym czasie żaden adres go nie wykazuje.

Jeśli lista problemów obejmuje wiele szablonów jednocześnie, porządek prac najłatwiej ustalić w ramach audytu SEO, w którym szybkość zestawia się z pozostałymi kwestiami technicznymi. Przegląd metod naprawy poszczególnych wskaźników zawiera nasz wpis o tym, jak poprawić LCP, INP i CLS na stronie firmy.

Co zrobić, gdy danych od użytkowników nie ma

Gdy strona ma zbyt mały ruch, Google nie pokazuje dla niej danych od użytkowników i wtedy jedyną podstawą oceny pozostaje pomiar laboratoryjny oraz własne pomiary. Dotyczy to wielu nowych serwisów i stron lokalnych firm. Search Console wyświetla w takiej sytuacji komunikat o braku dostępnych danych, a pomoc Google wyjaśnia, że przyczyną jest nowa usługa albo zbyt mała liczba pomiarów w CrUX dla danego typu urządzeń.

Brak danych nie jest błędem i nie oznacza kary. Oznacza jedynie, że w raporcie nie ma czego pokazać. W takim położeniu warto przyjąć test laboratoryjny za punkt odniesienia, ale czytać go rozsądnie: zwracać uwagę na wartości poszczególnych wskaźników i na zalecenia, a nie tylko na sumaryczną punktację, oraz testować kilka różnych typów podstron. Przydatne bywa także zwykłe sprawdzenie strony na kilku prawdziwych telefonach, w tym starszych, w sieci komórkowej.

Własne pomiary na stronie

Drugą drogą jest zbieranie własnych danych od odwiedzających. Web.dev w opracowaniu o rozpoczynaniu pomiarów Web Vitals wyraźnie zachęca, by uzupełniać narzędzia oparte na CrUX własnym monitoringiem rzeczywistych wizyt. Służy do tego między innymi niewielka biblioteka JavaScript o nazwie web-vitals, która mierzy wskaźniki w przeglądarce odwiedzającego zgodnie z ich oficjalną definicją. Zebrane wartości trzeba następnie przesłać do miejsca, w którym da się je analizować, na przykład do Google Analytics.

Własny pomiar obejmuje wszystkich odwiedzających, także tych, których CrUX nie uwzględnia, i pokazuje zmianę po poprawce szybciej niż raporty oparte na oknie 28 dni. Wdrożenie wymaga jednak pracy programisty i uporządkowanej analityki, dlatego zwykle łączymy je z analityką i raportowaniem SEO, tak aby liczby trafiały do jednego, czytelnego zestawienia.

Typowe pomyłki przy porównywaniu wyników

Najczęstsza pomyłka polega na traktowaniu punktacji z testu jako oceny wystawionej przez wyszukiwarkę, podczas gdy jest to wynik jednej symulacji. Pozostałe błędy mają podobne źródło: zestawia się liczby, które pochodzą z różnych pomiarów, okresów albo zakresów. Przed wyciągnięciem wniosków warto przejść przez poniższą listę.

• Ustalono, czy porównywane liczby pochodzą z testu, czy od użytkowników, i nie zestawiono ich ze sobą wprost.
• Sprawdzono, czy dane od użytkowników dotyczą testowanego adresu, czy całej witryny.
• Porównano ten sam typ urządzenia: telefony z telefonami, komputery z komputerami.
• Test laboratoryjny uruchomiono kilka razy, a nie oceniono strony po jednym wyniku.
• Przetestowano podstrony z grupy wskazanej w Search Console, a nie tylko stronę główną.
• Po poprawce odczekano, aż z okna 28 dni wypadną wizyty sprzed zmiany.
• Wzięto pod uwagę, że CrUX nie obejmuje wszystkich przeglądarek ani Chrome na iOS.
• Oceniono wartości LCP, INP i CLS, a nie samą punktację od 0 do 100.

Z praktyki naszych prac technicznych wynika, że sporo czasu i pieniędzy pochłania pogoń za ostatnimi punktami w teście. Usuwa się wtedy funkcje potrzebne klientom, na przykład czat, mapę dojazdu czy opinie, tylko po to, aby liczba na ekranie zmieniła kolor na zielony, choć dane od użytkowników od dawna mieściły się w przedziale dobrym. Odwrotny błąd jest równie kosztowny: wysoka punktacja strony głównej uspokaja właściciela, a w tym czasie karty produktów mają w Search Console status słabej jakości.

Pomoc specjalisty jest potrzebna zwłaszcza wtedy, gdy test i dane od użytkowników trwale się różnią, a przyczyny nie widać w zaleceniach narzędzia, gdy problem dotyczy reakcji na kliknięcia i wymaga analizy skryptów, albo gdy poprawki wymagają zmian w szablonie sklepu lub konfiguracji serwera. W takich przypadkach prace nad szybkością najlepiej prowadzić razem z pozostałymi elementami, które obejmuje SEO techniczne, ponieważ zmiany w kodzie i na serwerze wpływają jednocześnie na indeksowanie, wygodę odwiedzających i sprzedaż.

Jeśli chcą Państwo zamówić SEO techniczne, zachęcamy do kontaktu: tel. 222 500 844 lub mailowo: biuro@pozycjonowaniestron.pl