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 ofrece 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 dispositivo y red
- Herramientas que informan datos de campo (datos recopilados de usuarios reales que visitan tu sitio)
El problema es que, a veces, los datos que informan las herramientas del lab pueden ser bastante diferentes de los que informan las herramientas de campo. Es posible que los datos de tu lab indiquen que tu sitio tiene un buen rendimiento, pero los datos de tus campos sugieren que debe mejorarse. Como alternativa, es posible que los datos de campo indiquen que todas tus páginas son buenas, pero que los datos de tu lab informen 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 de las Métricas web esenciales:
Las diferencias entre las herramientas son una fuente comprensible de confusión para los desarrolladores. En esta publicación, se explican los principales motivos por los que podrían existir esas diferencias, con ejemplos específicos que abarcan cada una de las métricas 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 conoce como entorno sintético.
Por lo general, las herramientas de Chrome que informan datos de labs ejecutan Lighthouse.
El propósito de las pruebas de lab es controlar tantos factores como sea posible, de modo que los resultados sean (en la medida de lo posible) coherentes y se puedan reproducir 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 esos usuarios. Como 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 los usuarios.
Los datos de campo también se conocen como datos de supervisión de usuario real (RUM). Los dos términos son intercambiables.
Por lo general, las herramientas de Chrome que informan datos de campo los obtienen 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 sí mismos porque puede proporcionar más estadísticas prácticas que solo usar CrUX.
Lo más importante que hay que 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. Los datos del campo de tu sitio son 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 observas casi cualquier informe de CrUX, puedes ver que algunos usuarios que visitan un sitio pueden tener una muy buena experiencia, mientras que otros pueden tener una mala experiencia.
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 Métricas web esenciales lo hacen usando el percentil 75.
Si observas LCP desde 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 tuvo un LCP de entre 2.5 y 4 segundos (se necesita mejorar).
- 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 del campo, sigue siendo un valor de LCP válido para esta página, ya que es uno de los tantos valores que conforman 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 aspectos muy diferentes.
Los datos de campo incluyen una amplia variedad de condiciones de red y dispositivos, así como una gran cantidad de tipos diferentes de comportamientos de los usuarios. También incluye cualquier otro factor que afecte la experiencia del usuario, como las optimizaciones del navegador, como la memoria caché atrás/adelante (bfcache), o las optimizaciones de la plataforma, como la caché de AMP.
Por el contrario, los datos de lab limitan intencionalmente la cantidad de variables involucradas. Las pruebas de lab tienen las siguientes características:
- Un solo dispositivo...
- te conectaste a una sola red...
- se ejecutan desde una ubicación geográfica única.
Los detalles de un examen de laboratorio pueden o no representar con exactitud el percentil 75 de datos de campo de una página o sitio determinados.
El entorno controlado del lab es útil cuando se depuran problemas o se prueban funciones antes de implementar en producción. Sin embargo, cuando controlas estos factores, no representas explícitamente 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 hay una serie de diferencias más sutiles que es importante comprender para aprovechar al máximo los datos de tu lab y de campo, así como cualquier diferencia que encuentres.
En las siguientes secciones, se detallan en detalle los motivos más comunes por los que podrían haber diferencias entre los datos de laboratorio y de campo para cada una 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 laboratorio no sea el mismo que ven los usuarios cuando visitan tu página.
Si ejecutas un informe de Lighthouse para una página determinada, se mostrará siempre el mismo elemento LCP. 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 hacen que los elementos sean visibles dentro del viewport.
- Si el usuario ya 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 una prueba A/B se ejecuta en la página, podría generar 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 LCP).
- Las pruebas de lab suelen ejecutarse 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 un fragmento de texto, por lo que el elemento LCP puede estar en el medio o la parte inferior de la página (en lugar de estar "en 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 ellos tenía un elemento LCP que se carga 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 los visitantes de esa página si es inferior al 25%.
De manera alternativa, podría suceder lo contrario. Una prueba de lab podría identificar un bloque de texto como el elemento LCP porque está emulando un teléfono Moto G4 con un viewport relativamente pequeño, y la imagen hero de la página se renderiza en un principio fuera de la pantalla. Sin embargo, los datos de campo pueden incluir la mayoría de los usuarios de Pixel XL con pantallas más grandes, por lo que la imagen hero de carga lenta es su elemento LCP.
Efectos del estado de la caché en el LCP
Las pruebas de lab suelen cargar una página con una caché inactiva, pero, cuando 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 tiene un almacenamiento en caché adecuado configurado, es posible que, la próxima vez que el usuario vuelva, 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), una herramienta de lab no puede saber 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 podrían descubrir que su LCP real es mucho más rápido de lo que indican los datos de lab.
Optimizaciones de AMP o intercambio firmado
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 mucho mejor para los usuarios que visitan tus páginas desde esas plataformas.
Además de la precarga en orígenes cruzados, los sitios pueden precargar contenido para páginas subsiguientes del sitio, lo que también podría mejorar el LCP de esas páginas.
Las herramientas del lab no simulan las ganancias obtenidas a partir de estas optimizaciones y, si lo hicieron, 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 la bfcache en LCP
Cuando se restablecen las 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 compatibles con bfcache, es probable que generen 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 grandes 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á a que la página se cargue por completo para determinar cuál era el elemento LCP. Sin embargo, en el campo, el navegador dejará de supervisar 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 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ú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 generar tiempos de LCP más rápidos, según cómo se comportan los usuarios en esa página.
INP
INP requiere interacción del usuario real
La métrica de INP mide qué tan responsiva es una página a las interacciones del usuario, en el momento en que los usuarios deciden interactuar con ella.
La segunda parte de esa oración es fundamental porque las pruebas de lab, incluso aquellas que admiten el comportamiento del usuario de la secuencia 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 el FID con exactitud.
La TBT no tiene en cuenta el comportamiento del usuario
La métrica del lab Tiempo de bloqueo total (TBT) está diseñada para ayudar a diagnosticar problemas con el INP porque 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 procesamiento intensivo 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 JavaScript termine de ejecutarse, es posible que el INP sea muy bajo.
El momento en el 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 cualquier presión antes de ejecutar controladores de eventos. Lo hacen porque necesita determinar si el usuario intenta presionar dos veces para acercar antes de activar eventos del mouse o de clic.
Esta demora se considera en el INP 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 INP deficiente a pesar de tener muy buenas puntuaciones de TBT.
Efectos del estado de la caché y la 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 tenga el código JavaScript de un sitio ya en su caché, por lo que su procesamiento podría tardar menos tiempo y reducir los retrasos.
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 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 realicen cargas diferidas de imágenes o iframes sin dimensiones, y eso puede provocar cambios en el 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 la página, lo que provoca cambios en el 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, el navegador, por lo general, 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, son 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 buenas, pero los datos de tu lab sugieren que aún hay margen para mejorar, vale la pena comprender qué optimizaciones adicionales se pueden hacer.
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 ventajas y limitaciones, y, si solo usas uno, es posible que te pierdas la oportunidad de mejorar la experiencia de tus usuarios.