Más información para atribuir tus datos de rendimiento con información de depuración para identificar y solucionar problemas de usuarios reales con Analytics
Google ofrece dos categorías de herramientas para medir y depurar el rendimiento:
- Herramientas del lab: Herramientas como Lighthouse, en la que tu página se carga en una que puede imitar diversas condiciones (por ejemplo, una falla y un dispositivo móvil de baja gama).
- Herramientas de campo: Herramientas como la Experiencia del usuario en Chrome Informe (CrUX), que se basa en datos agregados de usuarios reales de Chrome. (Ten en cuenta que el datos de campo informados por herramientas, como PageSpeed, Estadísticas y Búsqueda La consola se obtiene de datos de CrUX).
Si bien las herramientas de campo ofrecen datos más precisos, es decir, los datos experiencia real de los usuarios. Las herramientas de lab suelen ser mejores para ayudarte a identificar y corregir problemas.
Los datos de CrUX son más representativos del rendimiento real de tu página, pero saber es poco probable que tus puntuaciones de CrUX te ayuden a descubrir cómo mejorar tu rendimiento.
Por otro lado, Lighthouse identificará los problemas y hará cambios sugerencias para mejorar. Sin embargo, Lighthouse solo hará sugerencias por problemas de rendimiento que detecta en el momento de carga de la página. No detecta problemas que solo se manifiestan como resultado de la interacción del usuario, por ejemplo, desplazarse o hacer clic botones de la página.
Esto genera una pregunta importante: ¿cómo se puede capturar información de depuración para ¿Métricas web esenciales o cualquier otra métrica de rendimiento de usuarios reales en el campo?
En esta publicación, se explicará en detalle qué APIs puedes usar para recopilar datos información de depuración para cada una de las métricas actuales de Core Web Vitals ideas para capturar estos datos en tu herramienta de análisis existente.
APIs para atribución y depuración
Cumulative Layout Shift (CLS)
De todas las métricas de las Métricas web esenciales, CLS es quizás la que recopilar información de depuración en el campo es lo más importante. La métrica CLS se mide a lo largo de la vida útil de la página, por lo que la forma en que un usuario interactúa con el de página (hasta dónde se desplazan, en qué hacen clic, etc.) puede tener un impacto significativo en cuanto a si hay cambios de diseño y qué elementos lo hacen.
Considera el siguiente informe de PageSpeed Insights:
El valor informado para CLS en el lab (Lighthouse) en comparación con CLS del (datos de CrUX) son bastante diferentes, lo que tiene sentido si consideras que la página puede tener mucho contenido interactivo que cuando se prueba en Lighthouse.
Pero incluso si entiendes que la interacción del usuario afecta los datos del campo, aún sepa qué elementos de la página están cambiando para dar como resultado una puntuación de 0.28 en el percentil 75. La clase LayoutShiftAttribution interfaz de usuario lo hace posible.
Cómo obtener la atribución de cambio de diseño
La clase LayoutShiftAttribution
en cada entrada de layout-shift que inestabilidad de diseño
que emite la API.
Para obtener una explicación detallada de estas dos interfaces, consulta Diseño de depuración. Cambios. Para los fines de en esta publicación, lo más importante que debes saber es que, como desarrollador, puedes para observar cada cambio de diseño que ocurre en la página, así como los elementos están cambiando.
Este es un código de ejemplo que registra cada cambio de diseño, así como los elementos que cambió:
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});
Probablemente no sea práctico medir y enviar datos a tu herramienta de análisis para cada cambio de diseño que ocurra; Sin embargo, al supervisar todos los turnos, hacer un seguimiento de los peores cambios y solo informar información sobre ellos.
El objetivo no es identificar y corregir cada cambio de diseño que ocurra todos los usuarios; su objetivo es identificar los cambios que afectan a la mayor cantidad de y así contribuirá más al CLS de su página en el percentil 75.
Además, no es necesario que calcules el elemento de origen más grande cada vez que haya un solo debes hacerlo cuando tengas todo listo para enviar el valor CLS a de análisis de datos en Google Cloud.
El siguiente código toma una lista de layout-shift entradas que contribuyeron
a CLS y muestra el elemento de origen más grande del cambio más grande:
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;
}
}
}
Una vez que hayas identificado el elemento más grande que contribuye al cambio más grande puedes informarlo a tu herramienta de estadísticas.
Es probable que el elemento que más contribuye a CLS para una página determinada varíe de usuario a usuario, pero si agregas esos elementos a todos los usuarios, estarás capaz de generar una lista de elementos cambiantes que afectan a la mayor cantidad de usuarios.
Una vez que hayas identificado y corregido la causa raíz de los cambios de esas tu código de Analytics comenzará a registrar cambios más pequeños cambios en tus páginas. Con el tiempo, todos los cambios informados serán lo suficientemente pequeños como para sus páginas estén dentro de las buenas" umbral de 0.1
Otros metadatos que pueden ser útiles de capturar junto con el cambio más grande elemento fuente es:
- La hora del cambio más grande
- La ruta de URL en el momento del cambio más grande (para sitios que actualizar la URL, como las aplicaciones de una sola página).
Largest Contentful Paint (LCP)
Para depurar el LCP en el campo, la información principal que necesitas es qué era el elemento más grande (el elemento candidato de LCP) para el carga de página.
Ten en cuenta que es completamente posible (de hecho, es bastante común que el LCP) candidato será diferente de un usuario a otro, incluso para la misma .
Esto puede suceder por varios motivos:
- Los dispositivos de los usuarios tienen diferentes resoluciones de pantalla, lo que da como resultado diferentes diseños de página y, por lo tanto, diferentes elementos visibles en el viewport.
- Los usuarios no siempre cargan páginas desplazadas hasta la parte superior. A menudo, los vínculos contener identificadores de fragmentos o incluso fragmentos de texto, lo que significa que es posible para que tus páginas se carguen y se muestren en cualquier posición de desplazamiento.
- Es posible que el contenido se personalice para el usuario actual, por lo que el elemento candidato del LCP podría variar mucho de un usuario a otro.
Esto significa que no puedes hacer suposiciones sobre qué elemento o conjunto de elementos será el elemento candidato de LCP más común de una página en particular. Debes y puedes medirlos según el comportamiento del usuario real.
Identifica el elemento candidato de LCP
Para determinar el elemento candidato de LCP en JavaScript, puedes usar el campo Mayor la API de Contentful Paint misma API que usas para determinar el valor de tiempo de LCP.
Cuando observas entradas de largest-contentful-paint, puedes determinar la
el elemento candidato de LCP actual observando la propiedad element de la última entrada:
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});
Una vez que conozcas el elemento candidato de LCP, puedes enviarlo a tu herramienta de estadísticas. junto con el valor de la métrica. Al igual que con CLS, esto te ayudará a identificar es más importante optimizar primero.
Además del elemento candidato de LCP, también puede ser útil medir el valor Horas de las subpartes LCP, que pueden ser útiles para determinar qué pasos específicos de optimización son relevantes para su sitio.
Interacción con el siguiente procesamiento de imagen (INP)
Los fragmentos más importantes de información que se deben capturar en el campo para el INP son los siguientes:
- Con qué elemento se interactuó
- ¿Por qué fue el tipo de interacción?
- Cuándo ocurrió esa interacción
Una de las principales causas de las interacciones lentas es el subproceso principal común mientras se carga JavaScript. Saber si la mayoría de las interacciones lentas que ocurren durante la carga de la página es útil para determinar qué hay que hacer para corregir el problema.
La métrica INP considera la latencia completa de un interactiva, incluido el tiempo que lleva ejecutar cualquier objeto de escucha de eventos registrado como así como el tiempo que lleva pintar el siguiente fotograma después de todos los objetos de escucha de eventos que se hayan ejecutado. Esto significa que para INP es muy útil saber qué objetivo de los elementos de la nube tienden a dar lugar a interacciones lentas, y qué tipos de interacciones esos son.
El siguiente código registra el elemento objetivo y la hora de la entrada de INP.
function logINPDebugInfo(inpEntry) {
console.log('INP target element:', inpEntry.target);
console.log('INP interaction type:', inpEntry.name);
console.log('INP time:', inpEntry.startTime);
}
Ten en cuenta que en este código no se muestra cómo determinar qué entrada de event es el INP.
ya que esa lógica es más compleja. Sin embargo, en la siguiente sección, se explica
cómo obtener esta información usando la
web-vitals.
Uso con la biblioteca de JavaScript web-vitals
En las secciones anteriores, se ofrecen algunas sugerencias generales y ejemplos de código para capturar información de depuración para incluirla en los datos que envíes a tu herramienta de estadísticas.
A partir de la versión 3, el directorio web-vitals La biblioteca JavaScript incluye una atribución compilación que muestra toda esta información y algunas de seguridad.
El siguiente ejemplo de código muestra cómo podrías configurar un evento adicional parámetro (o configuración dimensión) que contenga un cadena de depuración útil para ayudar a identificar la causa raíz del rendimiento problemas.
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);
Este código es específico de Google Analytics, pero la idea general debería traducirse a otras herramientas de análisis también.
Este código también muestra cómo informar en un solo indicador de depuración, útiles para recopilar e informar sobre varios indicadores diferentes por métrica
Por ejemplo, para depurar INP, es posible que quieras recopilar el elemento interactuaste, el tipo de interacción, la hora, el loadState, la interacción fases y más (como los datos de Marco de animación largo).
La compilación de atribución web-vitals expone información de atribución adicional.
como se muestra en el siguiente ejemplo para 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);
Consulta la atribución web-vitals. documentación de la una lista completa de los indicadores de depuración expuestos.
Informar y visualizar los datos
Una vez que comiences a recopilar información de depuración junto con los valores de las métricas, haz lo siguiente: El siguiente paso es agregar los datos de todos los usuarios para comenzar a buscar los patrones y las tendencias.
Como se mencionó anteriormente, no es necesario que abordes todos los problemas. que encuentran los usuarios, debes abordar, especialmente al principio, los problemas que afectan a la mayor cantidad de usuarios, y que también deberían ser los problemas que tienen el mayor impacto negativo en las puntuaciones de Métricas web esenciales.
Para GA4, consulta el artículo específico sobre cómo consultar y visualizar los datos usando BigQuery
Resumen
Esperamos que esta publicación haya ayudado a esbozar las formas específicas en que puedes usar la
APIs de rendimiento existentes y la biblioteca web-vitals para obtener información de depuración
para ayudar a diagnosticar el rendimiento en función de las visitas de usuarios reales en el campo. Mientras que esta
se centra en las Métricas web esenciales, los conceptos también se aplican a la depuración
en cualquier métrica de rendimiento que se pueda medir en JavaScript.
Si recién comienzas a medir el rendimiento y ya tienes Usuario de Google Analytics, la herramienta del Informe de métricas web puede ser un buen punto de partida porque ya admite la generación de informes de información de depuración para la versión web Métricas de Android vitals.
Si eres proveedor de analítica y quieres mejorar tus productos más información de depuración a tus usuarios, considera algunas de las las técnicas descritas aquí, pero no te limites solo a las ideas que se presentan aquí. El objetivo de esta publicación es que se pueda aplicar de manera general a todas las herramientas de estadísticas. Sin embargo, es probable que las herramientas de estadísticas individuales puedan (y deben) capturar e informar más información de depuración.
Por último, si sientes que hay brechas en tu capacidad para depurar estas métricas debido a funciones o información faltantes en las propias APIs. Envía tus comentarios a web-vitals-feedback@googlegroups.com.