Métricas

Publicado el 23 de junio de 2022. Última actualización el 13 de octubre 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 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 los usuarios 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 momento en que el documento HTML inicial se cargó y analizó por completo, sin esperar a que se terminen de cargar las hojas de estilo, las imágenes y los submarcos".

MDN

First Paint

"First Paint informa el momento en que el navegador realizó la primera renderización después de la navegación. Esto excluye la renderización de fondo predeterminada, pero incluye la renderización de fondo no predeterminada. Este es el primer momento clave que les importa a los desarrolladores en la carga de página, es decir, cuando el navegador comenzó a renderizar la página".

API de Paint Timing

First Contentful Paint

"First Contentful Paint (FCP) informa el momento en que el navegador renderizó por primera vez cualquier texto, imagen (incluidas las imágenes de fondo), lienzo no blanco o SVG. Esto incluye texto con fuentes 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 cercano al más alto para las páginas con muchas interacciones, se registra como la INP de la página. Una INP baja 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 los usuarios 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 de 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 - ¿Qué elementos se consideran 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 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 de Largest Contentful Paint

"Optimizar para lograr un mejor 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 - Desglose del LCP en subpartes

Desglosar los 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 de 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 esto no incluye las imágenes del primer fotograma del 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 del 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 todos los LCP y no son específicos de los LCP de texto.

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

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

Tipo Descripción
navigate Una carga de página que no corresponde 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áginas suelen generar una revalidación al servidor para verificar si la página principal cambió. Un porcentaje alto de recargas de páginas 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 blog sobre el 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 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 actualizado sobre los cambios más recientes.

Métricas experimentales de Métricas web esenciales de navegación suave

En la versión de octubre de 2026, se introdujeron versiones experimentales de las métricas de Métricas web esenciales, incluidas las navegaciones suaves:

  • experimental_largest_contentful_paint_with_softnavs
  • experimental_interaction_to_next_paint_with_softnavs
  • experimental_cumulative_layout_shift_with_softnavs

Estas métricas incluyen cargas de página completas y navegaciones suaves.

Para obtener más detalles, consulta Presentamos las métricas experimentales de Core Web Vitals en el Chrome UX Report.

Time to First Byte

El TTFB en CrUX solo se recopila en cargas de página completas, a diferencia de otros temporizadores (como el 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áginas frías, cargas de páginas almacenadas 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 puede verse 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 lab 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 de almacenamiento en caché.

Popularidad

La métrica de clasificación por 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 los mensajes: aceptar, rechazar, ignorar o descartar.

Métricas de anuncios

Chrome proporciona métricas y herramientas públicas para que los sitios y otras entidades, como los anunciantes, comprendan mejor las experiencias de anuncios de los usuarios reales y su impacto.

Esperamos que estas métricas sean particularmente útiles para los anunciantes web y los servicios que usan para publicar anuncios. Recibimos comentarios de una gran variedad de partes interesadas del ecosistema de publicidad que indican 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.