¿Qué son los Core Web Vitals y cómo se interpretan?
Qué miden LCP, INP y CLS, qué cifras se consideran buenas, por qué los datos de usuarios reales no coinciden con la nota de Lighthouse y por dónde empezar cuando una métrica sale en rojo.
Por Javier Tenjo, Desarrollador full stack
En esta página
Cuando alguien dice que una web «va lenta», casi nunca se refiere a una sola cosa. Puede que tarde en aparecer lo importante, que no reaccione al pulsar un botón o que el texto salte justo cuando ibas a leerlo. Son tres molestias distintas, con causas distintas, y Google las mide por separado.
Los Core Web Vitals son esas tres medidas. Google las usa como señal al ordenar resultados, pero su valor práctico es otro: convierten en números lo que siente quien visita tu web y permiten decidir qué arreglar primero.
Las tres métricas, en lenguaje llano
LCP (Largest Contentful Paint). Cuánto tarda en pintarse el elemento más grande de la primera pantalla: normalmente la imagen principal, un titular o un bloque de texto. Responde a la pregunta «¿cuándo vi que la página ya estaba ahí?».
INP (Interaction to Next Paint). Cuánto tarda la página en reaccionar visiblemente cuando tocas, haces clic o escribes. Tiene en cuenta todas las interacciones de la visita y se queda con una de las peores. Sustituyó en 2024 a FID, que solo medía la primera interacción, y es bastante más exigente.
CLS (Cumulative Layout Shift). Cuánto se mueve el contenido mientras carga. No se expresa en segundos, sino con una puntuación sin unidades que combina cuánta superficie se desplaza y cuánta distancia recorre. Es el botón que se escapa de debajo del dedo porque encima acaba de aparecer un aviso.
Hay otras métricas útiles para diagnosticar, como el TTFB (lo que tarda el servidor en empezar a responder) o el FCP (lo primero que se pinta), pero no forman parte de la evaluación.
¿Qué cifras se consideran buenas?
Google publica tres franjas para cada métrica:
| Métrica | Bueno | Mejorable | Pobre |
|---|---|---|---|
| LCP | hasta 2,5 s | de 2,5 a 4 s | más de 4 s |
| INP | hasta 200 ms | de 200 a 500 ms | más de 500 ms |
| CLS | hasta 0,1 | de 0,1 a 0,25 | más de 0,25 |
Una página pasa la evaluación cuando las tres están en la franja buena. Basta con que una falle para que el veredicto sea negativo. Y móvil y escritorio se evalúan por separado: es habitual aprobar en escritorio y suspender en el teléfono.
¿Por qué se usa el percentil 75 y no la media?
Las cifras no salen de la media de las visitas, sino del percentil 75: el valor que no superan tres de cada cuatro visitas. Si tu LCP en el p75 es de 2,3 segundos, el 75 % de la gente vio el contenido principal en 2,3 segundos o menos.
La media escondería justo a quien peor lo pasa, que suele ser quien navega con un móvil sencillo y mala cobertura. Con el p75, una cuarta parte del público puede tener una mala experiencia sin hundir la nota, pero no la mitad. Por eso lo que mueve el resultado es rescatar el tramo lento, no acelerar a quien ya iba rápido.
Datos de campo y datos de laboratorio
Aquí está la confusión más frecuente. Hay dos formas de medir, y dan cifras distintas por diseño.
Datos de campo. Salen del Chrome UX Report (CrUX), un conjunto de datos público que Google construye con las visitas reales de usuarios de Chrome que comparten estadísticas de uso. Se agregan en una ventana móvil de 28 días. Son los que cuentan para la evaluación.
Datos de laboratorio. Salen de herramientas como Lighthouse, que es la que está detrás de la puntuación de 0 a 100 de PageSpeed Insights. Cargan la página una vez, en un dispositivo y una red simulados. Son reproducibles y muy útiles para depurar, pero no describen lo que vive tu público.
¿Por qué no coinciden?
- El dispositivo. La simulación usa un perfil de móvil fijo; tu público usa el teléfono que tiene, a veces bastante más modesto.
- La red. El laboratorio simula una conexión estable; en la calle hay cobertura irregular y redes saturadas.
- La interacción. Lighthouse carga la página pero no la usa, así que no puede medir INP. En su lugar estima cuánto se bloquea el navegador durante la carga (el Total Blocking Time). Un problema de respuesta al pulsar solo se ve de verdad en campo.
- Lo que pasa después de cargar. Avisos de cookies, chats, anuncios o bloques que aparecen al hacer scroll mueven el CLS de los usuarios reales y a menudo no aparecen en una carga de laboratorio.
- El tiempo. El laboratorio es una foto de ahora; el campo resume cuatro semanas. Un arreglo publicado ayer ya se ve en Lighthouse y tarda semanas en reflejarse del todo en CrUX.
Una regla útil para no perderse: el laboratorio sirve para encontrar la causa; el campo dice si el problema existe y si de verdad lo has resuelto.
¿Qué hacer si una métrica sale mal?
Cada métrica tiene sus sospechosos habituales:
Si falla el LCP:
- La imagen principal pesa demasiado o usa un formato antiguo. Comprímela, sírvela en WebP o AVIF y al tamaño al que de verdad se pinta; está explicado en la guía de imágenes para tu web.
- Esa imagen se carga en diferido (
loading="lazy") aunque esté en la primera pantalla. Debe pedirse cuanto antes, incluso confetchpriority="high". - El servidor tarda en responder. Si el TTFB ya consume la mitad del margen, ninguna optimización del diseño lo compensa: hace falta caché, una CDN o un alojamiento mejor.
- Fuentes y hojas de estilo que bloquean el primer pintado.
Si falla el INP:
- Demasiado JavaScript ocupando el navegador: etiquetas de marketing, chats, widgets de terceros. Revisar si todos siguen haciendo falta suele ser la vía más rápida.
- Tareas largas que se ejecutan justo al pulsar. Dividirlas permite que el navegador responda entre medias.
Si falla el CLS:
- Imágenes, vídeos o iframes sin
widthyheight(o sinaspect-ratio), que no reservan su hueco. - Avisos, banners o anuncios que empujan el contenido en lugar de superponerse o tener un espacio reservado.
- Fuentes web que cambian el tamaño del texto al terminar de cargar.
Empieza por el móvil. Casi siempre es el que falla, porque la red y el procesador son peores, y es el que cuenta cuando te buscan desde el teléfono. Si tu web aún no está pensada para pantallas pequeñas, ese es el primer problema; lo contamos en por qué importa el diseño responsive.
¿Cuánto pesan en el posicionamiento?
Conviene ponerlo en su sitio. Los Core Web Vitals son una señal real, pero ligera frente a la relevancia: una página lenta que responde mejor a la búsqueda seguirá por delante de una rápida que no lo hace. Donde sí marcan diferencia es entre páginas igual de útiles, y sobre todo en lo que pasa después del clic: menos abandonos, más formularios completados, más gente que llega al final.
Para el resto de factores, la guía completa de posicionamiento web da el contexto.
¿Cómo comprobar los de tu web?
El comprobador de Core Web Vitals consulta directamente el informe CrUX de Google, así que enseña datos de campo y no una simulación. Escribe tu dominio para ver el origen completo, o una URL concreta si tiene tráfico suficiente. Verás móvil y escritorio a la vez, el p75 de LCP, INP y CLS (con FCP y TTFB como apoyo), cómo se reparten las visitas entre bueno, mejorable y pobre, y si pasas o no la evaluación.
Si algo sale en rojo, usa Lighthouse para buscar la causa en esa métrica concreta, corrige y vuelve a consultar CrUX pasadas unas semanas, cuando la ventana de 28 días ya recoja el cambio. Si no aparecen datos, no es un error: tu sitio aún no tiene visitas suficientes en Chrome, y el laboratorio es la única referencia disponible.
Los Core Web Vitals no premian una puntuación redonda: premian que la página aparezca pronto, responda al tocarla y se quede quieta. Mirarlos con datos reales y por dispositivo es la forma más directa de saber qué siente tu público.