Dowiedz się, dlaczego narzędzia, które monitorują podstawowe wskaźniki internetowe, mogą podawać różne wartości, i jak interpretować te różnice.
Google udostępnia wiele narzędzi, które ułatwiają właścicielom witryn monitorowanie wyników podstawowych wskaźników internetowych. Narzędzia te dzielą się na 2 główne kategorie:
- Narzędzia do raportowania danych laboratoryjnych, czyli danych zbieranych w kontrolowanym środowisku ze wstępnie zdefiniowanymi ustawieniami urządzenia i sieci.
- Narzędzia raportujące dane zgromadzone, czyli dane zebrane od rzeczywistych użytkowników odwiedzających Twoją witrynę.
Problem polega na tym, że czasami dane przekazywane przez narzędzia laboratoryjne mogą znacznie różnić się od danych raportowanych przez narzędzia terenowe. Dane laboratoryjne mogą wskazywać, że witryna osiąga świetne wyniki, ale dane z pola wskazują, że należy ją ulepszyć. Z kolei dane w polu mogą wskazywać, że wszystkie strony są w porządku, ale dane z Twojego laboratorium mogą również zgłaszać bardzo niski wynik.
Ten rzeczywisty przykład raportu PageSpeed Insights z web.dev pokazuje, że w niektórych przypadkach dane laboratoryjne i terenowe mogą się różnić w przypadku wszystkich podstawowych wskaźników internetowych:
Różnice między narzędziami to zrozumiałe źródło dezorientacji dla programistów. W tym poście wyjaśniamy główne przyczyny tych różnic (podajemy konkretne przykłady dotyczące każdego z podstawowych wskaźników internetowych) oraz pokazujemy, co zrobić, gdy zauważysz takie różnice w swoich stronach.
Dane laboratoryjne a dane terenowe
Aby zrozumieć, dlaczego narzędzia laboratoryjne i polowe mogą podawać różne wartości – nawet w przypadku tej samej strony internetowej – musisz zrozumieć różnicę między danymi z modułu a danymi pola.
Dane modułu
Dane modułu są określane przez wczytanie strony internetowej w kontrolowanym środowisku ze wstępnie zdefiniowanym zestawem warunków dotyczących sieci i urządzenia. Takie warunki są nazywane środowiskiem laboratorium, czasami nazywane też środowiskiem syntetycznym.
Narzędzia Chrome, które raportują dane z laboratorium, zwykle używają Lighthouse.
Celem testu laboratoryjnego jest kontrola jak największej liczby czynników, aby wyniki były (jak najwięcej) spójne i odtwarzalne.
Dane pola
Dane terenowe są określane przez monitorowanie wszystkich użytkowników, którzy odwiedzają daną stronę, i mierzenie określonego zestawu danych o skuteczności w przypadku każdego z poszczególnych doświadczeń. Dane w terenie są zbierane na podstawie informacji o rzeczywistych wizytach użytkowników, więc odzwierciedlają rzeczywiste urządzenia, warunki w sieci i lokalizacje geograficzne użytkowników.
Dane pól są też powszechnie nazywane danymi Real User Monitoring (RUM). Te 2 terminy są zamienne.
Narzędzia Chrome przesyłające dane z pola zwykle pochodzą z Raportu na temat użytkowania Chrome. Często (i zalecane) właściciele witryn samodzielnie gromadzą dane pól, ponieważ mogą one dostarczać bardziej przydatnych statystyk niż sam raport na temat użytkowania Chrome.
Przede wszystkim trzeba zrozumieć, że dane terenowe nie są tylko jedną liczbą, ale ich rozkładem. Oznacza to, że jedne osoby odwiedzające Twoją witrynę mogą wczytywać się bardzo szybko, inne bardzo wolno. Dane z pola dla Twojej witryny to pełny zbiór wszystkich danych o skuteczności zebranych od użytkowników.
Na przykład raporty CrUX pokazują rozkład danych o skuteczności wśród rzeczywistych użytkowników Chrome w okresie 28 dni. W niemal każdym raporcie raportu na temat użytkowania Chrome możesz zauważyć, że niektórzy użytkownicy są z niej bardzo zadowoleni, a inni – bardzo złe.
Jeśli narzędzie raportuje 1 liczbę dla danego rodzaju danych, na ogół reprezentuje ona konkretny punkt rozkładu. Narzędzia raportujące wyniki pola w Core Web Vitals robią to za pomocą 75 percentyla.
Patrząc na LCP z danych pola na zrzucie ekranu powyżej, widać rozkład, w którym:
- W przypadku 88% wizyt wskaźnik LCP wynosi nie więcej niż 2,5 sekundy (dobrze).
- W przypadku 8% wizyt wskaźnik LCP wynosił od 2,5 do 4 sekund (wymaga poprawy).
- W 4% wizyt wskaźnik LCP trwał ponad 4 sekundy (słabe).
W 75.percentylu LCP wynosił 1, 8 sekundy:
Dane modułu z tej samej strony pokazują wartość LCP wynoszącą 3,0 sekundy. Chociaż jest to wartość większa niż 1,8 sekundy widoczna w danych pola, nadal jest to prawidłowa wartość LCP dla tej strony – to jedna z wielu wartości, które składają się na pełny rozkład obciążenia.
Dlaczego dane laboratoryjne i pola różnią się od siebie
Jak wyjaśniamy w sekcji powyżej, dane laboratoryjne i dane terenowe mierzą zupełnie inne rzeczy.
Dane pól obejmują szeroką gamę warunków sieci i urządzeń, a także wiele rodzajów zachowań użytkowników. Uwzględnia też inne czynniki, które wpływają na wygodę użytkowników, takie jak optymalizacje przeglądarki takie jak pamięć podręczna stanu strony internetowej (bfcache) czy optymalizacje platformy (np. AMP Cache).
Z kolei dane laboratoryjne celowo ograniczają liczbę zmiennych. Składa się on z tych elementów:
- Jedno urządzenie...
- połączono z jedną siecią...
- w jednej lokalizacji geograficznej.
Szczegóły danego testu laboratoryjnego mogą, ale nie muszą, dokładnie odzwierciedlać 75 centyl danych pól dotyczących danej strony lub witryny.
Kontrolowane środowisko modułu jest przydatne podczas debugowania problemów lub testowania funkcji przed wdrożeniem ich w środowisku produkcyjnym. Jeśli jednak kontrolujesz te czynniki, wyraźnie nie odzwierciedlasz w świecie rzeczywistym rozbieżności występujących w świecie rzeczywistym we wszystkich typach sieci, możliwości urządzeń czy lokalizacji geograficznych. Zwykle nie uwzględniasz też wpływu na wydajność działania użytkowników, takich jak przewijanie, zaznaczanie tekstu czy klikanie elementów strony.
Oprócz możliwego rozróżnienia między warunkami laboratoryjnymi a warunkami większości rzeczywistych użytkowników występuje też kilka bardziej subtelnych różnic, które należy wziąć pod uwagę, aby jak najlepiej wykorzystać dane laboratoryjne i związane z pracą, a także ewentualne różnice.
W kolejnych sekcjach przedstawimy najczęstsze powody, dla których mogą występować różnice między danymi laboratoryjnymi a danymi z pól w przypadku poszczególnych wskaźników Core Web Viitals:
- Największe wyrenderowanie treści (LCP)
- Opóźnienie przy pierwszym działaniu (FID)
- Skumulowane przesunięcie układu (CLS)
LCP
Różne elementy LCP
Element LCP wskazany w teście laboratoryjnym może nie być tym samym elementem LCP, który użytkownicy widzą na Twojej stronie.
Jeśli wygenerujesz raport Lighthouse dotyczący danej strony, za każdym razem zwróci on ten sam element LCP. Jeśli jednak analizujesz dane pól dla tej samej strony, zwykle widzisz różne elementy LCP, które zależą od szeregu okoliczności specyficznych dla każdej wizyty na stronie.
Na przykład takie czynniki mogą mieć wpływ na określenie innego elementu LCP dla tej samej strony:
- Różne rozmiary ekranów urządzeń wpływają na widoczność różnych elementów w widocznym obszarze.
- Jeśli użytkownik jest zalogowany lub w jakiś sposób wyświetlane są spersonalizowane treści, element LCP może wyglądać zupełnie inaczej.
- Podobnie jak w przypadku poprzedniego punktu, test A/B może spowodować wyświetlanie zupełnie innych elementów.
- Zestaw czcionek zainstalowanych w systemie użytkownika może wpływać na rozmiar tekstu na stronie (a tym samym który element stanowi element LCP).
- Testy laboratoryjne są zwykle przeprowadzane na „podstawowym” adresie URL strony – bez dodawania parametrów zapytań ani fragmentów z krzyżykiem. W rzeczywistości jednak użytkownicy często udostępniają adresy URL zawierające identyfikator fragmentu lub fragment tekstu, więc element LCP może znajdować się w środkowej lub dolnej części strony (a nie „w części strony widocznej na ekranie”).
Wartość LCP w tym polu jest obliczana jako 75 centyl wszystkich wizyt na stronie. Dlatego, jeśli duży odsetek tych użytkowników miał element LCP, który wczytuje się bardzo szybko, np. akapit tekstu wyrenderowany za pomocą czcionki systemowej, to nawet jeśli niektórzy z tych użytkowników mają duży, wolno ładujący się obraz (%), może to nie wpłynąć na wynik tej strony, jeśli wyświetli się on mniej niż 25 użytkowników.
W przeciwnym razie może być na odwrót. W ramach testu laboratoryjnego można zidentyfikować blok tekstu jako element LCP, ponieważ emuluje on telefon Moto G4, który ma względnie mały widoczny obszar, a baner powitalny Twojej strony jest początkowo renderowany poza ekranem. Dane pola mogą jednak dotyczyć głównie użytkowników urządzeń Pixel XL z większymi ekranami, dlatego wolno ładujący się baner powitalny jest elementem LCP.
Wpływ stanu pamięci podręcznej na LCP
W ramach testów laboratoryjnych strona jest zazwyczaj ładowana w pamięci podręcznej z zimną pamięcią, ale gdy prawdziwi użytkownicy odwiedzają tę stronę, możliwe, że część jej zasobów znajduje się w pamięci podręcznej.
Przy pierwszym wczytywaniu strona może wczytywać się powoli, ale jeśli skonfigurowano odpowiednie zapisywanie w pamięci podręcznej, następnym razem strona ta może się wczytać od razu.
Niektóre narzędzia laboratoryjne obsługują wielokrotne uruchomienia tej samej strony (aby symulować wrażenia powracających użytkowników), jednak narzędzie laboratoryjne nie jest w stanie ustalić, jaki odsetek rzeczywistych wizyt nowych i powracających użytkowników pochodzi z witryny.
W przypadku witryn z dobrze zoptymalizowanymi konfiguracjami pamięci podręcznej i wieloma powracającymi użytkownikami rzeczywisty wskaźnik LCP może być znacznie szybszy, niż wskazują na to dane laboratoryjne.
Optymalizacje AMP lub Signed Exchange
Witryny utworzone przy użyciu AMP lub korzystające z technologii Signed Exchange (SXG) mogą być wstępnie wczytywane przez agregatory treści, np. wyszukiwarkę Google. Może to znacznie zwiększyć wydajność wczytywania stron przez użytkowników odwiedzających Twoje strony z tych platform.
Oprócz wstępnego wczytywania treści z innych domen same witryny mogą wstępnie wczytywać treści na kolejne strony w swojej witrynie, co może poprawić LCP również w przypadku tych stron.
Narzędzia laboratoryjne nie symulują korzyści płynących z tych optymalizacji. Nawet jeśli tak, nie były w stanie ustalić, jaki odsetek ruchu pochodzi z platform takich jak Wyszukiwarka Google w porównaniu z innymi źródłami.
Wpływ pamięci podręcznej (bfcache) na LCP
Po przywróceniu stron z pamięci podręcznej stanu strony internetowej wczytywanie odbywa się niemal natychmiast, a te funkcje są uwzględniane w danych pól.
Testy laboratoryjne nie uwzględniają zawartości pamięci podręcznej (bfcache), więc jeśli Twoje strony są dostosowane do bfcache, prawdopodobnie spowoduje to szybsze raportowanie wyników LCP w polu.
Wpływ interakcji użytkownika na LCP
LCP określa czas renderowania największego obrazu lub bloku tekstowego w widocznym obszarze. Ten największy element może się jednak zmieniać podczas wczytywania strony lub gdy nowa zawartość jest dynamicznie dodawana do widocznego obszaru.
W tym module przeglądarka poczeka, aż strona zostanie w pełni wczytana, zanim określi element LCP. Gdy użytkownik przewinie stronę lub wejdzie z nią w interakcję, w tym polu przeglądarka przestanie monitorować większe elementy.
Ma to sens (i jest niezbędne), ponieważ użytkownicy zwykle czekają na interakcję ze stroną, aż „zobaczy się” na niej wczytanie, co jest wykrywane przez wskaźnik LCP. Nie ma też sensu uwzględniać elementów dodanych do widocznego obszaru po interakcji użytkownika, ponieważ mogły one zostać wczytane z powodu działań użytkownika.
Konsekwencją jest jednak to, że dane pola strony mogą być szybciej raportowane LCP, w zależności od zachowania użytkowników na tej stronie.
FID
FID wymaga rzeczywistej interakcji z użytkownikiem
Wskaźnik FID określa responsywność strony w odniesieniu do interakcji użytkowników w momencie interakcji z nią.
Druga część tego zdania ma kluczowe znaczenie, ponieważ testy laboratoryjne, nawet takie, które obsługują zachowania użytkowników, nie są w stanie dokładnie przewidzieć, kiedy użytkownicy zdecydują się na interakcję ze stroną, a więc nie mogą dokładnie zmierzyć FID.
TBT nie uwzględnia zachowań użytkowników
Dane laboratoryjne Całkowity czas blokowania (TBT) mają pomóc w diagnozowaniu problemów z FID, ponieważ pokazują, jak bardzo wątek główny jest blokowany podczas wczytywania strony.
Oznacza to, że strony z wieloma synchronicznym kodem JavaScript lub innymi zadaniami wymagającymi intensywnego renderowania będą częściej blokowały wątek główny, gdy użytkownik wejdzie w interakcję po raz pierwszy. Jeśli jednak użytkownicy czekają na interakcję ze stroną do momentu zakończenia działania JavaScriptu, wartość FID może być bardzo niska.
To, kiedy użytkownicy zdecydują się na interakcję ze stroną, zależy w dużej mierze od tego, czy wygląda ona interaktywna. Nie można tego zmierzyć za pomocą TBT.
TBT nie uwzględnia opóźnienia kliknięcia
Jeśli witryna nie jest zoptymalizowana do wyświetlania na urządzeniach mobilnych, przeglądarki dodają 300 ms opóźnienia po każdym kliknięciu przed uruchomieniem modułów obsługi zdarzeń. Robią to, ponieważ muszą ustalić, czy przed uruchomieniem zdarzeń kliknięcia lub użycia myszy użytkownik próbuje dwukrotnie kliknąć, aby powiększyć.
To opóźnienie jest wliczane do FID strony, ponieważ wpływa na rzeczywiste opóźnienie danych wejściowych użytkownika. To opóźnienie nie jest jednak w zasadzie długim zadaniem, więc nie wpływa na TBT strony. Oznacza to, że strona może mieć niski wskaźnik FID pomimo bardzo dobrych wyników TBT.
Wpływ stanu i pamięci podręcznej stanu strony internetowej na FID
Podobnie jak prawidłowe buforowanie może poprawić LCP w polu, może też poprawić FID.
W świecie rzeczywistym użytkownik może mieć już w pamięci podręcznej kod JavaScript strony, dlatego jego przetworzenie może potrwać krócej i spowoduje mniejsze opóźnienia.
To samo dotyczy stron przywróconych z pamięci podręcznej stanu strony internetowej. W takich przypadkach JavaScript jest przywracany z pamięci, więc przetwarzanie może trwać bardzo krótko lub wcale.
CLS
Wpływ interakcji użytkowników na CLS
Wartość CLS mierzona w module uwzględnia tylko przesunięcia układu, które zachodzą w części strony widocznej na ekranie i w trakcie wczytywania strony. Jest to tylko podzbiór pomiarów CLS.
W tym polu CLS uwzględnia wszystkie nieoczekiwane przesunięcia układu, które mają miejsce w całym okresie działania strony, w tym treści, które przesuwają się, gdy użytkownik przewija stronę, lub w reakcji na wolne żądania sieciowe po interakcji użytkownika.
Na przykład leniwe ładowanie obrazów lub elementów iframe bez wymiarów jest dość częste, co może spowodować przesunięcie układu, gdy użytkownik przewinie stronę do tych sekcji. Takie zmiany mogą jednak wystąpić tylko wtedy, gdy użytkownik przewinie stronę w dół, co często nie zmieści się w teście laboratoryjnym.
Spersonalizowana treść
Spersonalizowane treści – w tym reklamy kierowane i testy A/B – wpływają na to, jakie elementy są ładowane na stronie. Ma to również wpływ na sposób ich wczytywania, ponieważ spersonalizowane treści są często ładowane później i wstawiane do głównej treści strony, co powoduje zmiany układu.
W ramach tego modułu strona jest zwykle wczytywana bez spersonalizowanych treści lub zawierająca treści przeznaczone dla ogólnego „użytkownika testowego”, co może, ale nie musi, powodować zmiany widoczne dla użytkowników.
Dane pól obejmują wrażenia wszystkich użytkowników, więc ilość (i stopień) przesunięć układu występujących na danej stronie zależy w dużym stopniu od tego, jaka treść zostanie wczytana.
Wpływ stanu i pamięci podręcznej pamięci podręcznej na CLS
Dwie najczęstsze przyczyny przesunięcia układu podczas wczytywania to obrazy i elementy iframe bez wymiarów (jak wspomnieliśmy powyżej) oraz wolne ładujące się czcionki internetowe. Oba te problemy mają większy wpływ na wrażenia użytkownika przy pierwszym otwarciu witryny, gdy pamięć podręczna jest pusta.
Jeśli zasoby strony są przechowywane w pamięci podręcznej lub gdy strona jest przywrócona z pamięci podręcznej stanu strony internetowej, przeglądarka zwykle może od razu wyrenderować obrazy i czcionki, nie czekając na ich pobranie. Może to spowodować, że wartości CLS w tym polu będą niższe niż wartości podane przez narzędzie modułu.
Co zrobić, gdy wyniki się różnią
Jeśli na danej stronie masz zarówno dane pól, jak i dane modułu, dane z pola należy wykorzystać do określenia priorytetów swoich działań. Dane z terenów pokazują, czego doświadczają użytkownicy, dlatego stanowią najdokładniejsze informacje o tym, z czym mają problemy użytkownicy i co wymaga poprawy.
Z drugiej strony, jeśli Twoje dane z terenu wykazują dobre wyniki ogólne, ale dane z Twojego modułu wskazują, że można coś jeszcze poprawić, warto wiedzieć, co można jeszcze poprawić.
Co więcej, dane w polach rejestrują wrażenia rzeczywistych użytkowników, ale tylko w przypadku użytkowników, którzy mogą załadować Twoją witrynę. Dane laboratoryjne mogą czasem pomóc w określeniu możliwości zwiększenia zasięgu witryny i ułatwienia dostępu do niej użytkownikom korzystającym z wolniejszych sieci lub mniej zaawansowanych urządzeń.
Ogólnie dane laboratoryjne i dane terenowe to ważne elementy skutecznego pomiaru wydajności. Oba mają swoje mocne i ograniczenia, a jeśli korzystasz tylko z jednego z nich, możesz tracić szanse na poprawę wygody użytkowników.