Pomiar Core Web Vitals od własnych użytkowników: zbieranie wskaźników w Google Analytics

Po co zbierać Core Web Vitals od własnych użytkowników

Własny pomiar daje to, czego nie pokazują zbiorcze dane Google: wynik dla każdej podstrony z osobna, podział na dowolne grupy odwiedzających i informację, który element strony zawinił. Core Web Vitals, czyli podstawowe wskaźniki internetowe, to trzy miary: LCP (czas wyświetlenia największego elementu treści), INP (czas reakcji strony na działanie użytkownika) oraz CLS (skala niespodziewanych przesunięć układu). Google ocenia je na podstawie danych z raportu Chrome User Experience Report, w skrócie CrUX, czyli zbioru pomiarów od użytkowników przeglądarki Chrome.

Dane CrUX są wiarygodne, ale mają ograniczenia opisane w serwisie web.dev. Obejmują przesuwane okno 28 dni, więc efekt poprawki widać w nich z opóźnieniem. Dotyczą wyłącznie Chrome i tylko tych osób, które zgodziły się na przesyłanie statystyk. Dla mniej popularnych podstron dane na poziomie adresu mogą w ogóle nie być dostępne. Jak zaznacza opis wskaźników w serwisie web.dev, CrUX nie zawiera szczegółów pojedynczych odsłon, dlatego Google zaleca uzupełnienie go własnym monitoringiem rzeczywistych użytkowników.

W praktyce różnica wygląda następująco. W Search Console raport Podstawowe wskaźniki internetowe informuje, że grupa adresów ma słaby wynik INP na telefonach. Nie wiadomo jednak, czy problem dotyczy menu, filtrów, formularza, czy może okna czatu. Własne zdarzenia w Google Analytics pozwalają odpowiedzieć na to pytanie, ponieważ przy każdym pomiarze zapisuje się adres podstrony, typ urządzenia, źródło wizyty i wskazanie konkretnego elementu.

Własny pomiar nie zastępuje danych CrUX, tylko je uzupełnia. To na podstawie CrUX Google ocenia stronę, natomiast zdarzenia w Analytics służą do szukania przyczyn i sprawdzania, czy wdrożone zmiany przynoszą efekt. Skąd biorą się rozbieżności między narzędziami, wyjaśniamy we wpisie o tym, dlaczego wynik testu różni się od danych od użytkowników.

Jak działa biblioteka web-vitals

Biblioteka web-vitals to niewielki skrypt, który korzysta z interfejsów przeglądarki i przekazuje gotowy wynik każdego wskaźnika do wskazanej funkcji. Jest przygotowana do użytku na działających stronach i mierzy wskaźniki tak, jak raportują je narzędzia Google. Jej kod i opis znajdują się w repozytorium web-vitals zespołu Chrome.

Biblioteka udostępnia pięć funkcji: onLCP, onINP, onCLS oraz dodatkowo onFCP i onTTFB dla dwóch wskaźników pomocniczych. Każda przyjmuje funkcję, która zostanie wywołana, gdy wynik będzie gotowy. Do tej funkcji trafia obiekt z kilkoma polami, które staną się parametrami zdarzenia w Analytics.

Ocena w polu rating opiera się na progach zapisanych w bibliotece. Dla LCP wynik dobry to najwyżej 2500 milisekund, a słaby zaczyna się powyżej 4000 milisekund. Dla INP granice wynoszą 200 i 500 milisekund, a dla CLS 0,1 oraz 0,25. Autorzy zalecają korzystanie z gotowej oceny zamiast samodzielnego porównywania wartości z progami.

Kiedy biblioteka zgłasza wynik

Wskaźniki nie są gotowe w tym samym momencie i nie każda wizyta dostarcza wszystkich trzech. INP nie zostanie zgłoszony, jeśli odwiedzający niczego nie kliknął ani nie wpisał. LCP i CLS nie są zgłaszane, gdy strona wczytała się w karcie otwartej w tle. CLS i INP biblioteka przekazuje w chwili, gdy strona przestaje być widoczna, czyli przy przejściu do innej karty lub zamknięciu okna, a funkcja może zostać wywołana więcej niż raz podczas jednej wizyty. Po przywróceniu strony z pamięci podręcznej stanu strony wskaźniki są zgłaszane ponownie, jako nowy pomiar. Z tych zasad wynika ważny wniosek: liczba zdarzeń LCP, INP i CLS w Analytics nigdy nie będzie równa liczbie odsłon. To prawidłowe zachowanie, a nie błąd wdrożenia.

Obsługiwane przeglądarki

Według dokumentacji funkcje mierzące LCP, INP, FCP i TTFB działają w przeglądarkach opartych na Chromium, w Firefoksie i w Safari, natomiast pomiar CLS jest dostępny wyłącznie w przeglądarkach opartych na Chromium. Dla firmy, której klienci często korzystają z telefonów z Safari, oznacza to, że dane o przesunięciach układu będą pochodziły tylko z części ruchu.

Jak wysłać LCP, INP i CLS jako zdarzenia do Google Analytics

Wystarczy wczytać bibliotekę na stronie i przekazać jej funkcję, która dla każdego wyniku wywoła polecenie gtag ze zdarzeniem o nazwie wskaźnika. Dokumentacja biblioteki zawiera gotowy wzór takiej funkcji; poniżej pokazujemy wariant dla strony, na której znacznik Google jest wstawiony bezpośrednio w kodzie.

Bibliotekę można zainstalować w projekcie jako pakiet albo wczytać jako zwykły plik skryptu. Dostępna jest w publicznych sieciach dostarczania treści, lecz autorzy podkreślają, że sieci te nie są związane z Google, i zalecają umieszczenie pliku na własnym serwerze ze względu na bezpieczeństwo, niezawodność i szybkość. Zaznaczają też, że skrypt nie musi ładować się na samym początku: przeglądarka przechowuje wcześniejsze pomiary, więc bibliotekę warto wczytać dopiero po kodzie, który ma bezpośredni wpływ na odwiedzającego.

<script defer src="/js/web-vitals.attribution.iife.js"></script>
<script>
window.addEventListener('load', function () {
  function wyslijDoAnalytics(metric) {
    var parametry = {
      value: metric.delta,
      metric_id: metric.id,
      metric_value: metric.value,
      metric_delta: metric.delta,
      metric_rating: metric.rating
    };
    if (metric.name === 'CLS') {
      parametry.debug_target = metric.attribution.largestShiftTarget;
    }
    if (metric.name === 'INP') {
      parametry.debug_target = metric.attribution.interactionTarget;
    }
    if (metric.name === 'LCP') {
      parametry.debug_target = metric.attribution.target;
    }
    gtag('event', metric.name, parametry);
  }
  webVitals.onCLS(wyslijDoAnalytics);
  webVitals.onINP(wyslijDoAnalytics);
  webVitals.onLCP(wyslijDoAnalytics);
});
</script>

Znaczenie parametrów jest następujące. W polu value trafia delta, czyli zmiana od poprzedniego zgłoszenia, dzięki czemu wartości tego samego pomiaru można sumować. Parametr metric_id pozwala złączyć zgłoszenia należące do jednego pomiaru. Parametry metric_value i metric_delta zawierają bieżącą wartość i zmianę, a metric_rating gotową ocenę. Parametr debug_target przechowuje wskazanie elementu strony i jest dostępny tylko w wersji biblioteki z atrybucją; według dokumentacji ta wersja jest większa od podstawowej o około półtora kilobajta po kompresji.

Wdrożenie przez Menedżera tagów Google

Jeżeli Analytics działa na stronie przez Menedżera tagów Google, polecenie gtag zwykle nie jest dostępne i powyższy kod nie wyśle zdarzeń. Dokumentacja biblioteki podaje, że web-vitals można uruchomić bezpośrednio z Menedżera tagów, lecz znacznie łatwiej użyć gotowego szablonu niestandardowego przygotowanego do tego celu. O porządkowaniu kontenera piszemy we wpisie Google Tag Manager a szybkość strony.

Sprawdzenie, czy zdarzenia docierają

Po wdrożeniu należy otworzyć stronę w zwykłej karcie, kliknąć dowolny element, a następnie przejść do innej karty, aby biblioteka zgłosiła także INP i CLS. W Google Analytics, w raporcie Czas rzeczywisty, na karcie z liczbą zdarzeń według nazwy zdarzenia powinny pojawić się pozycje LCP, INP i CLS. Pomoc Google zaleca wykonanie takiej kontroli przed rejestrowaniem wymiarów niestandardowych. Zdarzeń LCP będzie zwykle najwięcej, CLS mniej, a INP najmniej, co wynika z opisanych wcześniej zasad zgłaszania.

Rejestracja parametrów jako wymiarów i danych niestandardowych

Parametry wysyłane ze zdarzeniem nie pojawiają się w raportach same z siebie - trzeba je zarejestrować w ustawieniach usługi Google Analytics. Tekstowe parametry, takie jak ocena i wskazanie elementu, rejestruje się jako wymiary niestandardowe o zakresie zdarzenia, a liczbowe jako dane niestandardowe.

Ścieżka opisana w pomocy Google Analytics wygląda następująco: Administracja, sekcja Wyświetlanie danych, pozycja Definicje niestandardowe, karta Wymiary niestandardowe, a następnie przycisk tworzenia wymiaru niestandardowego. Formularz ma cztery pola: Nazwa wymiaru, Zakres, Opis oraz Parametr zdarzenia. W polu Zakres należy wskazać Zdarzenie, a w polu Parametr zdarzenia wpisać nazwę dokładnie taką, jak w kodzie strony. Zakresu i parametru nie da się zmienić po zapisaniu. W nazwie wymiaru nie wolno używać łączników, dozwolone są spacje i podkreślenia. Do wykonania tej czynności potrzebna jest rola Edytujący lub wyższa.

Kilka zasad z opisu wymiarów i danych niestandardowych ma tu bezpośrednie znaczenie. Zarejestrowane definicje pojawiają się w raportach i eksploracjach po 24-48 godzinach. Usługa standardowa mieści 50 wymiarów o zakresie zdarzenia i 50 danych niestandardowych. Google odradza rejestrowanie wymiarów o bardzo wielu unikalnych wartościach, takich jak identyfikatory sesji czy znaczniki czasu, ponieważ pogarszają one raporty, a część wierszy trafia do zbiorczej pozycji (inne). Z tego powodu parametru metric_id nie warto rejestrować jako wymiaru - jest potrzebny dopiero przy pracy na surowych danych.

Obowiązują też limity zbierania danych. Według zestawienia limitów Google Analytics jedno zdarzenie może mieć 25 parametrów, a wartość parametru 100 znaków. Długie wskazanie elementu, złożone z wielu klas, może więc nie zmieścić się w całości.

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

Raporty według podstron, urządzeń i źródeł ruchu

Zestawienia wskaźników buduje się w eksploracjach Google Analytics, łącząc nazwę zdarzenia z wymiarem opisującym podstronę, urządzenie lub źródło wizyty. Standardowe raporty nie mają gotowego widoku dla Core Web Vitals, dlatego potrzebna jest własna tabela.

Eksploracje otwiera się z lewego menu Analytics. Zgodnie z pomocą dotyczącą eksploracji najprostszą metodą jest Eksploracja swobodna, która przedstawia dane w tabeli krzyżowej. W panelu Zmienne dodaje się potrzebne wymiary i dane znakiem plusa, a potem przenosi je do panelu Ustawienia karty: wymiary do sekcji Wiersze, dane do sekcji Wartości. Na jednej karcie można ustawić do 10 filtrów.

Podstawowa tabela powstaje w kilku ruchach. Do wierszy trafia wymiar ze ścieżką strony, do wartości liczba zdarzeń, a filtr ogranicza widok do zdarzenia o nazwie LCP. Dodanie wymiaru Ocena wskaźnika jako kolumn pokazuje, ile pomiarów na każdej podstronie zakończyło się wynikiem dobrym, wymagającym poprawy i słabym. Tę samą tabelę warto powielić na kolejnych kartach dla INP i CLS, a w miejsce ścieżki strony podstawić kategorię urządzenia albo źródło i medium sesji. Dokładne polskie nazwy wymiarów wbudowanych najlepiej wyszukać w panelu Zmienne.

Jak czytać takie zestawienia

Podział według podstron wskazuje, gdzie zacząć. Jeśli większość słabych wyników LCP pochodzi z kart produktów, a strony kategorii wypadają dobrze, przyczyna leży zapewne w szablonie karty, na przykład w dużym zdjęciu głównym. Podział według urządzeń pokazuje, czy problem dotyczy telefonów, komputerów, czy obu grup; Google zaleca ocenianie wskaźników osobno dla urządzeń mobilnych i komputerów. Podział według źródeł ruchu bywa najbardziej zaskakujący: odwiedzający z reklam często trafiają na inne podstrony i korzystają z innych urządzeń niż osoby z wyników wyszukiwania, więc ich doświadczenie może się wyraźnie różnić.

Eksploracje mają swoje ograniczenia. Zapytania obejmujące ponad 10 milionów zdarzeń mogą być próbkowane, a przy małych liczbach działają progi chroniące prywatność; w obu sytuacjach ikona w prawym górnym rogu zmienia kolor z zielonego na żółty. Domyślny okres przechowywania danych do eksploracji wynosi 2 miesiące i można go zmienić w Administracji, w sekcji Zbieranie i modyfikowanie danych, w pozycji Przechowywanie danych.

Rozkład wyników i 75. percentyl: kiedy potrzebny jest eksport do BigQuery

Dokładny wynik w ujęciu, którego używa Google, czyli 75. percentyl, wymaga pracy na surowych danych, ponieważ wbudowane raporty Analytics nie liczą rozkładu wartości. Google zaleca ocenianie strony właśnie według 75. percentyla wizyt: wynik jest dobry, gdy co najmniej trzy czwarte pomiarów mieści się w progu.

Dokumentacja biblioteki wskazuje dwie drogi do rozkładu: interfejs danych Google Analytics albo eksport do BigQuery, czyli hurtowni danych Google, w której zdarzenia można przeszukiwać językiem zapytań. Eksport uruchamia się w Administracji, w sekcji Połączenia usług, w pozycji Połączenia z BigQuery. Pomoc Google dotycząca konfiguracji eksportu opisuje kolejne czynności: utworzenie projektu w Google Cloud i włączenie w nim interfejsu BigQuery, połączenie projektu z usługą Analytics, wybór lokalizacji danych i strumieni, a na koniec rodzaju eksportu - codziennego, strumieniowego albo obu. W usłudze standardowej eksport codzienny obejmuje do miliona zdarzeń dziennie, a dane zaczynają napływać w ciągu doby od połączenia.

Przy liczeniu wyników obowiązuje jedna ważna zasada, opisana w omówieniu pomiaru w serwisie web.dev. Ten sam wskaźnik bywa zgłaszany kilka razy podczas jednej wizyty, co szczególnie często dotyczy CLS. Najdokładniejsza jest ostatnia przesłana wartość, dlatego przed liczeniem percentyla zostawia się po jednym wierszu na każdy identyfikator metric_id. Ten sam materiał zaleca przedstawienie wyników w Looker Studio, narzędziu Google do budowania paneli, dla którego dostępny jest gotowy łącznik z zakładkami podsumowania, analizy ścieżek stron i wskazań elementów.

Nie każda firma potrzebuje tego poziomu szczegółowości. Dla strony usługowej z kilkudziesięcioma podstronami tabela z liczbą ocen dobrych i słabych w eksploracji zwykle wystarcza, aby wskazać miejsca do poprawy. Eksport do BigQuery ma sens w sklepach i dużych serwisach, w których wyniki porównuje się z danymi CrUX albo łączy z informacją o sprzedaży. Budowę takich zestawień prowadzimy w ramach usługi analityka i raportowanie SEO.

Jak wskazać element odpowiedzialny za słaby wynik

Element wskazuje wersja biblioteki z atrybucją: do każdego wyniku dołącza ona informacje diagnostyczne, w tym selektor elementu strony, który zdecydował o wartości wskaźnika. W zdarzeniu Analytics trafia on do parametru debug_target, a po zarejestrowaniu wymiaru można zestawić go ze ścieżką strony i oceną.

Dla każdego wskaźnika wskazanie oznacza coś innego. Przy LCP jest to element uznany za największy w widocznej części strony. Jak zauważa opis diagnozowania wydajności w serwisie web.dev, u różnych osób bywa to inny element, bo zależy od rozmiaru ekranu, treści dopasowanych do odwiedzającego i miejsca, do którego prowadził link. Przy CLS wskazanie dotyczy elementu z największego pojedynczego przesunięcia; jeśli nic się nie przesunęło, pole pozostaje puste. Przy INP jest to element, z którym użytkownik wszedł w interakcję, zanim strona zareagowała.

Wersja z atrybucją dostarcza też rozbicie wyniku na etapy. Dla LCP są to między innymi czas do pierwszego bajtu odpowiedzi, opóźnienie rozpoczęcia pobierania zasobu, czas pobierania i opóźnienie wyrenderowania elementu. Dla INP dostępne są rodzaj interakcji (wskaźnik lub klawiatura), opóźnienie wejścia, czas przetwarzania, opóźnienie prezentacji oraz stan wczytywania strony w chwili interakcji. Dla CLS biblioteka podaje moment największego przesunięcia i stan wczytywania. Każdą z tych wartości można wysłać jako kolejny parametr zdarzenia, w granicach limitu 25 parametrów.

Hipotetyczny przykład pokazuje, jak z tego korzystać. Hydraulik z Łodzi ma stronę z dużym zdjęciem w nagłówku i pływającym przyciskiem telefonu. Zestawienie wymiaru Element odpowiedzialny dla zdarzeń CLS o ocenie słabej wskazuje w większości wierszy ten sam pasek z informacją o plikach cookie. Poprawka dotyczy więc jednego elementu, a nie całego układu. Sposoby usuwania takich problemów opisujemy osobno dla każdego wskaźnika: LCP, INP i CLS.

Ograniczenia pomiaru: zgody, przeglądarki i ramki

Własny pomiar obejmuje tylko te wizyty, przy których znacznik Analytics może działać, dlatego nigdy nie pokaże całego ruchu. Największy wpływ mają ustawienia zgód, a w dalszej kolejności różnice między przeglądarkami i sposób liczenia treści osadzonych w ramkach.

Wpływ zgód na dane

Sposób wdrożenia trybu uzyskiwania zgody decyduje o tym, czy zdarzenia w ogóle zostaną wysłane. Pomoc Google Analytics dotycząca trybu uzyskiwania zgody rozróżnia dwa warianty. W implementacji podstawowej tagi Google są blokowane do chwili udzielenia zgody, więc od osób, które jej nie wyraziły, nie napływają żadne dane. W implementacji zaawansowanej tagi wczytują się przed wyświetleniem okna zgody, a po odmowie wysyłają sygnały bez plików cookie. Szczegóły obu wariantów omawiamy we wpisie Tryb uzyskiwania zgody Google.

Zgody wpływają nie tylko na liczbę pomiarów, ale i na ich wartości. Serwis web.dev w zestawieniu różnic między CrUX a własnym pomiarem zwraca uwagę na konkretny mechanizm: jeżeli zgoda pojawia się dopiero po pierwszej odsłonie, z pomiaru wypadają pierwsze, zwykle wolniejsze wczytania strony, a zebrane dane wyglądają lepiej niż rzeczywistość. Sam pasek zgody także bywa źródłem problemów ze wskaźnikami, co opisujemy we wpisie o banerze zgody a szybkości strony.

To, czy i w jakim zakresie pomiar wydajności wymaga zgody odwiedzającego, zależy od sposobu wdrożenia i od przepisów o prywatności. Przy wątpliwościach decyzję warto skonsultować z prawnikiem lub inspektorem ochrony danych.

Dlaczego wyniki różnią się od danych Google

Poza zgodami istnieje kilka powodów, dla których własne liczby nie pokryją się z CrUX. Dane Google pochodzą wyłącznie z Chrome, podczas gdy biblioteka mierzy także w innych przeglądarkach. CrUX uwzględnia treść w ramkach, a skrypt działający na stronie nie ma do niej dostępu; dokumentacja biblioteki potwierdza, że dotyczy to również ramek z tej samej domeny. Web.dev radzi, aby przy porównaniach zawęzić własne dane do użytkowników Chrome, tego samego typu urządzeń, 75. percentyla i okna 28 dni.

Typowe pomyłki przy wdrożeniu i odczytywaniu wyników

Najwięcej błędów bierze się z traktowania zdarzeń wskaźników jak zwykłych odsłon: liczenia średniej ze wszystkich zgłoszeń, porównywania liczby zdarzeń z liczbą wizyt i oceniania podstron po kilku pomiarach.

Pierwsza grupa pomyłek dotyczy samego kodu. Zdarza się wczytanie biblioteki dwa razy, raz w szablonie i raz przez Menedżera tagów, co podwaja zdarzenia. Częsta jest również literówka w nazwie parametru podczas rejestracji wymiaru - ponieważ pola Parametr zdarzenia nie da się poprawić po zapisaniu, wymiar trzeba utworzyć od nowa.

Druga grupa dotyczy odczytu. Sumowanie parametru metric_value z kilku zgłoszeń tego samego pomiaru zawyża wynik, bo każde zgłoszenie zawiera pełną bieżącą wartość; do sumowania służy delta. Średnia arytmetyczna bywa myląca, ponieważ kilka bardzo słabych wizyt potrafi ją mocno przesunąć, dlatego Google posługuje się 75. percentylem.

• Biblioteka wczytuje się raz, z własnego serwera, po kodzie ważnym dla odwiedzającego.
• Zdarzenia LCP, INP i CLS są widoczne w raporcie Czas rzeczywisty.
• Parametry tekstowe są zarejestrowane jako wymiary, a liczbowe jako dane niestandardowe.
• Identyfikator pomiaru nie jest zarejestrowany jako wymiar.
• Wiadomo, jaki wariant trybu zgody działa na stronie.
• Wnioski opierają się na podstronach z wystarczającą liczbą pomiarów.

Kiedy potrzebna jest pomoc specjalisty

Samo wklejenie kodu jest w zasięgu osoby, która opiekuje się stroną. Wsparcie przydaje się wtedy, gdy Analytics działa przez Menedżera tagów z rozbudowanymi regułami zgód, gdy potrzebny jest eksport do BigQuery i panel z 75. percentylem, a także wtedy, gdy dane wskazują winny element, lecz jego poprawa wymaga zmian w szablonie lub wtyczkach. Zajmujemy się tym w ramach usługi SEO techniczne, a szersze omówienie wskaźników znajduje się we wpisie Core Web Vitals: jak poprawić LCP, INP i CLS.

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