Dowiedz się, dlaczego narzędzia monitorujące podstawowe wskaźniki internetowe mogą podawać różne liczby i jak interpretować te różnice.
Google udostępnia kilka narzędzi, które pomagają właścicielom witryn monitorować ich wyniki w podstawowych wskaźnikach internetowych. Te narzędzia można podzielić na 2 główne kategorie:
- Narzędzia, które podają dane z testów laboratoryjnych – dane zebrane w kontrolowanym środowisku z zaimplementowanymi wstępnie ustawieniami urządzenia i sieci.
- narzędzia, które podają dane z pola – dane zbierane od prawdziwych użytkowników odwiedzających Twoją witrynę;
Problem polega na tym, że dane raportowane przez narzędzia laboratoryjne mogą się znacznie różnić od danych raportowanych przez narzędzia terenowe. Dane z testów laboratoryjnych mogą wskazywać, że Twoja witryna działa świetnie, ale dane z testów w warunkach rzeczywistych wskazują, że wymaga ulepszenia. Zdarza się też, że według danych z pola wszystkie strony są dobre, ale dane z testów laboratoryjnych wskazują na bardzo niski wynik.
Ten przykład raportu PageSpeed Insights z web.dev pokazuje, że w niektórych przypadkach dane z testów laboratoryjnych i z testów terenowych mogą się różnić w przypadku wszystkich podstawowych wskaźników internetowych:
Różnice między narzędziami są zrozumiałym źródłem zamieszania wśród programistów. W tym poście wyjaśniamy, dlaczego mogą występować takie różnice (podając konkretne przykłady dotyczące każdego z podstawowych wskaźników internetowych) oraz co zrobić, gdy znajdziesz różnice na swoich stronach.
Dane z laboratorium a zgromadzone dane
Aby zrozumieć, dlaczego narzędzia laboratoryjne i polecane narzędzia mogą podawać różne wartości (nawet w przypadku tej samej strony internetowej), musisz zrozumieć różnicę między danymi laboratoryjnymi a danymi z pola.
Dane z modułu
Dane z testów laboratoryjnych są ustalane przez załadowanie strony internetowej w kontrolowanym środowisku z wstępnie zdefiniowanym zestawem warunków sieci i urządzenia. Takie warunki nazywamy środowiskiem laboratoryjnym, czasami nazywanym też środowiskiem syntetycznym.
Narzędzia Chrome, które raportują dane laboratoryjne, zwykle korzystają z Lighthouse.
Celem testu laboratoryjnego jest kontrolowanie jak największej liczby czynników, aby wyniki były (w jak największym stopniu) spójne i powtarzalne.
Dane pól
Dane z pola są ustalane na podstawie monitorowania wszystkich użytkowników, którzy odwiedzają stronę, oraz pomiaru określonego zbioru danych o wydajności w przypadku poszczególnych użytkowników. Dane z pola są oparte na wizytach rzeczywistych użytkowników, dlatego odzwierciedlają ich faktyczne urządzenia, warunki sieciowe i lokalizacje geograficzne.
Dane z pola są też często nazywane danymi monitorowania rzeczywistych użytkowników (RUM). Oba te terminy są wymienne.
Narzędzia Chrome, które raportują dane z pól, zwykle uzyskują te dane z raportu na temat użytkowania Chrome (CrUX). Właściciele witryn często (i zalecane jest) samodzielnie zbierają dane z pól, ponieważ mogą one dostarczyć bardziej przydatnych informacji niż sam raport CrUX.
Najważniejsze, co należy wiedzieć o danych dotyczących pól, to że nie są to tylko 1 liczba, ale rozkład liczb. Oznacza to, że dla niektórych osób odwiedzających Twoją witrynę może ona ładować się bardzo szybko, a dla innych bardzo wolno. Dane z pola w przypadku Twojej witryny to kompletny zestaw wszystkich danych o wydajności zebranych od użytkowników.
Na przykład raporty CrUX pokazują rozkład danych o wydajności pochodzących od rzeczywistych użytkowników Chrome w ciągu 28 dni. Jeśli spojrzysz na niemal każdy raport CrUX, zauważysz, że niektórzy użytkownicy odwiedzający witrynę mogą mieć bardzo dobre wrażenia, a inni – bardzo złe.
Jeśli narzędzie podaje dla danego rodzaju danych jedną liczbę, zwykle będzie ona reprezentować konkretny punkt w rozkładzie. Narzędzia, które podają wyniki podstawowych wskaźników internetowych, robią to korzystając z 75. procentyla.
Na podstawie danych LCP z pola na powyższym zrzucie ekranu widać rozkład, w którym:
- W 88% przypadków wizyty miały czas LCP wynoszący 2,5 s lub mniej (dobry wynik).
- W 8% wizytacji czas LCP wynosił od 2,5 do 4 sekund (wymaga poprawy).
- W 4% wizytacji czas LCP wynosił ponad 4 sekundy (zły wynik).
W 75.percentylu LCP wynosił 1, 8 sekundy:
Dane z testów na tej samej stronie wskazują, że wartość LCP wynosi 3,0 s. Chociaż ta wartość jest większa niż 1,8 sekundy podane w danych polowych, nadal jest prawidłową wartością LCP dla tej strony.Jest to jedna z wielu wartości, które składają się na pełną dystrybucję doświadczeń ładowania.
Dlaczego dane z laboratorium różnią się od danych z pola
Jak wyjaśniono w poprzedniej sekcji, dane z laboratorium i dane z pola mierzą zupełnie inne rzeczy.
Dane z pola obejmują wiele różnych warunków sieci i urządzeń, a także wiele różnych typów zachowań użytkowników. Obejmuje ona też inne czynniki, które wpływają na komfort użytkownika, takie jak optymalizacje przeglądarki, np. pamięć podręczna wstecz/w przód (bfcache), czy optymalizacje platformy, np. pamięć podręczna AMP.
Z kolei dane z laboratorium celowo ograniczają liczbę zmiennych. Test laboratoryjny obejmuje:
- Jedno urządzenie…
- połączony z jedną siecią…
- działać z jednej lokalizacji geograficznej.
Szczegóły danego testu laboratoryjnego mogą, ale nie muszą dokładnie odzwierciedlać 75 percentyla danych zebranych na danej stronie lub w danej witrynie.
Kontrolowane środowisko laboratorium jest przydatne podczas debugowania problemów lub testowania funkcji przed wdrożeniem w wersji produkcyjnej, ale gdy kontrolujesz te czynniki, nie uwzględniasz wyraźnie zmienności, która występuje w rzeczywistych warunkach w różnych sieciach, na różnych urządzeniach i w różnych lokalizacjach geograficznych. Zazwyczaj nie rejestrujesz też wpływu na wydajność zachowań rzeczywistych użytkowników, takich jak przewijanie, zaznaczanie tekstu czy klikanie elementów na stronie.
Oprócz możliwej rozbieżności między warunkami laboratoryjnymi a warunkami większości użytkowników w rzeczywistych warunkach istnieje też kilka subtelniejszych różnic, które warto poznać, aby jak najlepiej wykorzystać dane laboratoryjne i zgromadzone dane, a także wszelkie różnice, które możesz zauważyć.
W kolejnych sekcjach znajdziesz szczegółowe informacje o najczęstszych przyczynach rozbieżności między danymi z testów laboratoryjnych a danymi z testów w warunkach rzeczywistych w przypadku każdego z podstawowych wskaźników internetowych:
- Największe wyrenderowanie treści (LCP)
- Interakcja do kolejnego wyrenderowania (INP)
- Skumulowane przesunięcie układu (CLS)
LCP
Różne elementy LCP
Element LCP zidentyfikowany w teście laboratoryjnym może nie być tym samym elementem LCP, który użytkownicy widzą podczas wizyty na Twojej stronie.
Jeśli uruchomisz raport Lighthouse dla danej strony, za każdym razem będzie on zwracać ten sam element LCP. Jeśli jednak spojrzysz na dane w polu dotyczące tej samej strony, zobaczysz zwykle różne elementy LCP, które zależą od wielu okoliczności związanych z każdą wizytą na stronie.
Na przykład na tej samej stronie można określić różne elementy LCP:
- Różne rozmiary ekranów urządzeń powodują, że różne elementy są widoczne w widocznym obszarze.
- Jeśli użytkownik jest zalogowany lub jeśli wyświetlane są treści spersonalizowane, element LCP może się znacznie różnić w zależności od użytkownika.
- Podobnie jak w poprzednim punkcie, jeśli na stronie jest prowadzony test A/B, może to spowodować wyświetlanie bardzo różnych elementów.
- Zestaw czcionek zainstalowanych w systemie użytkownika może wpływać na rozmiar tekstu na stronie (a tym samym na to, który element jest elementem LCP).
- Testy laboratoryjne są zwykle przeprowadzane na „podstawowym” adresie URL strony, bez dodanych parametrów zapytania ani fragmentów hasha. W rzeczywistych warunkach użytkownicy często udostępniają adresy URL zawierające identyfikator fragmentu lub fragment tekstu, więc element LCP może znajdować się w środku lub na dole strony (a nie „nad zakładką”).
Ponieważ LCP w tym polu jest obliczane jako 75. percentyl wszystkich wizyt użytkowników na stronie, jeśli duży odsetek tych użytkowników miał element LCP, który wczytał się bardzo szybko (np. akapit tekstu renderowany za pomocą czcionki systemowej), to nawet jeśli niektórzy z tych użytkowników mieli element LCP w postaci dużego obrazu, który wczytywał się wolno, nie wpłynie to na wynik strony, jeśli dotyczy to mniej niż 25% użytkowników.
Może się też zdarzyć, że jest odwrotnie. Test laboratoryjny może zidentyfikować blok tekstu jako element LCP, ponieważ emuluje telefon Moto G4 z względnie małym widocznym obszarem, a główny obraz strony jest początkowo renderowany poza ekranem. Twoje dane pochodzące z polowych badań mogą obejmować głównie użytkowników Pixela XL z większymi ekranami, więc dla nich elementem LCP jest obraz bohatera, który wczytuje się wolno.
Wpływ stanu pamięci podręcznej na LCP
Testy laboratoryjne zwykle wczytują stronę z zimną pamięcią podręcznej, ale gdy prawdziwi użytkownicy odwiedzają tę stronę, niektóre jej zasoby mogą już być w niej zapisane.
Po raz pierwszy strona może wczytywać się wolno, ale jeśli prawidłowo skonfigurujesz buforowanie, następnym razem, gdy użytkownik wróci na stronę, może ona wczytać się od razu.
Chociaż niektóre narzędzia laboratoryjne obsługują wielokrotne uruchamianie tej samej strony (aby symulować działanie dla powracających użytkowników), nie są w stanie określić, jaki odsetek wizyt w rzeczywistych warunkach jest spowodowany przez nowych i powracających użytkowników.
W przypadku witryn z dobrze zoptymalizowaną konfiguracją pamięci podręcznej i dużą liczbą powracających użytkowników LCP może być w rzeczywistości znacznie krótszy niż wynikałoby to z danych z testów laboratoryjnych.
optymalizacja AMP lub Signed Exchange;
Witryny utworzone za pomocą AMP lub korzystające z Signed Exchange (SXG) mogą być wstępnie ładowane przez agregatorów treści, takich jak wyszukiwarka Google. Może to znacznie poprawić szybkość wczytywania stron przez użytkowników odwiedzających Twoją witrynę z tych platform.
Oprócz wstępnego wczytania z innych domen witryny mogą też wstępnie wczytywać treści na kolejnych stronach, co może poprawić LCP na tych stronach.
Narzędzia laboratoryjne nie symulują zysków uzyskanych dzięki tym optymalizacjom, a nawet jeśli tak by było, nie mogłyby określić, jaki odsetek Twojego ruchu pochodzi z platform takich jak wyszukiwarka Google w porównaniu z innymi źródłami.
Wpływ pamięci podręcznej stanu strony internetowej na LCP
Gdy strony są przywracane z pamięci podręcznej bfcache, wczytywanie przebiega niemal natychmiastowo, a te działania są uwzględniane w danych z pola.
Testy laboratoryjne nie uwzględniają bfcache, więc jeśli Twoje strony są przystosowane do bfcache, prawdopodobnie uzyskasz szybsze wyniki LCP w sprawdzie w warunkach rzeczywistych.
Wpływ interakcji użytkownika na LCP
LCP określa czas renderowania największego obrazu lub bloku tekstu w widocznym obszarze, ale ten największy element może się zmieniać podczas wczytywania strony lub jeśli nowa treść jest dynamicznie dodawana do widocznego obszaru.
W laboratorium przeglądarka czeka, aż strona zostanie w pełni załadowana, zanim określi, czym był element LCP. Jednak w przypadku pól przeglądarka przestanie monitorować większe elementy, gdy użytkownik przewinie stronę lub wejdzie z nią w interakcję.
To ma sens (i jest konieczne), ponieważ użytkownicy zwykle czekają z działaniem na stronie, dopóki nie „wyda się”, że została ona załadowana. Właśnie to ma wykrywać wskaźnik LCP. Nie ma też sensu uwzględnianie elementów dodanych do widoku po interakcji użytkownika, ponieważ mogły one zostać załadowane tylko z powodu działania użytkownika.
Oznacza to jednak, że dane zgromadzone na temat strony mogą wskazywać krótsze czasy LCP, w zależności od tego, jak użytkownicy się na niej zachowują.
INP
Interakcja INP wymaga interakcji z użytkownikiem
Dane INP mierzą, jak responsywna jest strona w odniesieniu do interakcji użytkowników w momencie, gdy użytkownicy faktycznie z nią wchodzą w interakcję.
Druga część tego zdania jest kluczowa, ponieważ testy laboratoryjne, nawet te, które obsługują skrypt zachowania użytkownika, nie są w stanie dokładnie przewidzieć, kiedy użytkownicy zdecydują się na interakcję ze stroną, a więc nie mogą dokładnie mierzyć FID.
TBT nie uwzględnia zachowań użytkowników.
Dane laboratoryjne Całkowity czas blokowania (TBT) pomagają zdiagnozować problemy z interfejsem INP, ponieważ określają, jak długo wątek główny był zablokowany podczas wczytywania strony.
Założenie jest takie, że strony z dużą ilością kodu JavaScript w trybie synchronicznym lub innymi zadaniami wymagającymi intensywnego renderowania mają większe szanse na zablokowanie głównego wątku podczas pierwszej interakcji użytkownika. Jeśli jednak użytkownicy zaczną wchodzić w interakcję ze stroną dopiero po zakończeniu wykonywania kodu JavaScript, INP może być bardzo niski.
To, kiedy użytkownicy wejdą w interakcję ze stroną, zależy głównie od tego, czy wygląda na interaktywną, a tego nie można zmierzyć za pomocą TBT.
TBT nie uwzględnia opóźnienia dotknięcia
Jeśli witryna nie jest zoptymalizowana pod kątem wyświetlania na urządzeniach mobilnych, przeglądarki dodadzą opóźnienie 300 ms po każdym kliknięciu przed uruchomieniem modułów obsługi zdarzeń. Dzieje się tak, ponieważ zanim aplikacja będzie mogła wywołać zdarzenia myszy lub kliknięcia, musi określić, czy użytkownik próbuje dwukrotnie dotknąć ekranu, aby powiększyć obraz.
To opóźnienie jest uwzględniane w wartości INP strony, ponieważ wpływa na rzeczywistą latencję wprowadzania danych przez użytkowników. Ponieważ jednak technicznie nie jest to długie zadanie, nie wpływa na TBT strony. Oznacza to, że strona może mieć słaby wskaźnik INP, mimo że ma bardzo dobre wyniki TBT.
Wpływ stanu pamięci podręcznej i bfcache na INP
Podobnie jak prawidłowe przechowywanie w pamięci podręcznej może poprawić LCP w terenie, może też poprawić INP.
W rzeczywistych warunkach użytkownik może mieć skrypt JavaScript witryny w pamięci podręcznej, więc przetworzenie go może zabrać mniej czasu i spowodować mniejsze opóźnienia.
To samo dotyczy stron przywracanych z pamięci podręcznej stanu strony internetowej. W takich przypadkach kod JavaScript jest przywracany z pamięci, więc czas przetwarzania może być niewielki lub wcale nie wystąpić.
CLS
Wpływ interakcji użytkownika na CLS
CLS zmierzony w laboratorium uwzględnia tylko przesunięcia układu, które występują powyżej zagięcia i podczas wczytywania, ale jest to tylko podzbiór tego, co CLS faktycznie mierzy.
W tym polu CLS uwzględnia wszystkie nieoczekiwane przesunięcia układu, które występują w całym okresie działania strony, w tym przesunięcia treści podczas przewijania przez użytkownika lub w odpowiedzi na powolne żądania sieci po interakcji użytkownika.
Na przykład strony często ładują obrazy lub elementy iframe z lazy load bez wymiarów, co może powodować zmiany układu, gdy użytkownik przewija te sekcje strony. Jednak te zmiany mogą wystąpić tylko wtedy, gdy użytkownik przewinie stronę w dół, co często nie jest wychwytywane w testach laboratoryjnych.
Spersonalizowana treść
Treści spersonalizowane, w tym reklamy kierowane i testy A/B, wpływają na to, które elementy są wczytywane na stronie. Ma to też wpływ na sposób ich wczytywania, ponieważ treści spersonalizowane są często wczytywane później i wstawiane do głównej treści strony, co powoduje zmiany układu.
W laboratorium strona jest zwykle wczytywana bez treści spersonalizowanych lub z treściami dla ogólnego „użytkownika testowego”, co może, ale nie musi wywołać zmiany widoczne dla prawdziwych użytkowników.
Dane z pól obejmują działania wszystkich użytkowników, więc liczba (i stopień) przesunięć układu na danej stronie zależy w dużej mierze od tego, jakie treści są wczytywane.
Wpływ stanu pamięci podręcznej i bfcache na CLS
Dwie najczęstsze przyczyny przesunięć układu podczas wczytywania to obrazy i ramki iframe bez wymiarów (jak wspomniano powyżej) oraz wolno wczytujące się czcionki internetowe. Oba te problemy mogą mieć większy wpływ na wrażenia użytkownika podczas pierwszego odwiedzenia witryny, gdy jego pamięć podręczna jest pusta.
Jeśli zasoby strony są przechowywane w pamięci podręcznej lub jeśli sama strona jest przywracana z pamięci podręcznej, przeglądarka może zwykle renderować obrazy i czcionki od razu, bez oczekiwania na ich pobranie. Może to spowodować, że wartości CLS w polu będą niższe niż te, które raportuje narzędzie laboratoryjne.
Co zrobić, gdy wyniki są różne
Ogólnie, jeśli masz dane z pola i dane z laboratorium dotyczące danej strony, to dane z pola powinny być używane do ustalania priorytetów. Dane z pola odzwierciedlają wrażenia prawdziwych użytkowników, dlatego są najlepszym sposobem na zrozumienie, z czym mają oni problemy i co należy poprawić.
Z drugiej strony, jeśli dane z pola wskazują na dobre wyniki we wszystkich obszarach, ale dane z testów wskazują, że nadal można coś poprawić, warto sprawdzić, jakie dalsze optymalizacje można wprowadzić.
Co więcej, chociaż dane z pól rejestrują wrażenia prawdziwych użytkowników, dzieje się tak tylko w przypadku użytkowników, którym udało się załadować Twoją witrynę. Dane z testów laboratoryjnych mogą czasami pomóc w określaniu możliwości rozszerzenia zasięgu witryny i zwiększenia jej dostępności dla użytkowników korzystających z wolniejszych sieci lub tańszych urządzeń.
Ogólnie rzecz biorąc, zarówno dane laboratoryjne, jak i dane z pola są ważnymi elementami skutecznego pomiaru skuteczności. Oba rozwiązania mają swoje zalety i ograniczenia. Jeśli korzystasz tylko z jednego z nich, możesz nie wykorzystać możliwości poprawy wrażeń użytkowników.