Dowiedz się, jak przypisywać dane o skuteczności za pomocą informacji debugowania aby pomóc Ci identyfikować i rozwiązywać problemy użytkowników za pomocą Analytics
Google udostępnia 2 kategorie narzędzi do pomiaru i debugowania skuteczności:
- Narzędzia w Laboratorium: narzędzia takie jak Lighthouse, w których strona jest wczytywana symulowane środowisko, które może naśladować różne warunki (np. powolne działanie przez sieć komórkową i telefon komórkowy niskiej klasy).
- Narzędzia terenowe: narzędzia takie jak Chrome User Experience Zgłoś (CrUX), który jest oparty na zbiorczych danych rzeczywistych użytkowników z Chrome. (Pamiętaj, że dane terenowe zgłaszane przez narzędzia takie jak PageSpeed Statystyki i wyszukiwarka Konsola pochodzi z dane raportu na temat użytkowania Chrome).
Narzędzia terenowe zapewniają dokładniejsze dane, rzeczywiste wrażenia użytkowników — narzędzia laboratoryjne często są lepsze w identyfikowaniu i rozwiązywaniu problemów problemów.
Dane raportu na temat użytkowania Chrome są bardziej reprezentatywne dla rzeczywistej skuteczności strony, ale wiedzą, wyniki raportu CrUX raczej nie pomogą Ci w określeniu, jak polepszyć skuteczność reklam.
Z kolei narzędzie Lighthouse wykryje problemy i określi podpowiedzi, jak ją ulepszyć. Pamiętaj jednak, że Lighthouse będzie podawać tylko sugestie w przypadku problemów z wydajnością wykrytych podczas wczytywania strony. Nie wykrywa problemów które pojawiają się wyłącznie w wyniku interakcji użytkownika, np. przewijania lub kliknięcia; przyciski na stronie.
Pojawia się ważne pytanie: jak zebrać informacje na potrzeby debugowania podstawowych wskaźników internetowych lub innych danych dotyczących wydajności od rzeczywistych użytkowników w terenie?
W tym poście wyjaśnimy szczegółowo, za pomocą jakich interfejsów API możesz zbierać dodatkowe dane debugowania dotyczące każdego z bieżących wskaźników Podstawowych wskaźników internetowych oraz pomysły na rejestrowanie tych danych w używanym już narzędziu analitycznym.
Interfejsy API do atrybucji i debugowania
Skumulowane przesunięcie układu (CLS)
Spośród wszystkich podstawowych wskaźników internetowych CLS jest chyba tym, w przypadku którego zbieranie w tym polu informacji na potrzeby debugowania jest najważniejsze. Mierzony jest CLS na każdym etapie cyklu życia strony, czyli sposób interakcji użytkownika z – odległość, jaką przewijają, co klikają itd. – mogą mieć duży wpływ wpływ na to, czy występują przesunięcia układu i które elementy się przesuną.
Zobacz następujący raport z PageSpeed Insights:
Zgłoszona wartość CLS z laboratorium (Lighthouse) w porównaniu z CLS z okresu (dane na temat użytkowania Chrome) są nieco inne. Ma to sens, jeśli że strona może zawierać dużo interaktywnych treści, nie jest używana podczas testów w Lighthouse.
Nawet jeśli rozumiesz, że interakcja użytkownika wpływa na dane w terenie, muszą wiedzieć, które elementy na stronie przesuwają się, aby uzyskać wynik 0,28. na 75. percentylu. Metoda LayoutShiftAttribution interfejs, który to umożliwia.
Pobierz atrybucję przesunięcia układu
Metoda LayoutShiftAttribution
interfejs jest widoczny w każdej pozycji layout-shift, w której niestabilność układu
Interfejs API przesyła treści.
Szczegółowe omówienie obu tych interfejsów znajdziesz w artykule Debuguj układ . Na potrzeby Najważniejsze jest to, że jako deweloper umożliwia obserwowanie każdego przesunięcia układu strony i sprawdzanie, jakie elementy zmieniają się.
Oto przykładowy kod, który rejestruje każde przesunięcie układu oraz elementy które się zmieniło:
new PerformanceObserver((list) => {
for (const {value, startTime, sources} of list.getEntries()) {
// Log the shift amount and other entry info.
console.log('Layout shift:', {value, startTime});
if (sources) {
for (const {node, curRect, prevRect} of sources) {
// Log the elements that shifted.
console.log(' Shift source:', node, {curRect, prevRect});
}
}
}
}).observe({type: 'layout-shift', buffered: true});
Mierzenie i wysyłanie danych do narzędzia analitycznego w celu każde jedno przesunięcie układu, Jednak monitorując wszystkie zmiany, śledzić najgorsze zmiany i generować raporty na ich temat.
Celem nie jest identyfikacja i naprawianie każdego pojedynczego przesunięcia układu, który zachodzi każdego użytkownika; celem jest zidentyfikowanie zmian, które wpływają na największą liczbę użytkowników i tym samym mają największy wpływ na CLS strony na 75. percentylu.
Nie musisz też określać największego elementu źródłowego za każdym razem, gdy występuje musisz to zrobić tylko wtedy, gdy chcesz wysłać wartość CLS do narzędzie analityczne.
Ten kod pobiera listę layout-shift wpisów, które zostały przekazane
do CLS i zwraca największy element źródłowy od największego przesunięcia:
function getCLSDebugTarget(entries) {
const largestEntry = entries.reduce((a, b) => {
return a && a.value > b.value ? a : b;
});
if (largestEntry && largestEntry.sources && largestEntry.sources.length) {
const largestSource = largestEntry.sources.reduce((a, b) => {
return a.node && a.previousRect.width * a.previousRect.height >
b.previousRect.width * b.previousRect.height ? a : b;
});
if (largestSource) {
return largestSource.node;
}
}
}
Po zidentyfikowaniu największego elementu wpływającego na największe przesunięcie możesz to zgłosić w narzędziu analitycznym.
Element mający największy wpływ na CLS w przypadku danej strony będzie się prawdopodobnie różnić od między użytkownikami, ale jeśli zbierzesz te elementy na wszystkich użytkowników, aby wygenerować listę zmieniających się elementów, które wpływają na największą liczbę użytkowników.
Po zidentyfikowaniu i usunięciu głównej przyczyny zmian , kod Analytics zacznie raportować mniejsze zmiany jako „najgorsze” Twoje strony. W końcu wszystkie raportowane zmiany będą na tyle niewielkie, Twoje strony mają dobrą jakość próg 0,1!
inne metadane, które mogą być przydatne przy rejestrowaniu wraz z największym przesunięciem. element źródłowy to:
- Czas największej zmiany
- Ścieżka adresu URL w momencie największej zmiany (w przypadku witryn, które dynamicznie zaktualizować adres URL, np. aplikacje na jednej stronie).
Największe wyrenderowanie treści (LCP)
Aby debugować LCP w tym polu, potrzebne są podstawowe informacje: był największym elementem (elementem kandydującym do LCP) dla tego konkretnego wczytanie strony.
Zwróć uwagę, że jest całkowicie możliwe – w rzeczywistości jest to dość powszechne – że wskaźnik LCP kandydujący element będzie się różnić w zależności od użytkownika, nawet w przypadku dokładnie tego samego stronę.
Dzieje się tak z kilku powodów:
- Urządzenia użytkowników mają różne rozdzielczości ekranu, co powoduje różne układy stron, a przez to wyświetlanie różnych elementów w widocznym obszarze.
- Użytkownicy nie zawsze wczytują strony, które znajdują się na samej górze. Linki często zawierają identyfikatory fragmentów, a nawet fragmenty tekstu, co oznacza, że mogą być wczytywania i wyświetlania stron w każdej pozycji przewijania na stronie.
- Treści mogą być personalizowane pod kątem bieżącego użytkownika, więc element kandydujący LCP mogą się znacznie różnić w zależności od użytkownika.
Oznacza to, że nie można wyciągnąć wniosków dotyczących tego, który element lub zestaw elementów będzie najczęstszym elementem kandydującym do LCP w przypadku danej strony. Musisz na podstawie rzeczywistych zachowań użytkowników.
Określ element kandydujący LCP
Aby określić w JavaScripcie kandydujący element LCP, możesz użyć funkcji Największy Contentful Paint API, za pomocą tego samego interfejsu API, którego używasz do określania wartości czasu LCP.
Obserwując wpisy largest-contentful-paint, możesz określić
obecny element kandydujący LCP, patrząc na właściwość element ostatniego wpisu:
new PerformanceObserver((list) => {
const entries = list.getEntries();
const lastEntry = entries[entries.length - 1];
console.log('LCP element:', lastEntry.element);
}).observe({type: 'largest-contentful-paint', buffered: true});
Gdy już znasz element kandydujący LCP, możesz przesłać go do swojego narzędzia analitycznego. wraz z wartością danych. Podobnie jak w przypadku CLS, pomoże Ci to określić, najważniejsza jest optymalizacja w pierwszej kolejności.
Oprócz kandydującego elementu LCP przydaje się też pomiar podczasy podpunktów LCP, co może być przydatne. w określaniu, jakie konkretne czynności optymalizacyjne są odpowiednie dla Twojej witryny.
Od interakcji do kolejnego wyrenderowania (INP)
Najważniejsze informacje, które należy zarejestrować w polu INP, to:
- Z jakim elementem podjęto interakcję
- Dlaczego rodzaj interakcji
- kiedy miała miejsce interakcja;
Główną przyczyną powolnych interakcji jest zablokowany wątek główny, który może prowadzić być powszechne podczas wczytywania JavaScriptu. Sprawdzanie, czy większość spowolnionych interakcji występujące podczas wczytywania strony, pomaga określić, co trzeba zrobić i rozpoznają problem.
Wskaźnik INP uwzględnia pełne opóźnienie interakcji, w tym czas potrzebny na uruchomienie zarejestrowanych detektorów zdarzeń jako oraz czas potrzebny na wyrenderowanie następnej klatki po wszystkich detektorach zdarzeń już biegły. Oznacza to, że w przypadku INP bardzo przydatna jest informacja o tym, który cel które skutkują powolnym interakcją, a także czyli właśnie tak.
Ten kod rejestruje element docelowy i czas wpisu INP.
function logINPDebugInfo(inpEntry) {
console.log('INP target element:', inpEntry.target);
console.log('INP interaction type:', inpEntry.name);
console.log('INP time:', inpEntry.startTime);
}
Uwaga: ten kod nie pokazuje, jak określić, który wpis event jest INP.
z uwzględnieniem tej logiki. Jednak w następnej sekcji wyjaśniamy,
jak zdobyć te informacje przy pomocy
web- Vitals w języku JavaScript.
Użycie z biblioteką JavaScript Web Vitals
W poprzednich sekcjach znajdziesz ogólne sugestie i przykłady kodu, dane debugowania, aby uwzględnić je w danych wysyłanych do narzędzia analitycznego.
Od wersji 3 web Vitals Biblioteka JavaScript obejmuje atrybucję tworzyć, wszystkie te informacje oraz kilka dodatkowych informacji, .
Poniższy przykładowy kod pokazuje, jak ustawić dodatkowe zdarzenie (lub niestandardowy) ) zawierający wymiar ciąg debugowania pomaga w znalezieniu głównej przyczyny wydajności problemów.
import {onCLS, onINP, onLCP} from 'web-vitals/attribution';
function sendToGoogleAnalytics({name, value, id, attribution}) {
const eventParams = {
metric_value: value,
metric_id: id,
}
switch (name) {
case 'CLS':
eventParams.debug_target = attribution.largestShiftTarget;
break;
case 'LCP':
eventParams.debug_target = attribution.element;
break;
case 'INP':
eventParams.debug_target = attribution.interactionTarget;
break;
}
// Assumes the global `gtag()` function exists, see:
// https://developers.google.com/analytics/devguides/collection/ga4
gtag('event', name, eventParams);
}
onCLS(sendToGoogleAnalytics);
onLCP(sendToGoogleAnalytics);
onFID(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);
Kod ten jest charakterystyczny dla Google Analytics, ale ogólna zasada powinna przekładać się a także inne narzędzia analityczne.
Ten kod pokazuje też, jak utworzyć raport na podstawie pojedynczego sygnału debugowania, ale przydatna, ponieważ pozwala na zbieranie i raportowanie wielu różnych sygnałów danych.
Na przykład do debugowania wartości INP warto zbierać dane o elemencie interakcja z, typ interakcji, czas, parametr loadState, interakcja fazy i inne (np. dane długiej klatki animacji).
Funkcja web-vitals zawiera dodatkowe informacje o atrybucji,
jak w tym przykładzie dla INP:
import {onCLS, onINP, onLCP} from 'web-vitals/attribution';
function sendToGoogleAnalytics({name, value, id, attribution}) {
const eventParams = {
metric_value: value,
metric_id: id,
}
switch (name) {
case 'INP':
eventParams.debug_target = attribution.interactionTarget;
eventParams.debug_type = attribution.interactionType;
eventParams.debug_time = attribution.interactionTime;
eventParams.debug_load_state = attribution.loadState;
eventParams.debug_interaction_delay = Math.round(attribution.inputDelay);
eventParams.debug_processing_duration = Math.round(attribution.processingDuration);
eventParams.debug_presentation_delay = Math.round(attribution.presentationDelay);
break;
// Additional metric logic...
}
// Assumes the global `gtag()` function exists, see:
// https://developers.google.com/analytics/devguides/collection/ga4
gtag('event', name, eventParams);
}
onCLS(sendToGoogleAnalytics);
onLCP(sendToGoogleAnalytics);
onFID(sendToGoogleAnalytics);
onINP(sendToGoogleAnalytics);
Zapoznaj się z atrybucją Web Vitals dokumentacji pełna lista ujawnionych sygnałów debugowania.
Raportowanie i wizualizacja danych
Gdy zaczniesz zbierać informacje o debugowaniu wraz z wartościami danych, Następnym krokiem jest zebranie danych od wszystkich użytkowników, by rozpocząć wyszukiwanie wzorów i trendów.
Jak już wspomnieliśmy, nie musisz rozwiązywać wszystkich problemów. napotykanych przez użytkowników, warto rozwiązać – zwłaszcza na początku – problemy, które dotyczą największej liczby użytkowników, co również powinny być które mają największy negatywny wpływ na wyniki w Podstawowych wskaźnikach internetowych.
W przypadku GA4 zapoznaj się z artykułem o tworzeniu zapytań i wizualizowaniu danych za pomocą BigQuery.
Podsumowanie
Mamy nadzieję, że w tym poście omówiliśmy konkretne sposoby korzystania
istniejących interfejsów API wydajności oraz biblioteki web-vitals, aby pobierać dane debugowania
aby pomóc w diagnozowaniu skuteczności na podstawie wizyt rzeczywistych użytkowników w terenie. Choć w tym roku
dotyczy także podstawowych wskaźników internetowych, pojęcia te mają też zastosowanie do debugowania.
dowolne dane o skuteczności, które można zmierzyć w JavaScripcie.
Jeśli dopiero zaczynasz mierzyć skuteczność i masz już Użytkownik Google Analytics może zacząć od narzędzia do raportowania wskaźników internetowych ponieważ obsługuje już raportowanie danych debugowania dla Core Web Wskaźniki życiowe.
Jeśli jesteś dostawcą usług analitycznych i chcesz ulepszać swoje produkty udostępnić użytkownikom więcej informacji na temat debugowania, rozważ opisanych tu technik, ale nie ograniczaj się do tylko przedstawionych pomysłów tutaj. Ten post dotyczy wszystkich narzędzi analitycznych. jednak poszczególne narzędzia analityczne mogą (i powinny) przechwytywać i raportować jeszcze więcej danych na potrzeby debugowania.
Jeśli uważasz, że w możliwości debugowania tych danych występują luki w danych brakujące funkcje lub informacje w interfejsach API wysyłają opinię do web-vitals-feedback@googlegroups.com.