Obtén 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 los datos de lab: datos recopilados en un entorno controlado con una configuración predefinida de dispositivos y redes.
- Herramientas que informan los datos de campo (datos recopilados de usuarios reales que visitan tu sitio)
El problema es que, a veces, los datos que informan las herramientas de lab pueden ser bastante diferentes de los que informan las herramientas de campo. Los datos de tu lab pueden indicar que tu sitio tiene un excelente rendimiento, pero los datos de tu campo sugieren que debe mejorarse. De manera alternativa, los datos de tu campo pueden indicar que todas tus páginas son buenas, pero los datos de tu lab pueden informar una puntuación muy baja.
El siguiente ejemplo real de un informe de PageSpeed Insights de web.dev muestra que, en algunos casos, los datos de lab y de campo pueden ser diferentes en todas 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 web esenciales, y qué hacer cuando encuentras diferencias en tus páginas.
Datos de lab frente a datos de campo
Para comprender por qué las herramientas de lab y 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 de laboratorio
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 un entorno de lab, que a veces también se denomina entorno sintético.
Por lo general, las herramientas de Chrome que informan datos de labs ejecutan Lighthouse.
El propósito de las pruebas de laboratorio es controlar tantos factores como puedas para 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 supervisa a 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 cada uno. Debido a que los datos de campo se basan en 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 comúnmente 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 se recomienda) que los propietarios de sitios recolecten datos de campo por su cuenta, ya que puede proporcionar más estadísticas prácticas que solo usar CrUX.
Lo más importante que debes comprender sobre los datos de campo es que no son solo un número, sino 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 hacerlo con mucha lentitud. El campo de datos de tu sitio es el conjunto completo de todos los datos de rendimiento recopilados de tus usuarios.
Por 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 consultas casi cualquier informe de CrUX, notarás que algunos usuarios que visitan un sitio podrían tener una experiencia muy buena, mientras que otros podrían 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 del campo de Core Web vitals lo hacen usando 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 sucede lo siguiente:
- El 88% de las visitas tuvo un LCP de 2.5 segundos o menos (bueno).
- El 8% de las visitas experimentaron un LCP de entre 2.5 y 4 segundos (necesita mejorar).
- El 4% de las visitas tuvo un LCP superior a 4 segundos (malo).
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 del campo, sigue siendo un valor LCP válido para esta página, ya que es uno de los tantos que componen la distribución completa de las experiencias de carga.
Por qué los datos de lab y de campo son diferentes
Como se explica en la sección anterior, los datos de lab y de campo en realidad miden elementos muy diferentes.
Los datos de campo incluyen una amplia variedad de condiciones de red y dispositivo, así como una gran cantidad de diferentes 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é atrás/adelante (bfcache), o las optimizaciones de plataforma, como la caché de AMP.
Por el contrario, los datos de lab limitan intencionalmente la cantidad de variables involucradas. Estas pruebas consisten en lo siguiente:
- Un solo dispositivo...
- conectado a una sola red...
- se ejecutan desde una sola ubicación geográfica.
Los detalles de una prueba de laboratorio determinada pueden o no representar con exactitud el percentil 75 de datos de campo para una página o sitio determinados.
El entorno controlado del lab es útil cuando depuras problemas o pruebas funciones antes de implementarlas en producción. Sin embargo, 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 captas el impacto en el rendimiento del comportamiento de usuarios reales, como desplazarse, seleccionar texto o presionar elementos en la página.
Además de la posible desconexión entre las condiciones del lab y las condiciones de la mayoría de los usuarios reales, también es importante comprender una serie de diferencias más sutiles que es importante comprender para aprovechar al máximo los datos del lab y del campo, así como las diferencias que encuentres.
En las siguientes secciones, se explican en detalle los motivos más comunes por los que podrían haber diferencias entre los datos de laboratorio y los de campo para cada una de las métricas de métricas web esenciales:
LCP
Diferentes elementos de LCP
Es posible que el elemento de LCP identificado en un examen de laboratorio 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 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 generan distintos elementos visibles dentro 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, podrían mostrarse elementos muy diferentes.
- El conjunto de fuentes instaladas en el sistema del usuario puede afectar el tamaño del texto de la página (y, por lo tanto, qué elemento es el de LCP).
- Por lo general, las pruebas de lab se ejecutan en la URL "base" de una página, sin parámetros de consulta ni fragmentos de hash agregados. Sin embargo, en el mundo real, los usuarios suelen compartir URLs que contienen un identificador de fragmento o fragmento de texto, por lo que el elemento LCP puede ser en realidad del centro o la parte inferior de la página (en lugar de "la mitad superior de la página").
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 ellos tuvo un elemento LCP que se cargó muy rápido (por ejemplo, un párrafo de texto procesado con una fuente del sistema), incluso si algunos de esos usuarios tenían una imagen grande y de carga lenta como elemento de LCP, es posible que no afecte la puntuación de esa página si eso sucede a menos del 25% de los visitantes.
De manera alternativa, podría suceder lo contrario. Una prueba de laboratorio podría identificar un bloque de texto como el elemento LCP porque está emulando un teléfono Moto G4 que tiene un viewport relativamente pequeño, y la imagen principal de tu página se renderiza inicialmente fuera de la pantalla. Sin embargo, tus datos de campo pueden incluir la mayoría de los usuarios de Pixel XL con pantallas más grandes, por lo que, para ellos, la hero image de carga lenta es su elemento LCP.
Efectos del estado de la caché en LCP
Las pruebas de lab suelen cargar una página con una caché fría, pero cuando usuarios reales la visitan, 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 el almacenamiento en caché configurado correctamente, es posible que, la próxima vez que el usuario regrese, la página 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 ocurren de usuarios nuevos en comparación con usuarios recurrentes.
Los sitios con configuraciones de caché bien optimizadas y muchos visitantes recurrentes pueden descubrir que su LCP real es mucho más rápido de lo que indican los datos de sus labs.
Optimizaciones de AMP o intercambio firmado
Los sitios compilados con AMP o que usan intercambios firmados (SXG) pueden cargarse previamente con agregadores de contenido como la Búsqueda de Google. Esto puede mejorar considerablemente el rendimiento de carga de los usuarios que visitan tus páginas desde esas plataformas.
Además de la precarga de origen cruzado, los sitios pueden precargar contenido para 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 obtenidas a partir de estas optimizaciones y, si lo hicieran, no podrían saber qué porcentaje del tráfico proviene de plataformas como la Búsqueda de Google en comparación con otras fuentes.
Efectos de bfcache en LCP
Cuando se restablecen páginas desde la bfcache, la experiencia de carga es casi instantánea y estas experiencias se incluyen en los datos de campo.
Las pruebas de lab no consideran la bfcache, por lo que, si tus páginas son aptas para la bfcache, es probable que se generen puntuaciones de LCP más rápidas en el campo.
Efectos de la interacción del usuario en el LCP
LCP identifica el tiempo de renderización del bloque de texto o la imagen 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 al viewport de forma dinámica.
En el lab, el navegador esperará hasta que la página se cargue por completo para determinar cuál era el elemento LCP. Sin embargo, en el campo, el navegador detenerá la supervisión de elementos más grandes después de que el usuario se desplace en la página o interactúe con ella.
Esto tiene sentido (y es necesario), ya que los usuarios suelen esperar para interactuar con una página hasta que "parezca" cargada, que es exactamente lo que la métrica de LCP busca detectar. Tampoco tendría sentido considerar los elementos agregados al viewport después de que un usuario interactúe, ya que es posible que 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.
FID
FID requiere interacción de usuarios reales
La métrica FID mide qué tan responsiva es una página a las interacciones del usuario en el momento en que los usuarios realmente decidieron interactuar con ella.
La segunda parte de esa oración es crítica porque las pruebas de laboratorio, incluso aquellas que admiten el comportamiento del usuario de secuencias de comandos, no pueden predecir con exactitud 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 tiene en cuenta el comportamiento de los usuarios
La métrica del lab Tiempo de bloqueo total (TBT) tiene como objetivo ayudar a diagnosticar problemas con el FID, 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 alguna otra tarea de renderización intensiva tengan más probabilidades de tener un subproceso principal bloqueado cuando el usuario interactúe por primera vez. Sin embargo, si los usuarios esperan para interactuar con la página hasta que el código JavaScript termine de ejecutarse, es posible que el FID sea muy bajo.
El momento en que los usuarios deciden interactuar con una página depende en gran medida de si parece interactiva o no, y esto no se puede medir con TBT.
La TBT no tiene en cuenta la demora al presionar
Si un sitio no está optimizado para la visualización en dispositivos móviles, los navegadores agregarán una demora de 300 ms después de presionar antes de ejecutar los controladores de eventos. Lo hacen porque necesitan determinar si el usuario intenta presionar dos veces para hacer zoom antes de activar eventos del mouse o de hacer clic.
Esta demora se tiene en cuenta para el FID de una página porque contribuye a la latencia de entrada real que experimentan los usuarios. Sin embargo, dado que, técnicamente, esta demora no es una tarea larga, no afecta la TBT de una página. Esto significa que una página puede tener un FID deficiente a pesar de tener muy buenas puntuaciones de TBT.
Efectos del estado de la caché y la bfcache en FID
De la misma manera que el almacenamiento en caché adecuado puede mejorar el LCP en el campo, también puede mejorar el FID.
En el mundo real, es posible que un usuario ya tenga el JavaScript de un sitio en su caché, por lo que su procesamiento podría tardar menos tiempo y generar retrasos más pequeños.
Lo mismo sucede con las páginas restablecidas desde la bfcache. En esos casos, el código JavaScript se restablece desde la memoria, por lo que puede haber poco o ningún tiempo de procesamiento.
CLS
Efectos de la interacción del usuario en CLS
El CLS que se mide en el lab solo considera los cambios de diseño que ocurren en la mitad superior de la página y durante la carga, pero esto es solo un subconjunto de lo que CLS mide en realidad.
En el campo, CLS considera todos los cambios de diseño inesperados que se producen a lo largo de 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 realicen cargas diferidas de imágenes o iframes sin dimensiones, y eso puede provocar cambios de diseño cuando un usuario se desplaza a esas secciones de la página. Sin embargo, esos cambios solo pueden ocurrir si el usuario se desplaza hacia abajo, lo que no suele verse en una prueba de laboratorio.
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, una página suele cargarse sin contenido personalizado o con contenido para un “usuario de prueba” genérico, lo 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 los cambios de diseño experimentados en una página determinada depende en gran medida del contenido que se carga.
Efectos del estado de la caché y la bfcache en 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, y 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 en sí se restablece desde la bfcache, por lo general, el navegador puede renderizar imágenes y 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 de 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é tienen dificultades y qué se debe mejorar.
Por otro lado, si los datos de tu campo muestran puntuaciones positivas en general, pero los datos de tu lab sugieren que todavía hay margen para mejorar, vale la pena comprender qué otras optimizaciones se pueden realizar.
Además, si bien los datos de campo capturan experiencias de usuarios reales, solo lo hacen para los usuarios que pueden cargar tu sitio correctamente. A veces, 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 lab como los datos de campo son partes importantes de una medición eficaz del rendimiento. Ambos tienen sus fortalezas y limitaciones, y, si solo usas uno, es posible que te estés perdiendo la oportunidad de mejorar la experiencia de los usuarios.