Core Web Vitals con datos reales de usuarios

LCP, INP y CLS medidos en las visitas reales de Chrome de los últimos 28 días, en móvil y en escritorio. Es lo que Google usa en el informe de experiencia de página, no una carga simulada.

  • Gratis
  • Sin registro
  • Datos reales de Chrome
  • Móvil y escritorio

La URL se envía a la API de Chrome UX Report de Google desde nuestra función y el resultado se cachea seis horas. No registramos lo que consultas.

¿Cómo se usa?

  1. 01

    Escribe la URL o el dominio

    Con «origen entero» se miden todas las páginas del dominio juntas; con «esta URL», solo esa página, si tiene tráfico suficiente.

  2. 02

    Mira móvil y escritorio

    Google evalúa cada dispositivo por separado y casi siempre el móvil es el que falla. Aquí se ven los dos a la vez.

  3. 03

    Lee el p75 y la barra

    El p75 es lo que decide; la barra enseña cómo se reparten las visitas. Una métrica puede pasar con muchas visitas lentas si el 75 % va bien.

Datos de campo frente a datos de laboratorio

Lighthouse carga la página una vez, en un móvil simulado con una conexión simulada, y da una nota. Es útil para encontrar qué arreglar, y por eso lo usamos en cada build. Pero es una aproximación: no sabe qué móviles usa tu público, ni qué red, ni qué extensiones, ni a qué horas tu servidor va justo.

CrUX es lo contrario: no simula nada. Recoge lo que les pasó a los usuarios reales de Chrome durante los últimos 28 días y publica el percentil 75. Es el dato que Google usa en Search Console y en el informe de experiencia de página, y el que influye en el posicionamiento. Cuando los dos discrepan, manda este.

Cada métrica, en una frase

LCP
Largest Contentful Paint. Cuánto tarda en verse el elemento más grande de la pantalla inicial.
INP
Interaction to Next Paint. Cuánto tarda la página en responder cuando se pulsa o se escribe.
CLS
Cumulative Layout Shift. Cuánto se mueve el contenido mientras carga.
FCP
First Contentful Paint. Cuánto tarda en aparecer lo primero que se pinta. No puntúa en la evaluación.
TTFB
Time to First Byte. Cuánto tarda el servidor en empezar a responder. No puntúa en la evaluación.

Pasar en laboratorio y fallar en campo tiene causa

Casi siempre es una de tres: un servidor que responde lento a ciertas horas, scripts de terceros que no cargan en la simulación pero sí en la visita real, o un público con móviles más modestos que el que simula Lighthouse. Las tres se diagnostican y se arreglan; lo que no funciona es optimizar para la nota.

Este sitio tiene presupuestos de rendimiento verificados en cada build: peso máximo de CSS y JavaScript, LCP y CLS medidos antes de desplegar. Es la forma de que las cifras de campo no se degraden en silencio seis meses después del lanzamiento.

Cómo trabajamos el rendimiento y el SEO técnico →

Preguntas frecuentes

¿Por qué PageSpeed me da 90 y aquí no paso?

Porque miden cosas distintas. La puntuación de PageSpeed sale de Lighthouse, que carga la página una vez, en un dispositivo simulado y con una conexión simulada. CrUX recoge lo que les pasó a los usuarios reales de Chrome durante los últimos 28 días: con sus móviles, sus redes y sus extensiones. Un sitio puede clavar la prueba de laboratorio y fallar en campo por un servidor lento a ciertas horas, por un script de terceros que no carga en la simulación o por un público que navega con móviles modestos. Para posicionar, el que cuenta es el de campo.

¿Qué es el p75?

El percentil 75: el valor que el 75 % de las visitas no supera. Si el LCP p75 es de 2,1 segundos, tres de cada cuatro visitas vieron el contenido principal en 2,1 segundos o menos. Google eligió ese percentil para que una página no pase por tener una media buena mientras una cuarta parte de la gente la sufre.

¿Cuánto tarda en reflejarse una mejora?

Los datos son una ventana móvil de 28 días que se actualiza a diario. Una mejora publicada hoy empieza a notarse en unos días y solo se ve del todo cuando los 28 días completos son posteriores al cambio. Aquí, además, el resultado se cachea seis horas.

¿Por qué no hay datos de mi web?

Google solo publica cifras cuando un origen o una URL tiene un volumen mínimo de visitas en Chrome, y no dice cuál es. Un sitio pequeño suele tener datos del origen entero y no de páginas sueltas; uno muy pequeño, de ninguno. En ese caso la única medida disponible es la de laboratorio, y conviene recordar que es una aproximación.

¿INP sustituyó a FID?

Sí, en marzo de 2024. FID medía solo el retraso de la primera interacción; INP mide la latencia de todas las interacciones de la visita y se queda con una de las peores. Es más exigente y es la que más sitios hace fallar hoy: suele deberse a JavaScript que bloquea el hilo principal justo cuando alguien pulsa.

¿Móvil o escritorio?

Google evalúa cada uno por separado y para posicionar en búsquedas móviles mira el móvil. Casi siempre es el que falla, porque la red y el procesador son peores. Si tienes que elegir dónde invertir, empieza por el móvil.

¿Se guarda la URL que consulto?

La URL sale de nuestra función hacia la API de Chrome UX Report de Google, que es quien tiene los datos; nosotros no la registramos. El resultado se cachea seis horas para no gastar cuota en la misma consulta repetida.

¿Tu web pasa en laboratorio y falla con usuarios reales?

Suele ser el servidor, los scripts de terceros o el peso del JavaScript. Lo medimos con datos de campo, lo arreglamos y dejamos presupuestos de rendimiento que lo vigilen en cada despliegue.

Respondemos en menos de 24 horas hábilesBogotá · UTC−5

Escríbenos por WhatsApp (se abre en una pestaña nueva)