Fecha de publicación: 11 de febrero de 2025
La versión de febrero de 2025 del Informe sobre la experiencia del usuario en Chrome (CrUX) incluye varias métricas nuevas (y modificadas) interesantes:
- Subpartes y tipos de recursos de imagen del procesamiento de imagen con contenido más grande (LCP)
- Detalles del tiempo de ida y vuelta (RTT)
- Eliminación de la dimensión Tipo de conexión real (ECT)
Cada una de ellas proporciona más estadísticas sobre las métricas de rendimiento de los orígenes y las URLs disponibles en CrUX. En esta publicación, explicaremos por qué.
Información de diagnóstico de LCP
Originalmente, presentamos el concepto de subpartes de LCP en Google I/O 2022 como una técnica eficaz para desglosar el tiempo de LCP de las páginas con LCP de imágenes en componentes más pequeños para garantizar que dediques tus esfuerzos a optimizar las causas correctas de un LCP alto.
El análisis de los datos del lab de HTTP Archive en esa charla mostró que el tiempo de descarga de imágenes solía ser la parte más pequeña del tiempo de LCP. Muchas herramientas de lab (incluida Lighthouse de Google) se enfocaban con frecuencia en consejos para optimizar los formatos y el tamaño de las imágenes para reducir los tiempos de descarga y mejorar el rendimiento. Si bien el análisis sigue siendo correcto, mostró que es posible que se haya hecho demasiado énfasis en el consejo y que el problema más grande se produjo en los retrasos antes de que el navegador encontrara la imagen y comenzara a descargarla.
Si bien analizar los datos de laboratorio puede ser útil, la forma en que se usa la Web en la vida real suele diferir, por lo que es fundamental poder ver estas subpartes de los datos de campo. Una publicación publicada el año pasado confirmó que existe un error común sobre cómo optimizar el LCP con datos de campo.
Subpartes de la imagen de LCP
Con esta versión, los propietarios de sitios pueden verificar sus propios sitios en busca de subpartes para la LCP de imágenes, a nivel del origen o de la URL.
Las subpartes solo están disponibles para las imágenes y no incluyen las imágenes del primer fotograma del video (que son un poco más complicadas, ya que no podemos medir el tiempo de descarga completo). Tampoco se incluyen las partes secundarias de texto, ya que son menos útiles y distorsionarían los números de LCP de las imágenes. En el caso de los sitios que se componen principalmente de LCP de texto, las métricas generales de TTFB y FCP son desgloses útiles, aunque ten en cuenta que se aplican a todos los LCP y no son específicos de los LCP de texto. Por último, las subpartes de la imagen solo se recopilan en cargas de página completas, a diferencia de la métrica LCP, que también se recopila en las navegaciones hacia atrás y hacia adelante, y en las páginas renderizadas previamente.
Estos datos se agregaron a la API de CrUX y a la API de CrUX History a partir de febrero de 2025 (nota: no a BigQuery). La API de CrUX History tiene dos semanas de datos en el lanzamiento, y con el tiempo se ampliará hasta el historial completo de 25 semanas. Las APIs ponen los datos a disposición como el percentil 75 de cada subparte expresado en milisegundos.
Por ejemplo, para obtener las subpartes de la imagen de LCP para https://web.dev/ para las vistas de página de PHONE, puedes usar el siguiente comando curl (reemplaza API_KEY por tu propia clave):
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
--header 'Content-Type: application/json' \
--data '{ "formFactor": "PHONE",
"url": "https://web.dev/",
"metrics": [
"largest_contentful_paint_image_time_to_first_byte",
"largest_contentful_paint_image_resource_load_delay",
"largest_contentful_paint_image_resource_load_duration",
"largest_contentful_paint_image_element_render_delay"]}'
Y recibirás algo como lo siguiente:
{
"record": {
"key": {
"formFactor": "PHONE",
"url": "https://web.dev/"
},
"metrics": {
"largest_contentful_paint_image_element_render_delay": {
"percentiles": {
"p75": 2088
}
},
"largest_contentful_paint_image_resource_load_delay": {
"percentiles": {
"p75": 828
}
},
"largest_contentful_paint_image_resource_load_duration": {
"percentiles": {
"p75": 417
}
},
"largest_contentful_paint_image_time_to_first_byte": {
"percentiles": {
"p75": 2385
}
}
},
"collectionPeriod": {
"firstDate": {
"year": 2025,
"month": 1,
"day": 12
},
"lastDate": {
"year": 2025,
"month": 2,
"day": 8
}
}
}
}
Actualizamos la herramienta de visualización de CrUX para incluir estos datos y esperamos que otras herramientas de terceros que usen las APIs de CrUX también expongan estos datos valiosos:
En este ejemplo, podemos ver que, para un sitio de medios popular, la duración de carga de recursos es el componente más pequeño. Las verdaderas oportunidades de mejora para este sitio se encuentran en el TTFB y el retraso en la carga de recursos, con una oportunidad menor en el retraso en la renderización de elementos.
Los valores altos en cada subparte indican diferentes problemas:
- Un tiempo hasta el primer byte (TTFB) alto suele indicar problemas con el servidor, la red o el redireccionamiento, como se explica en Cómo optimizar el TTFB.
- Un alto retraso en la carga de recursos indica que el navegador descubre la imagen de LCP tarde, por ejemplo, una imagen de LCP que inyecta JavaScript del cliente y que tarda un tiempo en ejecutarse.
- Si la duración de carga de recursos es alta, debes reducir el tamaño de descarga de la imagen.
- Un retraso alto en la renderización de elementos se produce cuando la imagen está disponible (quizás a través de un
<link rel=preload>, pero no se usa durante mucho tiempo, a menudo debido a que se requiere JavaScript del cliente para mostrar la imagen.
Esperamos que la disponibilidad de estos datos en CrUX a nivel del origen y de la URL (sujeto a los criterios de elegibilidad habituales) ayude a los sitios a optimizar su métrica de LCP con mayor facilidad.
Tipos de recursos de LCP
Dado que las subpartes se ven mejor para los LCP de imágenes, CrUX restringe estos datos solo a las páginas con imágenes. Por lo tanto, es importante comprender cuántos de tus LCP son de imagen en lugar de texto (como los encabezados <h1> y los párrafos largos, por ejemplo).
Además de las subpartes de imágenes de la LCP, las APIs de CrUX ahora también incluyen un desglose de recursos que muestra la división de las cargas de páginas de la LCP entre texto e imágenes.
Por ejemplo, para obtener los tipos de recursos de LCP para https://web.dev/ para las vistas de página PHONE, puedes usar el siguiente comando curl (una vez más, reemplaza API_KEY por tu propia clave):
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
--header 'Content-Type: application/json' \
--data '{ "formFactor": "PHONE",
"url": "https://web.dev/",
"metrics": ["largest_contentful_paint_resource_type"]}'
Y recibirás algo como lo siguiente:
{
"record": {
"key": {
"formFactor": "PHONE",
"url": "https://web.dev/"
},
"metrics": {
"largest_contentful_paint_resource_type": {
"fractions": {
"image": 0.0155,
"text": 0.9845
}
}
},
"collectionPeriod": {
"firstDate": {
"year": 2025,
"month": 1,
"day": 12
},
"lastDate": {
"year": 2025,
"month": 2,
"day": 8
}
}
}
}
La vista de CrUX también se actualizó para mostrar estos datos:
En el caso de la página principal de web.dev, por ejemplo, podemos ver que el 98.5% de los LCP en realidad eran LCP de texto, por lo que las subpartes de imagen de LCP son menos útiles para esta página. En ese caso, podemos usar las métricas originales de TTFB y FCP como un desglose de diagnóstico potencialmente mejor.
Los tipos de recursos de LCP son otra herramienta de diagnóstico útil para comprender y mejorar el LCP, en especial para saber qué tan útiles son las subpartes de la imagen de LCP.
Información de diagnóstico de RTT
También expandimos la métrica RTT, que se presentó por primera vez en agosto de 2024.
Buckets de RTT
Agregamos tres intervalos a las APIs de CrUX que muestran tres agrupaciones de densidades de RTT:
| Latencia de red | Comenzar | Fin |
|---|---|---|
| Baja | 0 milisegundos | < 75 milisegundos |
| Medio | 75 milisegundos | < 275 milisegundos |
| Alta | 275 milisegundos | ∞ |
Estos intervalos son más informativos que las categorías de ECT anteriores, que incluían todo lo que era inferior a 270 milisegundos en la categoría 4g. Con los avances en la tecnología de redes desde que se lanzaron, la mayoría de los sitios vieron la mayor parte de su tráfico en esa categoría, lo que hace que esta categorización sea menos útil.
Por este motivo, sugerimos usar las etiquetas de distribución baja, media y alta en lugar de las etiquetas habituales buena, necesita mejoras y deficiente. No son métricas que el propietario de un sitio pueda mejorar directamente, por lo que son métricas de diagnóstico para comprender las otras métricas y por qué pueden ser diferentes de lo esperado. También pueden ayudar a explicar por qué otras métricas cambian con el tiempo, a pesar de que el sitio no cambia si muestran un cambio en la base de usuarios.
Estos grupos están disponibles en las APIs de CrUX, por ejemplo, para web.dev para las vistas de página PHONE (una vez más, reemplaza API_KEY por tu propia clave):
curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=API_KEY" \
--header 'Content-Type: application/json' \
--data '{ "formFactor": "PHONE",
"url": "https://web.dev/",
"metrics": ["round_trip_time"]}'
Que muestra algo como lo siguiente:
{
"record": {
"key": {
"formFactor": "PHONE",
"url": "https://web.dev/"
},
"metrics": {
"round_trip_time": {
"histogram": [
{
"start": 0,
"end": 75,
"density": 0.1524
},
{
"start": 75,
"end": 275,
"density": 0.6641
},
{
"start": 275,
"density": 0.1835
}
],
"percentiles": {
"p75": 230
}
}
},
"collectionPeriod": {
"firstDate": {
"year": 2025,
"month": 1,
"day": 12
},
"lastDate": {
"year": 2025,
"month": 2,
"day": 8
}
}
}
}
Los intervalos se muestran en CrUX Vis cuando se seleccionan las distribuciones:
RTT en BigQuery
Además de expandir la métrica RTT en las APIs de CrUX para incluir los tres intervalos, también pusimos los datos a disposición en el conjunto de datos mensual de BigQuery, incluido un histograma completo en intervalos de 25 milisegundos en las tablas sin procesar y los tres intervalos y los valores de p75 en las tablas materializadas.
Esto permite comprender mejor la distribución de los datos más allá de los tres intervalos disponibles en las APIs de CrUX. También nos permite volver a crear el desglose de ECT que se quitó de CrUX a partir de este mes (hablaremos de esto más adelante), con el ligero cambio de un umbral de 275 milisegundos para 4g en lugar del umbral anterior de 270 milisegundos. Los desgloses de ECT (que ahora provienen de los datos de RTT) siguen disponibles en las tablas materializadas de BigQuery de CrUX para que herramientas como el panel de CrUX puedan seguir mostrando este desglose.
El conjunto de datos de BigQuery también incluye datos por país (según se define en ISO 3166-1). Esto permite un análisis más detallado, que puede ser útil para explicar por qué las métricas de rendimiento son peores para algunos usuarios. Por ejemplo, podemos ver los datos de los usuarios de Teléfono de Google si observamos los datos de https://www.google.com:
SELECT
`chrome-ux-report`.experimental.GET_COUNTRY(country_code) AS geo,
least(500, p75_rtt) AS capped_p75_rtt,
p75_rtt
FROM
`chrome-ux-report.materialized.country_summary`
WHERE
origin = 'https://www.google.com' AND
yyyymm = 202501 AND
device = 'phone'
ORDER BY
p75_rtt DESC,
country_code
Luego, visualizamos los datos en un mapa geográfico:
https://www.google.com(datos de origen con gráfico interactivo).
Podemos ver que, mientras que la mayor parte del mundo (en particular, el "mundo occidental") tiene RTT muy buenas, África subsahariana, algunas partes de Medio Oriente y algunas partes de Asia tienen más dificultades. De hecho, el gráfico se limita a 500 milisegundos de RTT, ya que el uso de los datos completos sesgó los colores, en especial con Eritrea en un percentil 75 de 3,850 milisegundos.
Esto también puede ser útil cuando cambian los patrones de tráfico. Por ejemplo, una mayor proporción de usuarios de esos países con RTT más altas puede explicar las peores estadísticas de las métricas principales de la Web Vitals a pesar de que el sitio no haya cambiado nada.
Si bien los sitios no pueden mejorar directamente la RTT, poner estos datos a disposición de los visitantes de un sitio permite comprender mejor a los usuarios de tu sitio en todo el mundo. También genera muchas oportunidades de análisis en el futuro y esperamos que los investigadores encuentren estadísticas interesantes en este conjunto de datos.
Eliminación de la dimensión ECT
El último cambio en el lanzamiento de febrero de 2025 es la baja de la dimensión Tipo de conexión efectiva (ECT) de BigQuery (ya habíamos quitado el RTT de las APIs desde septiembre de 2024 cuando presentamos la métrica RTT como su reemplazo).
Como se mencionó anteriormente en esta publicación, la métrica RTT permite una vista más detallada de los detalles de conexión de los visitantes de un sitio. Incluso puedes volver a crear los buckets de ECT a partir de esos histogramas. (Técnicamente, la ECT debe ser una combinación de la RTT y la velocidad de bajada, pero Chrome solo usó la RTT).
Una diferencia importante es que la ECT era una dimensión de CrUX, lo que significa que las otras métricas se podían segmentar por ECT. El RTT es una métrica de CrUX en lugar de una dimensión, por lo que no es posible ver la LCP por RTT, por ejemplo, sino solo los RTT por las otras dimensiones (tipo de dispositivo y país).
Esto puede parecer más limitante, pero el cambio de dimensión a métrica en realidad desbloquea más datos en CrUX. Esto se debe a que CrUX tiene ciertos umbrales mínimos antes de que podamos mostrar los datos. Ya hicimos que las dimensiones sean opcionales en 2022, lo que significa que quitamos la ECT o el dispositivo cuando fue necesario para generar informes a un nivel superior, pero las métricas que no estaban en la mayoría de las cargas de página (Interacción hasta la siguiente pintura (INP), diferentes tipos de navegación y, ahora, subpartes de imagen de LCP) a menudo no estaban disponibles para los orígenes en BigQuery.
Cuando se reduce la cantidad de dimensiones, los datos están menos segmentados, por lo que aumenta la cantidad de orígenes que cumplen con estos requisitos mínimos. En enero, informamos INP para el 68.1% de los orígenes, mientras que, en el conjunto de datos de diciembre, solo informamos INP para el 64.5% de los orígenes. El mecanismo también se aplica a los tipos de navegación, las subpartes de LCP y los tipos de recursos en esta versión, ya que todos se benefician de la eliminación de la dimensión ECT. En las APIs de CrUX, la cobertura ampliada entró en vigencia a principios de febrero.
Las columnas de ECT permanecerán en BigQuery para mantener la coherencia con los conjuntos de datos anteriores, y los datos de ECT en las vistas materializadas seguirán disponibles, pero se basarán en la información de RTT (con una diferencia de 5 milisegundos para 3g y 4g, como se señaló anteriormente), además de los nuevos p75 de RTT y los tres intervalos.
Conclusión
La incorporación de más métricas al conjunto de datos público de CrUX les brinda a los propietarios de sitios y a los investigadores mucha más información para ayudar a diagnosticar y, en última instancia, solucionar problemas de rendimiento.
Como conjunto de datos público, CrUX tiene ciertas limitaciones en el nivel de detalle que podemos mostrar. Por ejemplo, los selectores de elementos individuales nunca se podrán mostrar en CrUX. Se recomienda a los propietarios de sitios que buscan este nivel de detalle que implementen una solución de RUM, que no tendrá tantas limitaciones.
Sin embargo, los datos agregados de nivel superior, como los que se detallan en esta publicación, pueden ayudar a cerrar la brecha entre saber que tienes un problema y por qué existe. Esperamos que estos datos adicionales te resulten útiles. Comunícate con nosotros en el grupo de debate si tienes comentarios o preguntas.