Supervisión de usuarios reales: comprender la velocidad de los sitios web tanto en condiciones reales como en laboratorio

Usuarios reales y pruebas de laboratorio

Supervisión de usuarios reales (RUM) registra cómo funciona un sitio web en visitas reales. Una visita desde un smartphone antiguo a través de una red móvil puede diferir considerablemente de una visita desde un ordenador de sobremesa con una conexión rápida. Las páginas visitadas y las interacciones también se tienen en cuenta en el análisis.

A Prueba de laboratorio Por el contrario, analiza una llamada definida en condiciones controladas. Para cada análisis se pueden especificar el tipo de dispositivo, las condiciones de red y el procedimiento de prueba. Esto facilita volver a reproducir una anomalía y comprobar posibles cambios en condiciones comparables.

Ambos puntos de vista responden a preguntas diferentes: los datos de campo pueden mostrar que las páginas de productos en dispositivos móviles suelen cargarse lentamente. Sin embargo, no demuestran si, por ejemplo, la imagen del producto, la ruta de renderizado o una respuesta lenta del documento son las causas de ello. Para identificar la causa, se necesitan diagnósticos adicionales e hipótesis verificables.

PageSpeed Insights combina ambas perspectivas: compara los datos de campo disponibles, procedentes del Informe sobre la experiencia del usuario de Chrome, con los diagnósticos de laboratorio basados en Lighthouse. No es necesario que los resultados coincidan, ya que las visitas reales abarcan condiciones y flujos de uso diferentes, mientras que el laboratorio analiza un caso de prueba concreto.

Por lo tanto, el RUM no sustituye al laboratorio. Por el contrario, una sola prueba de laboratorio no puede mostrar con qué frecuencia se produce un problema entre los visitantes reales. Además, antes de una publicación o en el caso de una página web con escaso tráfico, es posible que no se disponga de datos de campo suficientes; sin visitas reales, no se generan en absoluto valores de medición propios del RUM.

Así se obtienen los valores de medición de RUM

Para realizar un análisis propio se necesitan tres elementos: un sistema de registro en el navegador, un receptor de los valores transmitidos y un proceso de evaluación. En primer lugar, debes determinar qué páginas y qué grupos de visitantes deseas analizar, así como cómo se protegerán los datos. Solo a partir de valores individuales agrupados de forma adecuada se puede sentar una base para la toma de decisiones.

Los navegadores ofrecen diversas interfaces de rendimiento para ello. Tiempo de navegación describe los momentos relacionados con la navegación hasta el documento, como la respuesta a la solicitud del documento. Resource Timing proporciona información sobre el tiempo de cada uno de los recursos cargados, como imágenes o scripts. De este modo, se pueden delimitar con mayor precisión las distintas fases de un proceso de carga.

A PerformanceObserver supervisa las entradas de rendimiento optimizadas tan pronto como estén disponibles. Para los Core Web Vitals, la biblioteca puede web-vitals se encargan del cálculo y la notificación. Las entradas y los indicadores disponibles dependen, entre otras cosas, del navegador; por lo tanto, un script de medición no registra automáticamente todas las visitas en su totalidad.

No todos los valores se generan directamente al cargar la página. Para el INP, por ejemplo, debe producirse una interacción adecuada: quien solo lee una página y luego la abandona, es posible que no aporte ningún valor. Por lo tanto, la ausencia de un valor medido no significa que sea cero ni que sea indicio de una respuesta rápida.

Un servicio RUM puede ofrecer funciones de recopilación, recepción y análisis en un único paquete. Si se trata de un desarrollo propio, además tendrás que organizar el funcionamiento, el almacenamiento y el control de calidad. Esto incluye también gestionar correctamente los mensajes repetidos a lo largo del ciclo de vida de la página, en lugar de contabilizar cada mensaje sin comprobarlo como una visita independiente.

Cómo interpretar correctamente los Core Web Vitals

El Core Web Vitals describen tres aspectos distintos de la experiencia del usuario. El Largest Contentful Paint (LCP) mide cuándo se hace visible el elemento de contenido relevante de mayor tamaño. En la página de un producto, por ejemplo, puede tratarse de una imagen grande del producto: si aparece tarde, es posible que la página parezca que aún no se ha cargado por completo, a pesar de que la navegación ya sea visible.

El indicador «Interaction to Next Paint» (INP) mide el retraso entre una interacción y la siguiente actualización visible. Si un filtro de productos tarda en reaccionar de forma perceptible tras un clic, el INP puede señalar este problema. Por su parte, el Cumulative Layout Shift (CLS) describe los desplazamientos inesperados del contenido visible, como cuando un elemento que aparece posteriormente desplaza un botón.

Para la evaluación en PageSpeed Insights, se considera «bueno» un LCP de hasta 2,5 segundos inclusive, un INP de hasta 200 milisegundos inclusive y un CLS de hasta 0,1 inclusive. El CLS es un valor sin unidades. Estos umbrales se aplican a cada indicador concreto y no deben confundirse con la duración de una sola visita a la página.

Un factor decisivo para la evaluación de campo es el percentil 75 (p. 75): Al menos alrededor del 75 % de las experiencias tenidas en cuenta no superan el valor correspondiente. Sin embargo, una buena media por sí sola puede ocultar el hecho de que una parte considerable de las visitas es lenta. Analiza por separado los dispositivos móviles y los ordenadores de sobremesa, para que las diferencias entre los distintos grupos de dispositivos sigan siendo visibles.

El «Time to First Byte» (TTFB) complementa estos indicadores a la hora de detectar una respuesta lenta de un documento. Sin embargo, este valor no se refiere únicamente al tiempo de procesamiento del servidor: también influyen la red y otros puntos intermedios hasta que llega el primer byte de respuesta. El «Navigation Timing» y, en su caso, los datos de «Server Timing» facilitados ayudan a analizar con mayor precisión las etapas implicadas.

CrUX, su propio RUM y laboratorio

Para empezar, no es necesario que utilices tu propio sistema de medición desde el principio. PageSpeed Insights combina datos de campo procedentes del Informe sobre la experiencia de usuario de Chrome (CrUX) con un diagnóstico de laboratorio de Lighthouse. Ambas perspectivas responden a preguntas diferentes: una describe las experiencias registradas, mientras que la otra analiza una página en condiciones controladas.

Los datos de campo de CrUX en PageSpeed Insights describen un periodo retrospectivo de 28 días. Si los datos de una URL concreta no son suficientes, el informe puede mostrar, en su lugar, datos del origen. Estos incluyen el origen del sitio web correspondiente y no deben equipararse exactamente a la experiencia en la página introducida. Por lo tanto, presta atención al nivel que el informe muestra realmente.

CrUX solo tiene en cuenta a los usuarios de Chrome que cumplen los requisitos correspondientes; no incluye otros navegadores ni a los usuarios que no cumplen dichos requisitos. En una página web pequeña o que no sea pública, es posible que falten datos de CrUX. No obstante, un sistema de recopilación propio, adecuado desde el punto de vista jurídico y técnico, puede proporcionar información útil en esos casos, aunque su valor estadístico seguirá siendo limitado si el número de visitas es reducido.

La monitorización sintética repite pruebas predefinidas, incluso cuando no hay nadie visitando la página web en ese momento. Es adecuada para observar un proceso de forma periódica en condiciones similares. Para saber si los usuarios tienen la misma experiencia con otros dispositivos o redes, es necesario realizar una medición sobre el terreno; un único proceso sintético no sustituye a esta perspectiva.

Por lo tanto, a la hora de elegir, lo que cuenta es la pregunta que quieras responder: un informe público está disponible rápidamente, mientras que un sistema propio permite un registro más específico. Un servicio puede aliviar la carga de trabajo operativo, mientras que los ensayos de laboratorio y sintéticos permiten realizar análisis controlados. Sin embargo, incluso un servicio requiere una selección consciente de los datos y los grupos de análisis.

Preparar adecuadamente la medición propia

En primer lugar, define una pregunta concreta, por ejemplo, si las páginas de productos para móviles suelen presentar un LCP elevado con más frecuencia que otros tipos de páginas. A continuación, determina qué páginas y categorías de dispositivos quieres diferenciar, qué métricas son necesarias para ello y durante cuánto tiempo deseas recopilar datos. Solo después de eso debes decidir qué script de medición utilizar, a quién se enviarán los datos y cómo se evaluarán.

Como primer paso técnico, puedes utilizar la biblioteca web-vitals Integrarlo localmente en un proyecto de navegador y ver el resultado en las herramientas de desarrollo. El código JavaScript siguiente utiliza la versión 6.2.3 del paquete publicado. Se da por supuesto que esta versión está instalada en el proyecto y que la compilación procesa las importaciones de módulos. El ejemplo no envía datos a ningún servidor ni activa ninguna medición independiente de la navegación suave.

import {onCLS, onINP, onLCP} from 'web-vitals';

onCLS(console.log);
onINP(console.log);
onLCP(console.log);

La salida de la consola es una forma de comprobar la integración, no una indicación de la velocidad de tus visitantes. Abre la página del proyecto e interactúa, por ejemplo, con un filtro. Un valor INP requiere una interacción adecuada y no tiene por qué aparecer de inmediato; sin la interacción adecuada, puede que ni siquiera aparezca. La compatibilidad del navegador y el ciclo de vida de la página también influyen en el resultado.

Planifica, para un análisis posterior, el Ciclo de vida de la página Nota: Las notificaciones pueden producirse varias veces, por ejemplo, cuando una página se oculta y luego vuelve a mostrarse. No cuentes estas notificaciones de forma generalizada como visitas independientes. La biblioteca proporciona identificadores de métrica con los que se pueden asignar las notificaciones a la misma métrica.

La recuperación desde la caché «Back/Forward» también requiere un tratamiento específico. Puede generar un nuevo mensaje de métrica, aunque el documento provenga de la caché. Define cómo vas a diferenciar este tipo de recuperaciones de las navegaciones habituales en tu informe y consulta las instrucciones específicas de la biblioteca antes de configurar un registro en entorno productivo.

Analizar los valores medidos por segmentos

Un valor global de la tienda puede ocultar el hecho de que las páginas de productos para móviles son más lentas. Por eso, desglosa los datos de medición, como mínimo, por tipo de página y clase de dispositivo, y analiza cada métrica en un periodo de tiempo concreto. De este modo, por ejemplo, podrás comparar las páginas de productos para móviles con las páginas de categorías para móviles, en lugar de mezclar sin darte cuenta diferentes situaciones de uso.

Para cada segmento, el percentil 75 Es más significativo que una simple media: indica el valor que no supera, como mínimo, el 75 % de las experiencias tenidas en cuenta. Por el contrario, una media baja puede ocultar el hecho de que un grupo relevante tenga que esperar mucho tiempo. Compara el p75 siempre solo para la misma métrica y con la unidad adecuada.

El número de valores válidos forma parte directamente del resultado. Si un segmento consta solo de unas pocas mediciones, los datos individuales pueden influir considerablemente en el percentil; en ese caso, una variación no tiene por qué indicar un problema general. Si es necesario, elige un periodo de tiempo más largo o agrupa páginas temáticamente similares sin perder la comparabilidad.

Un INP ausente no es un INP rápido y no debe incluirse como cero en la distribución. En su lugar, indica por separado el número de valores de INP válidos. Si muchas visitas no proporcionan una interacción adecuada, el análisis del INP solo describe las experiencias de interacción registradas y no todas las visitas a la página de forma automática.

Agrupa adecuadamente los mensajes repetidos en función del ID de métrica, en lugar de tratar cada respuesta como una nueva observación independiente. Documenta, además, cómo se contabilizan las recuperaciones de la caché «back/forward». De este modo, se podrá comprobar qué observaciones están realmente incluidas en el p75 y en el número indicado.

Del problema de campo al diagnóstico

Si los datos de campo indican que las páginas de productos se cargan lentamente en dispositivos móviles, delimita primero el segmento afectado: ¿el LCP deficiente afecta a muchos productos o solo a un tipo de página? Comprueba al mismo tiempo el periodo de tiempo y el número de valores válidos. De este modo, obtendrás un punto de partida para el análisis, pero aún no tendrás pruebas de qué elemento está causando el retraso.

A continuación, introduce en el Prueba de laboratorio Recrea condiciones lo más similares posible, por ejemplo, con una configuración de dispositivo móvil y una velocidad de red limitada. Analiza qué elemento aparece como LCP y cuándo se carga y se muestra. Una imagen grande del producto, una solicitud de imagen tardía o una ruta de renderizado bloqueada son posibles hipótesis que debes comprobar mediante el diagnóstico.

Si hay indicios de que se están enviando imágenes, puedes comprobar el tamaño de los archivos, los formatos y la forma de entrega. Un Red de distribución de contenidos Es una medida posible, pero no garantiza una mejora del LCP. Sin embargo, si la respuesta del documento apunta a un cuello de botella, resulta útil un Prueba de rendimiento de servidores para cargas de trabajo de PHP, analizar la aplicación en condiciones definidas.

En el caso de un filtro de productos con retraso, lo decisivo es la interacción, y no el proceso de carga. Reproduce el clic en el filtro y comprueba qué trabajo se realiza hasta que se produce la actualización visible. En los navegadores que lo admitan, se puede Fotogramas de animación largos Proporcionan indicios sobre las actualizaciones de renderizado prolongadas y los scripts implicados; no explican automáticamente todas las interacciones lentas.

Aplica un cambio específico y, a continuación, vuelve a observar el mismo grupo de páginas en el entorno real. Un mejor resultado de laboratorio solo muestra, en un primer momento, el efecto en las condiciones de prueba seleccionadas. Solo la posterior evaluación en el entorno real podrá revelar si también han cambiado las experiencias registradas de los visitantes reales.

Calidad de los datos y protección de datos en la empresa

Antes de la puesta en marcha, determina qué valores de medición son necesarios para tu problema y quién se encargará de procesarlos. La planificación debe incluir una transmisión segura al destinatario, restricciones de acceso, un plazo de conservación limitado y un procedimiento de supresión. Analiza las cuestiones relativas a la protección de datos y al consentimiento para la implementación concreta, así como la normativa vigente, desde un punto de vista técnico, en lugar de dar por sentada una autorización general.

Con el Minimización de datos Merece la pena prestar atención a los campos de diagnóstico: las URL completas pueden contener información sensible en los parámetros de consulta; los selectores DOM también pueden revelar detalles sobre el contenido de las páginas o las entradas. Si es posible, registra un tipo de página general y unos pocos atributos seleccionados de forma específica. Comprueba también qué datos recopila o almacena adicionalmente un servicio integrado.

Los valores medidos no siempre están disponibles de inmediato. La biblioteca web-vitals puede generar notificaciones varias veces a lo largo del ciclo de vida de la página; por lo tanto, una notificación posterior no debe considerarse automáticamente como una nueva visita independiente. Planifica cómo se procesarán los mensajes relacionados y cómo se gestionarán las recuperaciones desde la caché de «Atrás» y «Adelante».

En el caso de paquetes de diagnóstico pequeños, la transmisión puede realizarse a través de sendBeacon durante el evento visibilitychange ser adecuado. Esto mejora la posibilidad de enviar datos al ocultar una página, pero no garantiza su entrega. Además, el destinatario debe aceptar los datos de forma segura y procesarlos de tal manera que los mensajes repetidos no falseen el análisis sin que se detecte.

Por último, ten en cuenta la Lagunas en el registro: Los scripts bloqueados, la falta de compatibilidad del navegador o las transmisiones perdidas pueden provocar que falten determinadas visitas. Evalúa una tasa de pérdida estimada junto con el tipo de registro. Los datos de medición restantes describen al grupo observado y no tienen por qué representar a todos los visitantes por igual.

Analizar los cambios y elegir el procedimiento

Para realizar una comparación tras una implementación, debes definir previamente qué tipos de páginas, clases de dispositivos y periodos se van a tener en cuenta. Compara, para cada métrica, el percentil 75 y el número de valores válidos antes y después del cambio. Los intervalos de tiempo de duración similar ayudan a contextualizar; sin embargo, esto no garantiza automáticamente que se obtengan muestras suficientemente comparables.

Ten en cuenta que la composición del tráfico puede haber cambiado. Si, tras una implementación, hay más usuarios con conexiones móviles lentas, el valor global puede empeorar, aunque el cambio en sí no sea más lento. El uso estacional u otros cambios simultáneos también dificultan la atribución. Por lo tanto, una correlación temporal es una hipótesis, no un Demostración de la causalidad.

CrUX y el RUM propio no tienen por qué ofrecer los mismos resultados: pueden abarcar diferentes grupos de usuarios, intervalos de tiempo y condiciones de registro. En el caso del CLS, hay que tener en cuenta además que CrUX también tiene en cuenta la contribución de los marcos incrustados a la experiencia de la página principal. Una medición mediante JavaScript en el documento principal no siempre registra estas contribuciones en su totalidad. Por lo tanto, compara primero los fundamentos de la medición antes de considerar una discrepancia como un error.

En el caso de una aplicación de una sola página, debes determinar si quieres analizar la navegación por documentos o los cambios de ruta internos. Para el registro por separado de Navegación suave A partir de la versión 6, Web Vitals admite la opción, siempre que el navegador la admita, reportSoftNavs: true. Debe configurarse en las respectivas funciones de devolución de llamada de métricas. El ejemplo anterior de la consola, sin esta opción, no activa ninguna medición de ruta independiente.

Cuando la captura de navegación suave está activada, los valores de CLS e INP se reinician para la nueva navegación y se analizan por separado; los valores de la navegación anterior se cierran al cambiar de ruta. No debes comparar sin comprobar estos valores, que se delimitan en un intervalo de tiempo diferente, con las mediciones de todo el documento. Sin la compatibilidad adecuada del navegador, esta opción no da lugar a una medición separada de la ruta.

A la hora de elegir un servicio RUM, además de la compatibilidad con los navegadores, comprueba si se pueden analizar los grupos de páginas y las clases de dispositivos que necesitas. Infórmate sobre los métodos de muestreo, el tratamiento de datos, la conservación y las opciones de exportación. Igualmente importante es conocer qué repercusiones puede tener el propio script de medición en la página y si su recopilación de datos puede limitarse a lo estrictamente necesario para tu análisis.