Fecha de publicación: 23 de junio de 2022; última actualización: 15 de septiembre de 2026
Las métricas de CrUX se basan en las APIs de la plataforma web estándar que exponen los navegadores. En el conjunto de datos de BigQuery en particular, estos datos se agregan a la resolución de origen. Los propietarios de sitios que requieren un análisis y estadísticas más detallados (p.ej., resolución a nivel de la URL) sobre el rendimiento de su sitio pueden usar las mismas APIs para recopilar datos detallados de la medición de usuarios reales (RUM) para sus propios orígenes. Ten en cuenta que, si bien todas las APIs están disponibles en Chrome, es posible que otros navegadores no admitan el conjunto completo de métricas.
La mayoría de las métricas se representan como una agregación de histogramas, lo que permite visualizar la distribución y aproximar los valores de percentiles.
Cambio de diseño acumulado
El Cumulative Layout Shift (CLS) es una métrica importante centrada en el usuario para medir la estabilidad visual, ya que ayuda a cuantificar la frecuencia con la que los usuarios experimentan cambios de diseño inesperados. Un CLS bajo ayuda a garantizar que la página sea agradable.
DOM Content Loaded
"DOMContentLoaded informa el tiempo en que se completó la carga y el análisis del documento HTML inicial, sin esperar a que termine la carga de las hojas de estilo, las imágenes y los marcos secundarios".
First Paint
"First Paint informa el tiempo en que el navegador realizó el primer procesamiento después de la navegación. Solo incluye el procesamiento de imagen que no es predeterminado. Este es el primer momento clave que les importa a los desarrolladores en la carga de página: cuando el navegador comenzó a renderizar la página".
First Contentful Paint
El First Contentful Paint (FCP) indica el momento en el que el navegador procesó textos, imágenes (incluidas las de fondo), lienzos no blancos o SVG por primera vez. Se incluye texto con fuentes para sitios web pendientes. Esta es la primera vez que los usuarios pueden comenzar a consumir contenido de la página".
Interaction to Next Paint
"Interaction to Next Paint (INP) es una métrica de campo que evalúa la capacidad de respuesta. El INP registra la latencia de todas las interacciones durante todo el ciclo de vida de la página. El valor más alto de esas interacciones (o un valor cercano al más alto en el caso de las páginas con muchas interacciones) se registra como la INP de la página. Un INP bajo garantiza que la página responderá de forma confiable en todo momento".
La métrica Interaction to Next Paint (INP) se agregó al conjunto de datos de CrUX en febrero de 2022. Esta nueva métrica captura la latencia de extremo a extremo de los eventos individuales y ofrece una imagen más integral de la capacidad de respuesta general de una página a lo largo de su ciclo de vida.
Procesamiento de imagen con contenido más grande
"Largest Contentful Paint (LCP) es una métrica importante centrada en el usuario para medir la velocidad de carga percibida, ya que marca el punto en el cronograma de carga de la página cuando es probable que se haya cargado el contenido principal de la página. Un LCP rápido ayuda a garantizar al usuario que la página es útil".
Tipo de recurso de Largest Contentful Paint
"El LCP informa el tiempo de renderización de la imagen, el bloque de texto o el video más grandes que se pueden ver en el viewport, en relación con el momento en que el usuario navegó a la página por primera vez".
web.dev/articles/lcp: ¿Qué elementos se tienen en cuenta para el LCP?
El texto y la imagen (incluida la imagen del primer fotograma del video) suelen tener características de carga y técnicas de optimización muy diferentes. Comprender la proporción de los tipos de recursos del LCP te permite comprender mejor las métricas del LCP y las rutas de optimización.
Para obtener más información, consulta la entrada de blog sobre el lanzamiento de los tipos de recursos del LCP.
Subpartes de la imagen del Largest Contentful Paint
"Optimizar el LCP puede ser una tarea más compleja cuando PageSpeed Insights no te brinda la respuesta sobre cómo mejorar esta métrica. Con las tareas complejas, suele ser mejor dividirlas en tareas más pequeñas y fáciles de administrar, y abordar cada una por separado".
web.dev/articles/optimize-lcp: Desglose del LCP en partes
Desglosar los LCP de las imágenes en sus partes más críticas permite utilizar recomendaciones y prácticas recomendadas específicas para optimizar cada parte.
Las partes secundarias de la imagen del LCP se proporcionan en cuatro métricas separadas:
largest_contentful_paint_image_time_to_first_bytelargest_contentful_paint_image_resource_load_delaylargest_contentful_paint_image_resource_load_durationlargest_contentful_paint_image_element_render_delay
Las subpartes solo se incluyen para las imágenes, y esto no incluye las imágenes del primer fotograma de video, ya que son un poco más complicadas porque no podemos medir el tiempo de descarga completo (ten en cuenta que los primeros fotogramas de video se incluyen en la métrica del tipo de recurso LCP, en la que esa complicación no es relevante).
Tampoco se incluyen las subpartes de texto, ya que son menos útiles y distorsionarían las cifras del LCP de la imagen. 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íficas de los LCP de texto.
Para obtener más información, consulta la entrada de blog sobre el lanzamiento de las subpartes de imágenes del LCP.
Tipos de navegación
La métrica tipos de navegación proporciona un desglose del porcentaje de vistas de página de las siguientes navegaciones:
| Tipo | Descripción |
|---|---|
navigate |
Carga de página que no corresponde a ninguna de las otras categorías. |
navigate_cache |
Es una carga de página para la que el recurso principal (el documento HTML principal) se entregó desde la caché HTTP. Los sitios suelen usar el almacenamiento en caché para los recursos secundarios, pero el documento HTML principal a menudo se almacena en caché mucho menos y, cuando se puede, puede generar mejoras notables en el rendimiento por poder almacenarse en caché de forma local y en una CDN. |
reload |
El usuario volvió a cargar la página presionando el botón de recarga, presionando Intro en la barra de direcciones o deshaciendo el cierre de una pestaña. Las recargas de páginas suelen generar una revalidación al servidor para verificar si la página principal cambió. Un porcentaje alto de recargas de página puede indicar frustraciones en la experiencia del usuario. |
restore |
Se volvió a cargar la página después de reiniciar el navegador o una pestaña que se había quitado por motivos de memoria. En Chrome para Android, se informan como "recarga". |
back_forward |
Navegación por el historial, lo que significa que la página se vio y se volvió a visitar recientemente. Con el almacenamiento en caché correcto, estas experiencias deberían ser razonablemente rápidas, pero aun así requieren que se procese la página y se ejecute JavaScript, dos procesos que la bfcache evita. |
back_forward_cache |
Es una navegación basada en el historial que se publicó desde la bfcache. Optimizar tus páginas para aprovechar la bfcache, quitando los bloqueadores, debería generar experiencias más rápidas, por lo que los sitios deberían verse |
prerender |
La página se renderizó previamente, lo que, de manera similar a la bfcache, puede generar cargas de páginas casi instantáneas. |
En algunos casos, la carga de una página puede ser una combinación de varios tipos de navegación. En ese caso, CrUX informa la primera coincidencia en orden inverso al de la tabla (de abajo hacia arriba).
Puedes encontrar más información en la publicación del anuncio sobre los tipos de navegación.
Onload
"El evento de carga se activa cuando la página y sus recursos dependientes terminaron de cargarse".
Tiempo de ida y vuelta
Proporciona una estimación del tiempo de ida y vuelta HTTP (capa de aplicación) al inicio de la navegación, según las conexiones de red recientes.
Esta métrica se basa en la propiedad rtt de la API de Network Information, que es la misma API responsable de la anterior dimensión Effective Connection Type (ECT).
Para obtener más información, consulta la entrada de blog sobre el lanzamiento de los tipos de recursos del LCP.
Métricas experimentales
Las métricas experimentales están disponibles en el conjunto de datos de CrUX a través de BigQuery y en la API de CrUX, aunque no todas las métricas están disponibles en ambos. Estas métricas están sujetas a cambios a medida que evolucionan en función de los comentarios de los usuarios. Consulta las notas de la versión para mantenerte al día sobre los cambios más recientes.
Time to First Byte
El TTFB en CrUX solo se recopila en las cargas de página completas, a diferencia de otros temporizadores (como el LCP) que también se recopilan en las navegaciones de la memoria caché atrás/adelante (bfcache) y las páginas renderizadas previamente. Por lo tanto, el tamaño de la muestra del TTFB puede ser más pequeño que el de otras métricas y no necesariamente se puede comparar directamente con ellas. El TTFB en CrUX incluirá cargas de páginas en frío, cargas de páginas en caché y cargas de páginas desde una conexión establecida (por ejemplo, cargas de páginas dentro del sitio).
El TTFB no es una medida directa del tiempo de respuesta del servidor, ya que incluye medidas anteriores, como el tiempo de redireccionamiento, y se ve afectado por si una respuesta se entrega desde la caché, la CDN o el servidor. Esto se evidencia particularmente en los datos de campo, como CrUX, mientras que las pruebas de laboratorio suelen verse menos afectadas por estos factores, ya que la URL final se prueba y, a menudo, se niegan repetidamente los cambios de almacenamiento en caché.
Popularidad
La métrica del ranking de popularidad es una medida relativa de la popularidad del sitio dentro del conjunto de datos de CrUX, que se mide según la cantidad total de navegaciones en el origen. El ranking se basa en una escala logarítmica de base 10 con medios pasos (p. ej., las 1,000 principales, las 5,000 principales, las 10,000 principales, las 50,000 principales, las 100,000 principales, las 500,000 principales, el millón de principales, etcétera), y cada ranking excluye el anterior (p. ej., las 5,000 principales son en realidad 4,000 URLs, ya que se excluyen las 1,000 principales). El límite superior es dinámico a medida que crece el conjunto de datos.
La popularidad se proporciona como guía para el análisis general, por ejemplo, para determinar el rendimiento por país de los 1,000 orígenes principales.
Permisos de notificaciones
En el caso de los sitios web que solicitan permiso para mostrar notificaciones a los usuarios, esta métrica representa la frecuencia relativa de las respuestas de los usuarios a los mensajes: aceptar, rechazar, ignorar o descartar.
Métricas de anuncios
Chrome proporciona métricas y herramientas públicas para que los sitios y otros, como los anunciantes, comprendan mejor las experiencias de los usuarios reales con los anuncios y su impacto.
- Recuento de anuncios: Esta métrica describe cuántos anuncios ve un usuario típico a la vez en el sitio.
- Densidad de anuncios: Esta métrica describe el equilibrio típico de un usuario entre la visibilidad del contenido y la publicidad.
- Peso del anuncio: CPU: Esta métrica describe el consumo de CPU por parte de los anuncios, lo que puede afectar el rendimiento.
- Peso del anuncio: Red: Esta métrica describe el consumo de recursos de red por parte de los anuncios.
Esperamos que estas métricas sean particularmente útiles para los anunciantes web y los servicios que utilizan para publicar anuncios. Muchos interesados del ecosistema publicitario nos comentaron que estas métricas podrían mejorar la forma en que valoran las oportunidades publicitarias y toman decisiones sobre los productos publicitarios.
Para obtener más información, consulta la entrada de blog sobre el lanzamiento de las métricas de anuncios y la documentación sobre las mediciones de anuncios.