Dowiedz się, jak przypisywać dane o wydajności do informacji debugowania, aby łatwiej identyfikować i rozwiązywać problemy z użytkownikami rzeczywistymi za pomocą funkcji analitycznych
Google udostępnia 2 kategorie narzędzi do pomiaru i debugowania skuteczności:
- Narzędzia laboratoryjne: narzędzia takie jak Lighthouse, w których przypadku strona jest wczytywana w symulowanym środowisku, które może symulować różne warunki (np. wolną sieć i niedrogowe urządzenie mobilne).
- Narzędzia dotyczące danych z pól: narzędzia takie jak raport na temat użytkowania Chrome (CrUX), który jest oparty na zbiorczych danych o użytkownikach Chrome. Pamiętaj, że dane pól raportowane przez narzędzia takie jak PageSpeed Insights i Search Console pochodzą z danych CrUX.
Narzędzia terenowe zapewniają dokładniejsze dane, które odzwierciedlają rzeczywiste wrażenia użytkowników, ale narzędzia laboratoryjne często lepiej pomagają w identyfikowaniu i rozwiązywaniu problemów.
Dane CrUX lepiej odzwierciedlają rzeczywistą skuteczność strony, ale znajomość wyników CrUX nie pomoże Ci zwiększyć jej skuteczności.
Z drugiej strony Lighthouse wskazuje problemy i podaje konkretne sugestie dotyczące ich rozwiązania. Lighthouse będzie jednak podawać sugestie tylko w przypadku problemów z wydajnością, które wykryje w momencie wczytywania strony. Nie wykrywa problemów, które występują tylko w wyniku interakcji użytkownika, takich jak przewijanie lub klikanie przycisków na stronie.
W związku z tym pojawia się ważne pytanie: jak możesz rejestrować informacje debugowania dotyczące podstawowych wskaźników internetowych lub innych danych o wydajności, które pochodzą od rzeczywistych użytkowników?
W tym artykule szczegółowo opisujemy, których interfejsów API możesz używać do zbierania dodatkowych informacji debugujących dla każdego z obecnych podstawowych wskaźników internetowych. Podpowiadamy też, jak rejestrować te dane w dotychczasowym 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 prawdopodobnie tym, dla którego zbieranie informacji debugujących w polu jest najważniejsze. Wartość CLS jest mierzona przez cały okres istnienia strony, więc sposób, w jaki użytkownik z niej korzysta (jak daleko przewija stronę, co klika itp.) może mieć znaczący wpływ na to, czy występują przesunięcia układu i które elementy się przesuwają.
Zastanów się nad tym raportem z PageSpeed Insights:
Wartość CLS z testów laboratoryjnych (Lighthouse) w porównaniu z wartością CLS z testów w warunkach rzeczywistych (dane z raportu CrUX) jest dość różna, co ma sens, jeśli weźmiemy pod uwagę, że strona może zawierać dużo interaktywnych treści, których nie używa się podczas testów w Lighthouse.
Nawet jeśli wiesz, że interakcja użytkownika wpływa na dane w polu, musisz wiedzieć, które elementy na stronie się zmieniają, aby uzyskać wynik 0,28 w 75.percentylu. Umożliwia to interfejs LayoutShiftAttribution.
Uzyskiwanie atrybucji przesunięcia układu
Interfejs LayoutShiftAttribution jest dostępny w przypadku każdego wpisu layout-shift, który generuje interfejs API niestabilności układu.
Szczegółowe omówienie obu tych interfejsów znajdziesz w artykule Zmiana układu na potrzeby debugowania. W tym artykule najważniejsze jest to, że jako deweloper możesz obserwować każdą zmianę układu na stronie, a także które elementy się zmieniają.
Oto przykładowy kod, który rejestruje każde przesunięcie układu oraz elementy, które się przesunęły:
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});
Prawdopodobnie nie jest praktyczne mierzenie i przesyłanie danych do narzędzia analitycznego w przypadku każdego wystąpienia zmiany układu. Jednak dzięki monitorowaniu wszystkich zmian możesz śledzić najgorsze zmiany i wysyłać tylko informacje o nich.
Celem nie jest identyfikowanie i naprawianie każdego przesunięcia układu, które występuje u każdego użytkownika, lecz identyfikowanie przesunięć, które wpływają na największą liczbę użytkowników i tym samym w największym stopniu wpływają na CLS strony w 75. percentylu.
Nie musisz też obliczać największego elementu źródłowego za każdym razem, gdy nastąpi zmiana. Wystarczy, że zrobisz to, gdy będziesz gotowy wysłać wartość CLS do narzędzia analitycznego.
Poniższy kod pobiera listę wpisów layout-shift, które przyczyniły się do CLS, i zwraca największy element źródłowy z największym przesunięciem:
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, który przyczynił się do największej zmiany, możesz przekazać tę informację w narzędziu analitycznym.
Element, który najbardziej wpływa na CLS na danej stronie, prawdopodobnie będzie się różnić w zależności od użytkownika, ale jeśli zgrupujesz te elementy dla wszystkich użytkowników, będziesz mieć możliwość wygenerowania listy elementów, które wpływają na największą liczbę użytkowników.
Gdy znajdziesz i usuniesz główną przyczynę zmian tych elementów, kod Analytics zacznie raportować mniejsze zmiany jako „największe” zmiany na stronach. Ostatecznie wszystkie zgłoszone przesunięcia będą na tyle małe, że Twoje strony będą się mieścić w dopuszczalnym progu 0,1.
Inne metadane, które warto rejestrować wraz z elementem źródła o największej zmianie:
- Czas największej zmiany
- Ścieżka URL w momencie największej zmiany (w przypadku witryn, które dynamicznie aktualizują adres URL, np. aplikacji typu Single Page Application).
Największe wyrenderowanie treści (LCP)
Aby debugować LCP w polu, musisz znać element, który był największym elementem (elementem kandydującym do LCP) podczas wczytywania danej strony.
Pamiętaj, że element kandydujący do LCP może być inny dla każdego użytkownika, nawet na tej samej stronie.
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 w konsekwencji różne elementy widoczne w widocznym obszarze.
- Użytkownicy nie zawsze wczytują strony przewinięte do samego końca. Linki często zawierają identyfikatory fragmentów lub nawet fragmenty tekstu, co oznacza, że strony mogą być wczytywane i wyświetlane w dowolnym miejscu na stronie.
- Treści mogą być spersonalizowane dla danego użytkownika, więc element kandydujący do LCP może się znacznie różnić w zależności od użytkownika.
Oznacza to, że nie możesz zakładać, który element lub zestaw elementów będzie najczęściej występującym elementem kandydującym do LCP na danej stronie. Musisz je mierzyć na podstawie zachowań rzeczywistych użytkowników.
.Określanie elementu kandydującego do LCP
Aby określić element kandydujący do LCP w JavaScript, możesz użyć interfejsu Largest Contentful Paint API, czyli tego samego interfejsu API, którego używasz do określenia wartości czasu LCP.
Obserwując wpisy largest-contentful-paint, możesz określić aktualny element kandydujący do LCP, sprawdzając 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ż poznasz element kandydujący do LCP, możesz go wysłać do narzędzia analitycznego wraz z wartością danych. Podobnie jak w przypadku CLS, pomoże Ci to określić, które elementy należy najpierw zoptymalizować.
Oprócz elementu kandydującego LCP może być też przydatne mierzenie czasów poszczególnych części LCP, co może pomóc w określaniu, które konkretne kroki optymalizacji są odpowiednie dla Twojej witryny.
Interakcja do kolejnego wyrenderowania (INP)
Najważniejsze informacje, które należy podać w polu w przypadku INP:
- Element, z którym nastąpiła interakcja
- Typ interakcji
- Kiedy doszło do interakcji
Główną przyczyną powolnego działania interakcji jest zablokowany wątek główny, co może być częstym zjawiskiem podczas wczytywania kodu JavaScript. Wiedza o tym, czy większość wolnych interakcji występuje podczas wczytywania strony, pomaga określić, co należy zrobić, aby rozwiązać problem.
Dane INP uwzględniają pełny czas oczekiwania na interakcję, w tym czas potrzebny na wykonanie wszystkich zarejestrowanych odbiorników zdarzeń, a także czas potrzebny na wyrenderowanie następnego obrazu po wykonaniu wszystkich odbiorników zdarzeń. Oznacza to, że w przypadku INP przydatne jest poznanie, które elementy docelowe powodują zwykle spowolnienie interakcji i jakie są to rodzaje interakcji.
Poniższy 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);
}
Pamiętaj, że ten kod nie pokazuje, jak określić, które pole event jest polem INP, ponieważ ta logika jest bardziej skomplikowana. W następującej sekcji wyjaśniono, jak uzyskać te informacje za pomocą biblioteki JavaScript web-vitals.
Używanie z biblioteką JavaScript web-vitals
W poprzednich sekcjach znajdziesz ogólne wskazówki i przykłady kodu, które pomogą Ci rejestrować informacje debugowania, aby uwzględniać je w danych przesyłanych do narzędzia analitycznego.
Od wersji 3 biblioteka JavaScript web-vitals zawiera ustawienie atrybucji, które udostępnia wszystkie te informacje, a także kilka dodatkowych sygnałów.
Poniższy przykład kodu pokazuje, jak ustawić dodatkowy parametry wydarzenia (lub wymiar niestandardowy), który zawiera ciąg debugowania przydatny do identyfikowania pierwotnych przyczyn problemów ze skutecznością.
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);
onINP(sendToGoogleAnalytics);
Ten kod jest przeznaczony do Google Analytics, ale ogólna idea powinna się sprawdzić również w przypadku innych narzędzi analitycznych.
Ten kod pokazuje też, jak tworzyć raporty na podstawie jednego sygnału debugowania, ale przydatne jest zbieranie i raportowanie wielu różnych sygnałów na podstawie jednej metryki.
Na przykład, aby debugować INP, możesz zbierać informacje o elemencie, z którym następuje interakcja, typ interakcji, czas, stan ładowania, fazy interakcji i inne (np. dane o długim klatce animacji).
W przypadku wersji atrybucji web-vitals są widoczne dodatkowe informacje atrybucji, jak w tym przykładzie w przypadku 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);
onINP(sendToGoogleAnalytics);
Pełną listę dostępnych sygnałów debugowania znajdziesz w dokumentacji przypisania danych wskaźników internetowych.
Raportowanie i wizualizacja danych
Po rozpoczęciu zbierania informacji debugowania wraz z wartościami danych następnym krokiem jest zgrupowanie danych dotyczących wszystkich użytkowników, aby można było zacząć szukać wzorców i trendów.
Jak już wspomnieliśmy, nie musisz rozwiązywać wszystkich problemów, z którymi spotykają się użytkownicy. Zwróć uwagę przede wszystkim na problemy, które dotyczą największej liczby użytkowników, ponieważ to one mają największy negatywny wpływ na wyniki metryk Core Web Vitals.
W przypadku GA4 zapoznaj się z artykułem poświęconym wykonywaniu zapytań i wizualizacji danych za pomocą BigQuery.
Podsumowanie
Mamy nadzieję, że ten artykuł pomógł Ci poznać sposoby korzystania z dotychczasowych interfejsów API dotyczących wydajności i biblioteki web-vitals, aby uzyskiwać informacje debugowania, które ułatwiają diagnozowanie wydajności na podstawie wizyt rzeczywistych użytkowników. Ten przewodnik skupia się na podstawowych wskaźnikach internetowych, ale omawiane w nim zagadnienia mają też zastosowanie do debugowania wszelkich danych dotyczących wydajności, które można mierzyć w JavaScript.
Jeśli dopiero zaczynasz mierzyć skuteczność i korzystasz już z Google Analytics, dobrym punktem wyjścia może być narzędzie Raport podstawowych wskaźników internetowych, które obsługuje już raportowanie informacji debugowania dotyczących podstawowych wskaźników internetowych.
Jeśli jesteś dostawcą usług analitycznych i chcesz ulepszać swoje produkty oraz udostępniać użytkownikom więcej informacji do debugowania, rozważ zastosowanie opisanych tutaj technik, ale nie ograniczaj się tylko do przedstawionych tu pomysłów. Ten post ma zastosowanie do wszystkich narzędzi analitycznych, ale poszczególne narzędzia analityczne mogą (i powinny) rejestrować i przekazywać jeszcze więcej informacji debugujących.
Jeśli uważasz, że nie możesz debugować tych danych z powodu braku funkcji lub informacji w samych interfejsach API, prześlij opinię na adres web-vitals-feedback@googlegroups.com.