Información sobre los motivos por los que las herramientas que supervisan las Métricas web esenciales pueden generar informes con números distintos y cómo interpretar esas diferencias
Google proporciona varias herramientas para ayudar a los propietarios de sitios a supervisar sus puntuaciones de Métricas web esenciales. Estas herramientas se dividen en dos categorías principales:
- Herramientas que informan datos de lab: datos recopilados en un entorno controlado con parámetros de configuración de red y dispositivo predefinidos
- Herramientas que informan datos de campo: datos recopilados de los usuarios reales que visitan tu sitio
El problema es que, a veces, los datos que registran las herramientas de laboratorio pueden ser bastante diferentes de los que registran las herramientas de campo. Es posible que tus datos de lab indiquen que tu sitio tiene un excelente rendimiento, pero tus datos de campo sugieren que necesita mejoras. Como alternativa, es posible que tus datos de campo indiquen que todas tus páginas son buenas, pero que los datos de lab muestren una puntuación muy baja.
En el siguiente ejemplo real de un informe de PageSpeed Insights de web.dev, se muestra que, en algunos casos, los datos de campo y de laboratorio pueden ser diferentes en todas las métricas de las Métricas web esenciales:
Las diferencias entre las herramientas son una fuente de confusión comprensible para los desarrolladores. En esta publicación, se explican los principales motivos por los que podrían existir estas diferencias, con ejemplos específicos que abarcan cada una de las métricas de las Métricas web esenciales, y qué hacer cuando encuentres diferencias en tus páginas.
Datos de laboratorio en comparación con datos de campo
Para comprender por qué las herramientas de lab y de campo pueden informar valores diferentes, incluso para la misma página web, debes comprender la diferencia entre los datos de lab y de campo.
Datos del lab
Para determinar los datos de lab, se carga una página web en un entorno controlado con un conjunto predefinido de condiciones de red y dispositivo. Estas condiciones se conocen como entorno de lab, que a veces también se denomina entorno sintético.
Por lo general, las herramientas de Chrome que informan datos de laboratorio ejecutan Lighthouse.
El propósito de una prueba de laboratorio es controlar tantos factores como sea posible, de modo que los resultados sean (en la medida de lo posible) coherentes y reproducibles de una ejecución a otra.
Datos de campo
Para determinar los datos de campo, se supervisan todos los usuarios que visitan una página y se mide un conjunto determinado de métricas de rendimiento para cada una de las experiencias individuales de esos usuarios. Dado que los datos de campo se basan en las visitas de usuarios reales, reflejan los dispositivos, las condiciones de la red y las ubicaciones geográficas reales de tus usuarios.
Los datos de campo también se conocen como datos de supervisión de usuarios reales (RUM); los dos términos son intercambiables.
Por lo general, las herramientas de Chrome que informan datos de campo obtienen esos datos del Informe sobre la experiencia del usuario en Chrome (CrUX). También es común (y recomendable) que los propietarios de sitios recopilen los datos de campo por su cuenta, ya que pueden proporcionar estadísticas más prácticas que solo usar CrUX.
Lo más importante que debes comprender sobre los datos de campo es que no es solo un número, es una distribución de números. Es decir, para algunas personas que visitan tu sitio, es posible que se cargue muy rápido, mientras que para otras, puede tardar mucho en cargarse. Los datos de campo de tu sitio son el conjunto completo de todos los datos de rendimiento recopilados de tus usuarios.
A modo de ejemplo, los informes de CrUX muestran una distribución de las métricas de rendimiento de usuarios reales de Chrome durante un período de 28 días. Si observas casi cualquier informe de CrUX, puedes ver que algunos usuarios que visitan un sitio pueden tener una experiencia muy buena, mientras que otros pueden tener una experiencia muy mala.
Si una herramienta informa un solo número para una métrica determinada, por lo general, representará un punto específico en la distribución. Las herramientas que informan las puntuaciones de campo de las Métricas web esenciales lo hacen con el percentil 75.
Si observas el LCP de los datos de campo en la captura de pantalla anterior, puedes ver una distribución en la que se cumplen las siguientes condiciones:
- El 88% de las visitas tuvo un LCP de 2.5 segundos o menos (bueno).
- El 8% de las visitas tuvo un LCP entre 2.5 y 4 segundos (debe mejorarse).
- El 4% de las visitas tuvo un LCP superior a 4 segundos (deficiente).
En el percentil 75, el LCP fue de 1.8 segundos:
Los datos de lab de la misma página muestran un valor de LCP de 3.0 segundos. Si bien este valor es mayor que los 1.8 segundos que se muestran en los datos de campo, sigue siendo un valor de LCP válido para esta página; es uno de los muchos valores que conforman la distribución completa de las experiencias de carga.
Por qué los datos de laboratorio y de campo son diferentes
Como se explica en la sección anterior, los datos de laboratorio y los de campo miden cosas muy diferentes.
Los datos de campo incluyen una amplia variedad de condiciones de red y dispositivo, así como una gran cantidad de tipos de comportamiento de los usuarios. También incluye cualquier otro factor que afecte la experiencia del usuario, como las optimizaciones del navegador, como la caché de atrás/adelante (bfcache), o las optimizaciones de la plataforma, como la caché de AMP.
Por el contrario, los datos de laboratorio limitan intencionalmente la cantidad de variables involucradas. Una prueba de laboratorio consta de lo siguiente:
- Un solo dispositivo…
- conectado a una sola red…
- se ejecuten desde una sola ubicación geográfica.
Los detalles de cualquier prueba de laboratorio pueden representar con exactitud o no el percentil 75 de los datos de campo de una página o un sitio determinado.
El entorno controlado del lab es útil cuando se depuran problemas o se prueban funciones antes de implementarlas en producción, pero cuando controlas estos factores, no representas de forma explícita la variación que ves en el mundo real en todos los tipos de redes, capacidades de dispositivos o ubicaciones geográficas. Por lo general, tampoco capturas el impacto en el rendimiento del comportamiento de los usuarios reales, como el desplazamiento, la selección de texto o el toque de elementos en la página.
Además de la posible desconexión entre las condiciones de laboratorio y las de la mayoría de los usuarios reales, también hay una serie de diferencias más sutiles que es importante comprender para sacar el máximo provecho de tus datos de laboratorio y de campo, así como de las diferencias que puedas encontrar.
En las siguientes secciones, se detallan los motivos más comunes por los que podría haber diferencias entre los datos de laboratorio y los de campo para cada una de las métricas de las Métricas web esenciales:
- Procesamiento de imagen con contenido más grande (LCP)
- Interaction to Next Paint (INP)
- Cambio de diseño acumulado (CLS)
LCP
Diferentes elementos de LCP
Es posible que el elemento LCP identificado en una prueba de lab no sea el mismo que los usuarios ven cuando visitan tu página.
Si ejecutas un informe de Lighthouse para una página determinada, se mostrará el mismo elemento de LCP cada vez. Sin embargo, si observas los datos de campo de la misma página, por lo general, encontrarás una variedad de elementos de LCP diferentes, que dependen de una serie de circunstancias específicas de cada visita a la página.
Por ejemplo, los siguientes factores podrían contribuir a que se determine un elemento LCP diferente para la misma página:
- Los diferentes tamaños de pantalla de los dispositivos hacen que se vean diferentes elementos dentro de la vista del viewport.
- Si el usuario accedió o si se muestra contenido personalizado de alguna manera, el elemento LCP podría ser muy diferente de un usuario a otro.
- Al igual que en el punto anterior, si se ejecuta una prueba A/B en la página, es posible que se muestren elementos muy diferentes.
- El conjunto de fuentes instaladas en el sistema del usuario puede afectar el tamaño del texto en la página (y, por lo tanto, qué elemento es el elemento LCP).
- Por lo general, las pruebas de lab se ejecutan en la URL "base" de una página, sin agregar ningún parámetro de consulta ni fragmento de hash. Sin embargo, en el mundo real, los usuarios suelen compartir URLs que contienen un identificador de fragmento o un fragmento de texto, por lo que el elemento LCP puede estar en la mitad o en la parte inferior de la página (en lugar de "sobre la mitad superior").
Dado que el LCP en el campo se calcula como el percentil 75 de todas las visitas de los usuarios a una página, si un gran porcentaje de esos usuarios tuvo un elemento de LCP que se cargó muy rápido (por ejemplo, un párrafo de texto renderizado con una fuente del sistema), incluso si algunos de esos usuarios tenían una imagen grande y de carga lenta como su elemento de LCP, es posible que no afecte la puntuación de esa página si eso ocurre en menos del 25% de los visitantes.
Como alternativa, podría ser lo opuesto. Una prueba de lab podría identificar un bloque de texto como el elemento de LCP porque emula un teléfono Moto G4 que tiene un viewport relativamente pequeño y la imagen hero de tu página se renderiza inicialmente fuera de la pantalla. Sin embargo, es posible que tus datos de campo incluyan principalmente usuarios de Pixel XL con pantallas más grandes, por lo que, para ellos, la imagen hero de carga lenta es su elemento de LCP.
Efectos del estado de la caché en la LCP
Por lo general, las pruebas de lab cargan una página con una caché fría, pero cuando los usuarios reales visitan esa página, es posible que ya tengan algunos de sus recursos almacenados en caché.
La primera vez que un usuario carga una página, es posible que se cargue lentamente, pero si la página tiene configurado el almacenamiento en caché adecuado, la próxima vez que el usuario vuelva a la página, es posible que se cargue de inmediato.
Si bien algunas herramientas de lab admiten varias ejecuciones de la misma página (para simular la experiencia de los visitantes recurrentes), no es posible que una herramienta de lab sepa qué porcentaje de visitas reales se produce de usuarios nuevos en comparación con los recurrentes.
Es posible que los sitios con parámetros de configuración de caché bien optimizados y muchos visitantes recurrentes descubran que su LCP en el mundo real es mucho más rápida de lo que indican sus datos de lab.
Optimizaciones de AMP o intercambios firmados
Los agregadores de contenido, como la Búsqueda de Google, pueden precargar los sitios compilados con AMP o que usan intercambios firmados (SXG). Esto puede generar un rendimiento de carga significativamente mejor para los usuarios que visitan tus páginas desde esas plataformas.
Además de la carga previa entre orígenes, los sitios también pueden precargar contenido para las páginas posteriores de su sitio, lo que también podría mejorar el LCP de esas páginas.
Las herramientas de Lab no simulan las ganancias que se obtienen con estas optimizaciones y, incluso si lo hicieran, no podrían saber qué porcentaje de tu tráfico proviene de plataformas como la Búsqueda de Google en comparación con otras fuentes.
Efectos de bfcache en la LCP
Cuando las páginas se restablecen desde la bfcache, la experiencia de carga es casi instantánea y estas experiencias se incluyen en tus datos de campo.
Las pruebas de lab no tienen en cuenta la bfcache, por lo que, si tus páginas son compatibles con bfcache, es probable que se informen puntuaciones de LCP más rápidas en el campo.
Efectos de la interacción del usuario en el LCP
El LCP identifica el tiempo de renderización de la imagen o el bloque de texto más grande en el viewport, pero ese elemento más grande puede cambiar a medida que se carga la página o si se agrega contenido nuevo de forma dinámica al viewport.
En el lab, el navegador esperará hasta que la página se cargue por completo antes de determinar cuál fue el elemento de LCP. Sin embargo, en el campo, el navegador dejará de supervisar los elementos más grandes después de que el usuario se desplace o interactúe con la página.
Esto tiene sentido (y es necesario) porque, por lo general, los usuarios esperan para interactuar con una página hasta que "aparece" cargada, que es exactamente lo que la métrica LCP pretende detectar. Tampoco tendría sentido considerar los elementos agregados al viewport después de que un usuario interactúa, ya que es posible que esos elementos solo se hayan cargado debido a algo que hizo el usuario.
Sin embargo, esto implica que los datos de campo de una página pueden informar tiempos de LCP más rápidos, según el comportamiento de los usuarios en esa página.
INP
La INP requiere interacción con usuarios reales.
La métrica INP mide qué tan responsiva es una página a las interacciones del usuario, en el momento en que los usuarios eligen interactuar con ella.
La segunda parte de esa oración es fundamental porque las pruebas de lab, incluso aquellas que admiten el comportamiento de los usuarios de secuencias de comandos, no pueden predecir con precisión cuándo los usuarios elegirán interactuar con una página y, por lo tanto, no pueden medir con precisión el FID.
La TBT no considera el comportamiento del usuario.
El objetivo de la métrica de lab Total Blocking Time (TBT) es ayudar a diagnosticar problemas con la INP, ya que cuantifica cuánto se bloquea el subproceso principal durante la carga de la página.
La idea es que las páginas con mucho código JavaScript síncrono o con otras tareas de renderización intensivas tienen más probabilidades de tener un subproceso principal bloqueado cuando el usuario interactúa por primera vez. Sin embargo, si los usuarios esperan para interactuar con la página hasta que se termina de ejecutar JavaScript, el INP puede ser muy bajo.
El momento en que los usuarios elijan interactuar con una página depende en gran medida de si se ve interactiva o no, y esto no se puede medir con la TBT.
El TBT no considera la demora en el toque.
Si un sitio no está optimizado para la visualización en dispositivos móviles, los navegadores agregarán un retraso de 300 ms después de cada toque antes de ejecutar los controladores de eventos. Esto se debe a que deben determinar si el usuario intenta presionar dos veces para acercar la imagen antes de poder activar los eventos del mouse o del clic.
Esta demora se considera en la INP de una página porque contribuye a la latencia de entrada real que experimentan los usuarios. Sin embargo, como esta demora no es técnicamente una tarea prolongada, no afecta el TBT de una página. Esto significa que una página puede tener una INP baja a pesar de tener puntuaciones de TBT muy buenas.
Efectos del estado de la caché y de bfcache en INP
De la misma manera que el almacenamiento en caché adecuado puede mejorar el LCP en el campo, también puede mejorar el INP.
En el mundo real, es posible que un usuario ya tenga el código JavaScript de un sitio en su caché, por lo que procesarlo podría tomar menos tiempo y generar retrasos menores.
Lo mismo sucede con las páginas que se restablecen desde bfcache. En esos casos, el JavaScript se restablece desde la memoria, por lo que podría haber poco o ningún tiempo de procesamiento.
CLS
Efectos de la interacción del usuario en el CLS
El CLS medido en el laboratorio solo considera los cambios de diseño que ocurren por encima de la mitad inferior de la página y durante la carga, pero esto es solo un subconjunto de lo que mide el CLS.
En el campo, CLS considera todos los cambios de diseño inesperados que ocurren durante la vida útil de la página, incluido el contenido que cambia a medida que el usuario se desplaza o en respuesta a solicitudes de red lentas después de la interacción del usuario.
Por ejemplo, es bastante común que las páginas carguen imágenes o iframes de forma diferida sin dimensiones, lo que puede provocar cambios de diseño cuando un usuario se desplaza hasta esas secciones de la página. Sin embargo, esos cambios solo pueden ocurrir si el usuario se desplaza hacia abajo, lo que a menudo no se detecta en una prueba de lab.
Contenido personalizado
El contenido personalizado, incluidos los anuncios segmentados y las pruebas A/B, afecta los elementos que se cargan en una página. También afecta la forma en que se cargan, ya que el contenido personalizado a menudo se carga más tarde y se inserta en el contenido principal de una página, lo que provoca cambios de diseño.
En el lab, por lo general, se carga una página sin contenido personalizado o con contenido para un "usuario de prueba" genérico, que puede activar o no los cambios que ven los usuarios reales.
Dado que los datos de campo incluyen las experiencias de todos los usuarios, la cantidad (y el grado) de cambios de diseño que se experimentan en una página determinada depende en gran medida del contenido que se carga.
Efectos del estado de la caché y de bfcache en la CLS
Dos de las causas más comunes de los cambios de diseño durante la carga son las imágenes y los iframes sin dimensiones (como se mencionó anteriormente) y las fuentes web de carga lenta. Es más probable que ambos problemas afecten la experiencia la primera vez que un usuario visita un sitio, cuando su caché está vacía.
Si los recursos de una página se almacenan en caché o si la página se restablece desde la caché de bf, el navegador suele renderizar las imágenes y las fuentes de inmediato, sin esperar a que se descarguen. Esto puede generar valores de CLS más bajos en el campo que los que puede informar una herramienta de lab.
Qué hacer cuando los resultados son diferentes
Como regla general, si tienes datos de campo y de lab para una página determinada, debes usar los datos de campo para priorizar tus esfuerzos. Dado que los datos de campo representan lo que experimentan los usuarios reales, es la forma más precisa de comprender realmente con qué problemas se enfrentan tus usuarios y qué se debe mejorar.
Por otro lado, si tus datos de campo muestran buenas puntuaciones en todos los aspectos, pero los datos de lab sugieren que aún hay margen para la mejora, vale la pena comprender qué optimizaciones adicionales se pueden realizar.
Además, si bien los datos de campo capturan las experiencias de los usuarios reales, solo lo hacen para los usuarios que pueden cargar tu sitio correctamente. En ocasiones, los datos de lab pueden ayudar a identificar oportunidades para expandir el alcance de tu sitio y hacerlo más accesible para los usuarios con redes más lentas o dispositivos de gama baja.
En general, tanto los datos de laboratorio como los de campo son partes importantes de una medición de rendimiento eficaz. Ambas tienen sus fortalezas y limitaciones, y si solo usas una, es posible que te estés perdiendo la oportunidad de mejorar la experiencia de tus usuarios.