Guía de Core Web Vitals: qué son y cómo mejorarlos
Abres PageSpeed Insights, pegas la dirección de tu web y aparecen tres letras en verde, naranja o rojo: LCP, INP y CLS. Alguien te ha dicho que importan para Google, pero nadie te ha explicado qué mide cada una ni por dónde se empieza a arreglar.
Aquí tienes el mapa completo. Cada dato técnico lleva su enlace a la documentación oficial de Google en la misma frase, y cuando algo es criterio mío y no de Google, lo digo.
Respuesta corta: los Core Web Vitals son tres medidas de la experiencia real de quien visita tu página: LCP (cuánto tarda en aparecer lo principal), INP (cuánto tarda en responder al tocar) y CLS (cuánto se mueve el contenido). Google recomienda LCP de 2,5 segundos o menos, INP de 200 milisegundos o menos y CLS de 0,1 o menos.
Antes de entrar en materia, este es el resumen de lo que vas a leer:
| Métrica | Pregunta que contesta | Bueno | Malo |
|---|---|---|---|
| LCP | ¿Cuánto tarda en aparecer lo principal? | 2,5 s o menos | más de 4 s |
| INP | ¿Cuánto tarda en responder cuando toco algo? | 200 ms o menos | más de 500 ms |
| CLS | ¿Se mueve la página mientras la leo? | 0,1 o menos | más de 0,25 |
Si no ves todas las columnas, desliza la tabla horizontalmente.
¿Qué son los Core Web Vitals y por qué importan para el SEO?
Los Core Web Vitals son un conjunto de métricas que miden la experiencia real de carga, interactividad y estabilidad visual de una página, según la documentación de Google Search Central. Google los recomienda para tener éxito en Search y para ofrecer una buena experiencia en general.
Importan porque miden lo que siente quien llega a tu web, no lo que ve un robot. Una página que tarda en mostrar lo principal, que no responde al pulsar o que se mueve mientras lees hace que la visita se estropee antes de empezar.
En la guía de Search Console desde cero vimos dónde aparece el informe. Hoy bajamos a qué significa cada número y qué hacer con él.
¿Qué mide cada métrica: LCP, INP y CLS?
LCP mide cuánto tarda en pintarse el elemento más grande visible de la página, normalmente una imagen grande o un bloque de texto. Es el tiempo desde que el usuario empieza a cargar la página hasta que ese elemento está en pantalla, según web.dev.
INP mide la capacidad de respuesta de la página. Una interacción es un clic, un toque o una pulsación de tecla, y la medida refleja cuánto pasa hasta que el navegador muestra el resultado visual, según la guía de INP de web.dev. La página de Core Web Vitals de web.dev explica que INP sustituyó a FID como métrica estable en 2024.
CLS mide la estabilidad visual: cuánto se desplazan los elementos de forma inesperada durante la vida de la página. Es esa sensación de ir a pulsar un enlace, que algo se cargue encima y acabar pulsando otra cosa. Los desplazamientos que ocurren en los 500 milisegundos siguientes a una interacción del usuario no cuentan, según la guía de CLS de web.dev.
¿Mejoran de verdad el posicionamiento?
Sí cuentan, pero no son el factor principal ni garantizan nada. Google dice en su página sobre experiencia de página que sus sistemas de clasificación principales usan los Core Web Vitals.
La misma página aclara tres cosas que conviene leer con calma:
- No existe una única "señal de experiencia de página": los sistemas miran una variedad de señales.
- Tener buenos resultados en el informe de Search Console o en herramientas de terceros no garantiza posicionar arriba.
- Hay más en una buena experiencia de página que las puntuaciones de Core Web Vitals.
Mi lectura, y es criterio mío: una página con contenido excelente y una métrica en naranja sigue pudiendo posicionar, y una página rapidísima con contenido flojo no se salva por eso. No dejes de escribir buenas páginas por perseguir una puntuación. Que una web sea rápida no arregla el resto del SEO: lo vimos en Astro vuela, pero eso no significa que tu SEO también.
¿Qué valores considera Google buenos?
Google considera buenos un LCP de 2,5 segundos o menos, un INP de 200 milisegundos o menos y un CLS de 0,1 o menos. Así lo recoge la documentación de Search Central.
Cada métrica tiene además un umbral de "malo". Según las guías de web.dev de LCP, INP y CLS, lo malo es un LCP por encima de 4 segundos, un INP por encima de 500 milisegundos y un CLS por encima de 0,25. Lo que queda entre medias "necesita mejorar".
| Métrica | Bueno | Necesita mejorar | Malo |
|---|---|---|---|
| LCP | 2,5 s o menos | entre 2,5 s y 4 s | más de 4 s |
| INP | 200 ms o menos | entre 200 y 500 ms | más de 500 ms |
| CLS | 0,1 o menos | entre 0,1 y 0,25 | más de 0,25 |
Si no ves todas las columnas, desliza la tabla horizontalmente.
El valor que se mide es el percentil 75 de las visitas, separando móvil y escritorio. Una página supera la evaluación de Core Web Vitals si cumple el objetivo bueno en las tres métricas a la vez, según web.dev.
¿Dónde veo mis Core Web Vitals con datos reales?
Puedes verlos en el informe de Core Web Vitals de Search Console y en PageSpeed Insights, y los dos usan datos de usuarios reales cuando hay suficientes. Conviene mirar primero los datos reales y después los de laboratorio.
El informe de Search Console agrupa las URL por estado (malo, necesita mejorar, bueno), por tipo de métrica y por grupo de páginas similares, según la ayuda oficial del informe. El estado de un grupo es el de su métrica peor: si el CLS es malo y el INP es bueno, el grupo figura como malo.
Si en tu propiedad pone "No hay datos disponibles", no es un fallo de tu web. La misma ayuda explica que puede ser una propiedad nueva o que el informe de experiencia de usuarios de Chrome (CrUX) no tenga datos suficientes para ese dispositivo. En ese caso, el informe omite las URL sin un mínimo de datos.
PageSpeed Insights separa dos tipos de datos, según su documentación oficial:
- Los datos de campo salen de usuarios reales de Chrome durante los 28 días anteriores. Si una página no tiene datos suficientes, PageSpeed Insights muestra los de todo el origen.
- Los datos de laboratorio los genera Lighthouse simulando la carga. Sirven para depurar, pero pueden no reflejar lo que vive el usuario real.
La recomendación de web.dev es ir primero a los datos reales y, si Lighthouse y CrUX no coinciden, fiarse de CrUX. Para entender de dónde sale ese dato público, mira cómo Chrome convierte la carga publicitaria en un dato público, que usa la misma fuente.
¿Cómo mejoro el LCP?
Para mejorar el LCP hay que optimizar el proceso entero de carga, no un solo paso: web.dev avisa de que rara vez una corrección única consigue una mejora importante. El primer paso es saber qué elemento es tu LCP.
Con PageSpeed Insights o las herramientas de desarrollo de Chrome puedes ver cuál es el elemento LCP de cada página. A partir de ahí, web.dev propone dividir el LCP en cuatro partes y reducir cada una, según su guía de optimización de LCP:
| Parte del LCP | Porcentaje ideal |
|---|---|
| Tiempo hasta el primer byte (TTFB) | cerca del 40 % |
| Retraso en empezar a cargar el recurso | menos del 10 % |
| Duración de la carga del recurso | cerca del 40 % |
| Retraso en pintar el elemento | menos del 10 % |
Si no ves todas las columnas, desliza la tabla horizontalmente.
Estos porcentajes sirven para comparar las partes entre sí, no para convertirlos en segundos. La propia guía lo advierte.
Servidor lento, redirecciones y distancia
Un TTFB alto puede deberse a varias redirecciones del servidor, a visitantes lejos del servidor más cercano, a mala red o a no poder usar contenido en caché por los parámetros de la URL, según la misma guía. Un TTFB muy alto puede hacer difícil o imposible llegar a 2,5 segundos.
Mi criterio, no una cita de Google: un hosting de calidad y una red de distribución de contenidos (CDN) acercan el contenido al visitante y suelen ser la primera revisión cuando el TTFB es el problema.
La imagen principal: descubrible, con prioridad y sin lazy load
La guía de web.dev dice que el recurso LCP debe poder descubrirse en el HTML inicial. Si solo se referencia desde un archivo CSS o JavaScript, conviene precargarlo con prioridad alta, y si es una imagen puedes indicarlo con el atributo fetchpriority.
El aviso más claro de esa guía: nunca cargues con lazy load la imagen LCP, porque provoca un retraso innecesario y perjudica el LCP. Si tu imagen principal lleva loading="lazy", quítalo.
Imágenes más ligeras, pero mide el efecto
Reducir el peso de la imagen con más compresión o con un formato mejor, como AVIF o WebP, acorta la duración de la carga. Según web.dev, eso no siempre mejora el LCP, porque el tiempo ahorrado puede pasar al retraso en pintar el elemento. Por eso se optimizan las cuatro partes y no solo una.
¿Cómo mejoro el INP?
Para mejorar el INP hay que reducir el trabajo que bloquea el hilo principal del navegador, para que la página responda antes a cada toque. web.dev divide cada interacción en tres partes y propone actuar sobre cada una.
Según la guía de INP, las tres partes son el retraso de entrada (hasta que empiezan a ejecutarse las funciones del evento), la duración del procesamiento (lo que tardan en terminar) y el retraso de presentación (hasta que el navegador pinta el siguiente fotograma con el resultado).
Tareas largas y scripts
Una tarea larga es cualquiera que dura más de 50 milisegundos, según la guía de tareas largas de web.dev. Mientras el navegador la procesa, no puede atender otras interacciones.
La evaluación de scripts es una causa frecuente durante la carga: tras descargar un archivo JavaScript, el navegador todavía tiene que analizarlo, compilarlo y ejecutarlo. Mi criterio, no de Google: revisa qué scripts y plugins sigues cargando sin necesidad y quita los que no uses.
Partir el trabajo para ceder el paso
La técnica que propone web.dev se llama ceder al hilo principal: dividir el trabajo en tareas más pequeñas para que el navegador pueda atender antes lo que pide el usuario. Puedes hacerlo con setTimeout o con scheduler.yield, según la guía de tareas largas.
También recomienda hacer primero solo lo necesario para pintar el cambio visual y dejar el resto para una tarea posterior. Con ello las funciones de evento son más ligeras y el navegador pinta antes.
Un DOM más pequeño
Cuando el DOM es muy grande, el trabajo de renderizado crece con él, según la guía de INP. Reducir su tamaño ayuda al retraso de presentación, aunque la propia guía admite que a veces no se puede reducir mucho.
¿Cómo evito los saltos de diseño (CLS)?
Para evitar los saltos de diseño hay que reservar el espacio de todo lo que carga más tarde que el texto: imágenes, vídeos, anuncios, embeds y fuentes. Si el navegador sabe cuánto sitio ocupa cada cosa antes de que llegue, no mueve nada.
Imágenes y vídeos con dimensiones
web.dev recomienda incluir siempre los atributos width y height en imágenes y vídeos, o reservar el espacio con la propiedad CSS aspect-ratio, según su guía de optimización de CLS. Con las imágenes responsive, todas las que ofrezcas en srcset deben tener la misma proporción.
Anuncios, embeds y contenido que llega tarde
Los vídeos de YouTube, los mapas o las publicaciones de redes sociales suelen no reservar espacio hasta que cargan. La guía propone reservar el espacio con min-height o, en contenido responsive, con aspect-ratio.
Con los anuncios no siempre puedes saber el tamaño exacto. La guía sugiere elegir el tamaño más probable según datos históricos o iniciar con el tamaño más pequeño que se vaya a servir, y evitar colapsar el hueco reservado si no llega ningún anuncio, porque quitar el espacio provoca tanto CLS como insertar contenido.
Tipografías web
Cambiar de la fuente de reserva a la fuente web puede provocar saltos de diseño cuando las dos ocupan un espacio distinto, según la guía de buenas prácticas de fuentes de web.dev. Entregar la fuente antes ayuda a eliminar esos saltos.
La misma guía avisa de que precargar fuentes tiene un coste: quita recursos del navegador a otras cargas. Úsalo con criterio y solo con las fuentes más importantes.
Un ejemplo inventado
Este es un ejemplo inventado, no es una web real. Una tienda ficticia tiene una ficha de producto con un banner de oferta que se carga un segundo después del texto. El banner empuja la descripción hacia abajo justo cuando el visitante iba a pulsar "Añadir a la cesta", y el CLS sale rojo. Se arregla reservando la altura del banner con min-height, sin tocar nada más.
¿Cuál es el orden de trabajo recomendado?
El orden recomendado es medir con datos reales, priorizar por impacto y esfuerzo, corregir una métrica cada vez y revisar el resultado con el tiempo. Un informe lleno de rojos no es una lista de tareas: es una lista de preguntas.
- Mide con datos reales en el informe de Search Console y en PageSpeed Insights, y anota qué métrica y qué grupo de páginas fallan.
- Identifica la causa en las plantillas que más tráfico reciben: en el LCP, qué elemento es; en el INP, qué interacción es lenta; en el CLS, qué elemento se mueve.
- Prioriza cada acción por impacto y esfuerzo. Empieza por lo que ayude a más páginas con menos trabajo.
- Corrige una métrica cada vez y vuelve a medir. Los datos de campo de PageSpeed Insights se calculan sobre los 28 días anteriores, así que el cambio tarda en verse.
- Revisa el informe cada mes y vigila las plantillas nuevas antes de publicar.
Para ordenar este trabajo he preparado una plantilla de lectura de Core Web Vitals: una tabla por página con el valor de cada métrica, su color, si los datos son de usuarios reales, la causa probable, la acción y el esfuerzo. Es una herramienta propia, no una recomendación de Google. Descarga la Guía práctica de Core Web Vitals (te la enviamos por email).
Preguntas frecuentes sobre Core Web Vitals
¿Son los Core Web Vitals un factor de posicionamiento?
Sí, Google dice que sus sistemas de clasificación principales usan los Core Web Vitals. Pero no hay una única señal de experiencia de página, y buenos resultados no garantizan posicionar arriba, según la página de experiencia de página de Google.
¿Cuánto tardan en actualizarse los datos?
Los datos de campo de PageSpeed Insights cubren los 28 días anteriores, por lo que una mejora tarda semanas en reflejarse por completo, según su documentación. Para ver un cambio concreto antes, puedes usar los datos de laboratorio de Lighthouse.
¿Qué hago si mi web no aparece en el informe de Search Console?
Si el informe dice "No hay datos disponibles", la web es nueva o CrUX no tiene datos suficientes del dispositivo elegido, según la ayuda de Search Console. Las URL sin un mínimo de datos se omiten. Mientras tanto, usa PageSpeed Insights y sus datos de laboratorio.
¿Hay que medir en móvil o en escritorio?
En los dos. El informe de Search Console separa móvil y escritorio, y web.dev recomienda medir el percentil 75 segmentando entre ambos dispositivos, según su guía de Web Vitals.
¿Hace falta ser desarrollador para mejorarlos?
No para todo. Entender el informe, comprimir imágenes, quitar scripts que no usas y reservar espacio de banners está al alcance de quien gestiona la web. Dividir tareas largas en JavaScript o precargar el recurso LCP suelen requerir a un desarrollador. Esta es una opinión mía, no de Google.
Revisado el 12 de octubre de 2026 contra la documentación oficial de Google (Search Central, web.dev, PageSpeed Insights y la ayuda de Search Console) por Alejandro Castillo Cantón.
