Core Web Vitals: qué son y cómo medir LCP, INP y CLS
Actualizado en noviembre 2026 | Por Freddy Enguita | 15 min de lectura
Tabla de contenidos
Las Core Web Vitals son tres métricas que ayudan a evaluar cómo experimentan las personas una página: cuándo aparece su contenido principal, con qué rapidez responde a una interacción y si los elementos cambian de sitio inesperadamente. Sus nombres son LCP, INP y CLS.
Para utilizarlas bien necesitas saber qué mide cada una y de dónde procede el resultado que estás mirando. Una prueba puntual puede ayudarte a localizar una causa; los datos de uso real permiten observar qué ocurre en las visitas recogidas. En esta guía veremos los umbrales, cómo leer PageSpeed Insights y Search Console y qué corregir primero en una web profesional.
Qué son las Core Web Vitals
Una página puede mostrar contenido pronto y reaccionar con retraso al abrir un menú. También puede responder bien y desplazar un botón cuando se carga una imagen. Las Core Web Vitals permiten separar esas situaciones en tres dimensiones: carga, capacidad de respuesta y estabilidad visual. Ese desglose ayuda a saber qué necesita una revisión más concreta.
Si necesitas situar estas métricas dentro de la experiencia y los objetivos de tu negocio, la guía sobre velocidad de carga web explica ese contexto.
Qué mide cada métrica: LCP, INP y CLS
LCP: cuándo se muestra el elemento principal
Largest Contentful Paint mide cuándo se renderiza el elemento de contenido más grande visible en la pantalla durante la carga, por ejemplo una imagen destacada o un bloque de texto. Es una referencia de carga percibida, no el momento en que termina de descargarse todo lo que contiene la página.
Si la zona principal aparece tarde, conviene identificar qué elemento está midiendo la herramienta. Comprimir una imagen distinta o retocar recursos secundarios puede dejar intacta la causa del problema. La definición oficial de LCP explica qué elementos pueden intervenir en esta medición.
INP: cómo responde la página al interactuar
Interaction to Next Paint observa la respuesta visual a clics, toques y pulsaciones de teclado durante la visita. Una interacción lenta puede aparecer al abrir la navegación, desplegar una sección o utilizar un filtro. El valor representa una de las interacciones más lentas, con un tratamiento específico de los casos atípicos.
Es importante distinguir esa respuesta del tiempo total de una operación: mostrar que un formulario se está enviando y recibir después una respuesta del servidor son momentos diferentes. INP se ocupa del retraso hasta la siguiente actualización visual. La documentación de INP desarrolla esta diferencia.
CLS: cuánto se desplaza el contenido inesperadamente
Cumulative Layout Shift refleja la inestabilidad visual causada por desplazamientos inesperados del contenido. Ocurre, por ejemplo, si aparece un bloque sin espacio reservado y empuja lo que estabas leyendo o el botón que ibas a pulsar.
CLS es una puntuación sin unidad: no se expresa en segundos. Su cálculo considera la mayor agrupación de desplazamientos dentro de unas ventanas de sesión, no una suma ilimitada de todos los movimientos. La explicación oficial de CLS permite entender por qué una página que parece rápida puede seguir siendo incómoda de utilizar.
Qué valores se consideran buenos
Los umbrales de referencia distinguen tres estados. Esta tabla conserva los límites exactos para que un valor situado justo en el borde no se interprete de forma incorrecta:
| Métrica | Qué evalúa | Bueno | Necesita mejorar | Deficiente |
|---|---|---|---|---|
| LCP | Aparición del elemento de contenido más grande visible. | Hasta 2,5 s, incluido. | Más de 2,5 s y hasta 4 s, incluido. | Más de 4 s. |
| INP | Respuesta visual a interacciones de clic, toque y teclado. | Hasta 200 ms, incluido. | Más de 200 ms y hasta 500 ms, incluido. | Más de 500 ms. |
| CLS | Estabilidad visual frente a desplazamientos inesperados. | Hasta 0,1, incluido. | Más de 0,1 y hasta 0,25, incluido. | Más de 0,25. |
La referencia se aplica al percentil 75, separando móvil y ordenador. Si el LCP en ese percentil es de 2,5 segundos, aproximadamente el 75 % de las experiencias registradas tiene ese valor o uno mejor. Es distinto de una media y de la mejor ejecución que hayas conseguido repetir.
La guía de Web Vitals de Google explica estos criterios. Cuando existe información suficiente para las tres métricas, la evaluación conjunta requiere que las tres estén en el rango bueno. Algunas herramientas pueden emitir una evaluación sin INP cuando faltan datos de interacción; revisa qué información está disponible antes de interpretar el resultado.
Cómo medir las Core Web Vitals sin mezclar informes
PageSpeed Insights: separar experiencia real y laboratorio
Empieza por una URL importante y analiza móvil y ordenador por separado. En PageSpeed Insights, identifica primero el bloque de experiencia real y comprueba si describe esa URL o el conjunto del origen. Un origen agrupa páginas que comparten protocolo, dominio y puerto, no solo el artículo que has introducido.
Los datos de campo proceden del informe de experiencia de usuarios de Chrome, conocido como CrUX, y representan una ventana de los últimos 28 días. Debe haber información suficiente para mostrarlos. Después encontrarás el diagnóstico de laboratorio realizado con Lighthouse en unas condiciones concretas.
Anota por separado la evaluación de campo y la puntuación de laboratorio. La nota de rendimiento de 0 a 100 puede ayudar a investigar, pero no equivale al resultado de las Core Web Vitals de usuarios reales. La documentación de PageSpeed Insights describe ambos bloques y sus diferencias.
Search Console: localizar grupos que necesitan atención
El informe de Core Web Vitals de Search Console organiza páginas similares en grupos y diferencia móviles y ordenadores. Abre un problema, revisa la métrica afectada y toma varias URL de ejemplo. Un aviso compartido puede proceder de una plantilla o de un componente que se utiliza en muchas páginas.
No presupongas que el valor del grupo coincide con el dato individual de una URL en PageSpeed. Las agrupaciones cumplen otra función y los ejemplos no son un inventario completo de todas las páginas. También conviene distinguir un problema de experiencia de uno de acceso o indexación.
La guía de SEO técnico ayuda a situar el rendimiento junto al rastreo, la indexación y las demás prioridades de la web.
Cuando faltan datos de usuarios reales
La ausencia de datos puede deberse a que no existe una muestra suficiente para la página, el origen o el dispositivo elegido. No demuestra que la web haya aprobado o suspendido. Puedes investigar con pruebas de laboratorio, revisar páginas representativas y, si el proyecto lo necesita, plantear medición propia de usuarios reales.
Para diagnosticar INP hay que probar interacciones. La auditoría de carga habitual de Lighthouse ofrece otras pistas, como el tiempo de bloqueo total o TBT, pero TBT e INP no son la misma métrica. Abrir un informe sin hacer clic en la página no reproduce lo que sucede al utilizar sus elementos.
Qué corregir según la métrica afectada
Si el problema está en LCP
Localiza el elemento que tarda en aparecer y revisa su recorrido: respuesta del servidor, descubrimiento del recurso, descarga y posibilidad de mostrarlo. Así podrás separar una imagen pesada de una imagen que empieza a descargarse demasiado tarde o de un contenido bloqueado por otros recursos.
Si el elemento es una imagen, comprueba dimensiones, formato, compresión y entrega adecuada al dispositivo. Revisa también si se ha aplicado carga diferida a esa imagen principal. La guía de optimización de LCP desaconseja retrasar con carga diferida la imagen que actúa como elemento LCP.
Eso no significa dar prioridad máxima a todas las imágenes. La decisión debe beneficiar al recurso importante y verificarse después; una configuración indiscriminada puede desdibujar esa prioridad.
Si el problema está en INP
Reproduce las acciones habituales: abrir el menú móvil, usar un filtro, desplegar información o interactuar con el formulario. Busca en qué momento se retrasa la respuesta y si coincide con tareas de JavaScript, trabajo del navegador o componentes externos.
Entre las líneas de mejora están reducir trabajo innecesario, dividir tareas largas y simplificar lo que se ejecuta al interactuar. La guía para optimizar INP organiza el diagnóstico según las fases de la interacción. En WordPress, ese análisis puede llevar a revisar una función concreta de un plugin o una integración, en lugar de desactivar herramientas por su número.
Si el problema está en CLS
Observa la página durante la carga y mientras la utilizas. Busca imágenes, vídeos, anuncios, fuentes o bloques insertados que cambien la posición del contenido. Una prueba corta puede pasar por alto un desplazamiento que aparece más tarde.
Una corrección habitual consiste en reservar el espacio de los recursos antes de que lleguen, por ejemplo con dimensiones de imagen coherentes o una relación de aspecto. Los contenidos externos también necesitan un espacio adecuado. La guía para optimizar CLS detalla estas causas y sus comprobaciones.
Cómo priorizar las mejoras en una web WordPress
Relaciona cada aviso con una página, una plantilla y una acción importante para el visitante. Un menú que responde tarde en todas las páginas de servicio merece una atención distinta de un detalle aislado de una URL poco utilizada. Combina alcance, gravedad observada, función de la página y esfuerzo de corrección.
Un orden práctico sería:
1. Elegir páginas representativas. Inicio, un servicio importante, un artículo y, si corresponde, una categoría o ficha de producto.
2. Localizar el problema compartido. Imagen principal, navegación, componente de la plantilla o servicio externo.
3. Plantear una corrección concreta. Indicar qué recurso o comportamiento se cambiará y qué métrica debería reflejarlo.
4. Probar el cambio en un entorno adecuado. Conservar una referencia del estado anterior y comprobar menús, formularios y funciones importantes.
5. Extenderlo cuando esté verificado. Si el origen es una plantilla común, comprobar varias páginas que la utilizan.
Activar a la vez todas las opciones de caché, combinación o retraso de scripts dificulta explicar qué ha ocurrido. Trabaja con cambios acotados y conserva la posibilidad de volver a la configuración anterior si una función deja de comportarse correctamente.
Un ejemplo de decisión
Imagina que varias páginas de servicio comparten una imagen principal muy grande y el LCP aparece fuera del rango bueno. Antes de cambiar de tema o de alojamiento, comprueba si esa imagen es realmente el elemento medido y cómo se solicita.
La intervención podría consistir en servir una versión adecuada y revisar su prioridad de carga. Después repetirías pruebas comparables y comprobarías que la página sigue funcionando. Si el recurso aparece antes pero el LCP apenas cambia, habría que investigar otra parte del recorrido.
Este un ejemplo hipotético, no una auditoría de una web real. Su objetivo es mostrar la relación entre evidencia, hipótesis y comprobación, sin atribuir una mejora a una acción que todavía no se ha probado.
Cómo comprobar una mejora y cuándo volver a medir
Después del cambio, repite la prueba de laboratorio en condiciones comparables y comprueba el comportamiento que intentabas corregir. Guarda URL, fecha, dispositivo, cambio realizado y resultados. Varias ejecuciones pueden ayudar a reconocer la variación habitual y evitar decidir por un único intento favorable.
Los datos de campo incorporan visitas a lo largo del tiempo. Una corrección de hoy no borra de inmediato la experiencia registrada antes del cambio. Search Console ofrece un proceso de validación con seguimiento de 28 días, descrito en su ayuda del informe Core Web Vitals. Ese seguimiento no obliga a esperar para comprobar si un menú funciona ni permite prometer una fecha de mejora SEO. Separa la verificación técnica de una supuesta mejora de posiciones.
Para relacionar los cambios con la visibilidad y las acciones relevantes del negocio, consulta cómo medir el SEO con datos y contexto.
Qué relación tienen las Core Web Vitals con el SEO
Google indica que sus sistemas de posicionamiento utilizan Core Web Vitals, pero también aclara que unos buenos resultados no garantizan las primeras posiciones. La relevancia y la utilidad del contenido siguen formando parte de la evaluación. La documentación sobre experiencia de página explica este alcance.
Para una empresa, merece la pena reducir esperas, respuestas tardías y movimientos molestos porque afectan al uso de la web. Ese trabajo debe encajar con páginas útiles, una oferta comprensible y un recorrido de contacto que funcione. Perseguir una nota perfecta puede consumir tiempo que tendría más valor corrigiendo un obstáculo real para el visitante.
Preguntas frecuentes sobre Core Web Vitals
¿Por qué obtengo resultados distintos en móvil y ordenador?
Las condiciones de uso, los dispositivos y las muestras son diferentes. Las herramientas también separan sus pruebas y datos por dispositivo. Revisa ambos resultados y prioriza según los problemas observados y el uso de las páginas importantes de tu negocio.
¿Por qué no aparece INP en algunas visitas?
Puede no haber una interacción de clic, toque o teclado que permita registrarlo. Desplazarse por la página no basta para generar esta métrica. Si un informe no muestra datos, comprueba su cobertura antes de interpretarlo como un valor bueno o malo.
¿FID sigue siendo una Core Web Vital?
FID es la métrica anterior de respuesta a la primera interacción. INP la sustituyó como Core Web Vital en 2024 y observa la capacidad de respuesta durante la visita. Si una guía antigua sigue usando FID como referencia actual, contrástala con la documentación vigente.
¿Hace falta cambiar de hosting para mejorarlas?
Solo cuando el diagnóstico indica que la respuesta o la capacidad del servidor son una causa relevante. Un traslado no resuelve por sí mismo una interacción costosa en JavaScript ni un bloque sin espacio reservado. Primero identifica qué está fallando y qué parte del sistema lo provoca.
Por dónde empezar en tu web
Elige una página importante, separa los datos de campo de la prueba de laboratorio y apunta la métrica que necesita atención. Después relaciona esa métrica con un elemento o comportamiento concreto. Esa primera ficha —URL, problema, evidencia y siguiente comprobación— permite encargar o ejecutar una mejora que se pueda evaluar.
Si necesitas ordenar los problemas de rendimiento dentro de un plan que conecte técnica, contenido y medición, puedes conocer mi servicio SEO para empresas.
Freddy Enguita
Consultor SEO y diseñador web en Madrid
Ayudo a empresas y profesionales a crear páginas web claras, rápidas y preparadas para posicionarse y generar oportunidades reales.
Trabajo directamente con cada cliente para comprender su negocio, organizar los contenidos, mejorar la experiencia de usuario y medir las acciones que realmente importan.
