Métricas

Fecha de publicación: 23 de junio de 2022. Última actualización: 18 de noviembre de 2025

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 más detallado (p.ej., resolución a nivel de la URL) y estadísticas sobre el rendimiento de su sitio pueden usar las mismas APIs para recopilar datos detallados de 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 la aproximación de los valores de percentiles.

Cambio de diseño acumulado

"El cambio de diseño acumulado (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".

web.dev/articles/cls

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".

MDN

First Paint

"First Paint informa el tiempo en que el navegador realiza 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 la página, cuando el navegador comienza a renderizar la página".

API de Paint Timing

First Contentful Paint

"First Contentful Paint (FCP) informa el tiempo en el que el navegador procesó textos, imágenes (incluidas las de fondo), lienzos no blancos o SVG por primera vez. Se incluyen textos con fuentes para sitios web pendientes. Esta es la primera vez que los usuarios pueden comenzar a consumir contenido de la página".

API de Paint Timing

Interaction to Next Paint

"Interaction to Next Paint (INP) es una métrica de campo que evalúa la capacidad de respuesta. 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 cerca del más alto para las páginas con muchas interacciones, se registra como el INP de la página. Un INP bajo garantiza que la página responderá de manera confiable en todo momento".

web.dev/articles/inp

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 eventos individuales y ofrece una imagen más integral de la capacidad de respuesta general de una página durante su ciclo de vida.

Largest Contentful Paint

"Largest Contentful Paint (LCP) es una métrica importante centrada en el usuario para medir la velocidad de carga percibida, ya que indica 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".

web.dev/articles/lcp

Tipo de recurso Largest Contentful Paint

"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 - What elements are considered for LCP

El texto y la imagen (incluida la imagen del primer fotograma de video) suelen tener características de carga y técnicas de optimización muy diferentes. Comprender la proporción de tipos de recursos de LCP te permite comprender mejor tus métricas de 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 de LCP.

Subpartes de la imagen Largest Contentful Paint

"La optimización para LCP puede ser una tarea más compleja cuando PageSpeed Insights no te da la respuesta sobre cómo mejorar esta métrica. Con tareas complejas, suele ser mejor dividirlas en tareas más pequeñas y manejables, y abordar cada una por separado".

web.dev/articles/optimize-lcp - LCP breakdown into subparts

Dividir las LCP de las imágenes en sus subpartes más importantes permite utilizar recomendaciones y prácticas recomendadas específicas para optimizar cada parte.

Las subpartes de la imagen LCP se proporcionan en cuatro métricas separadas:

  • 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

Las subpartes solo se incluyen para las imágenes y no incluyen las imágenes del primer fotograma de video, ya que son un poco más complicadas, ya que no podemos medir el tiempo de descarga completo (ten en cuenta que los primeros fotogramas de video se incluyen en la métrica de tipo de recurso de LCP, en la que esa complicación no es relevante).

Las subpartes de texto tampoco se incluyen, ya que son menos útiles y distorsionan los números de LCP de las imágenes. Para los sitios que se componen principalmente de LCP de texto, las métricas generales de TTFB y generales de FCP son desgloses útiles, aunque ten en cuenta que se aplican a todas las LCP y no son específicas de las LCP de texto.

Para obtener más información, consulta la entrada de blog sobre el lanzamiento de las subpartes de la imagen LCP .

La métrica tipos de navegación proporciona un desglose del porcentaje de páginas vistas de las siguientes navegaciones:

Tipo Descripción
navigate Una carga de página que no se ajusta a ninguna de las otras categorías.
navigate_cache 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 subrecursos, pero el documento HTML principal suele almacenarse en caché mucho menos y, cuando se puede, puede generar mejoras notables en el rendimiento, ya que se puede almacenar en caché de forma local y en una CDN.
reload El usuario volvió a cargar la página, ya sea 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ágina suelen generar una revalidación al servidor para verificar si cambió la página principal. Un porcentaje alto de recargas de página puede indicar frustraciones en la experiencia del usuario.
restore La página se volvió a cargar 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 "reload".
back_forward Una 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 deberían ser experiencias razonablemente rápidas, pero aún requieren que se procese la página y que se ejecute JavaScript, lo que evita la bfcache.
back_forward_cache Una navegación por el historial que se entregó 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, al igual que la bfcache, puede generar cargas de página casi instantáneas.

En algunos casos, una carga de página puede ser una combinación de varios tipos de navegación. En ese caso, CrUX informa la primera coincidencia en orden inverso de la tabla (de abajo hacia arriba).

Puedes encontrar más información en la entrada de anuncio de los tipos de navegación.

Onload

"El evento de carga se activa cuando la página y sus recursos dependientes terminaron de cargarse".

MDN

Tiempo de ida y vuelta

Proporciona una estimación del tiempo de ida y vuelta de HTTP (capa de aplicación) al comienzo de la navegación, según las conexiones de red recientes. Esta métrica se basa en la rtt propiedad de la API de Network Information, que es la misma API responsable de la dimensión anterior de tipo de conexión efectiva (ECT).

Para obtener más información, consulta la entrada de blog sobre el lanzamiento de los tipos de recursos de LCP.

Métricas experimentales

Las métricas experimentales están disponibles en el conjunto de datos de CrUX con BigQuery, y algunas también están disponibles en la API de CrUX. Es probable que estas métricas cambien con regularidad 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 con los cambios más recientes.

Time to First Byte

El TTFB en CrUX solo se recopila en cargas de página completas, a diferencia de otros temporizadores (como LCP), que también se recopilan en navegaciones de caché hacia atrás y hacia adelante (bfcache) y en páginas renderizadas previamente. Por lo tanto, el tamaño de la muestra de TTFB puede ser más pequeño que el de otras métricas y es posible que no se compare directamente con ellas. El TTFB en CrUX incluirá cargas de página en frío, cargas de página almacenadas en caché y cargas de página desde una conexión establecida (por ejemplo, cargas de página 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é o la CDN, o desde el servidor. Esto es particularmente evidente 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 es la que se prueba y, a menudo, se niegan repetidamente los cambios en el almacenamiento en caché.

Popularidad

La métrica de clasificación de popularidad es una medida relativa de la popularidad del sitio dentro del conjunto de datos de CrUX, medida por la cantidad total de navegaciones en el origen. La clasificación se encuentra en una escala log10 con medios pasos (p. ej., 1,000 principales, 5,000 principales, 10,000 principales, 50,000 principales, 100,000 principales, 500,000 principales, 1 millón principales, etcétera), y cada clasificación excluye la anterior (p. ej., 5,000 principales son en realidad 4,000 URLs, excluyendo las 1,000 principales). El límite superior es dinámico a medida que crece el conjunto de datos.

La popularidad se proporciona como una 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 las indicaciones: aceptar, rechazar, ignorar o descartar.