Las Core Web Vitals son las tres métricas con las que Google mide la experiencia real de carga de una página: LCP (lo que tarda en verse el contenido principal), INP (lo que tarda en responder cuando interactúas) y CLS (cuánto se mueve la página mientras carga). Google publica umbrales concretos para cada una y las usa como parte de las señales de experiencia de página. Esta guía de nuestra serie de formación SEO explica qué mide cada métrica, cómo leerla sin confundir datos de laboratorio con datos reales y cómo mejorarla, con el caso de nuestra propia web y los números que no salieron como esperábamos.
Lo esencial
- Umbrales de «bueno» según Google: LCP por debajo de 2,5 segundos, INP por debajo de 200 milisegundos y CLS por debajo de 0,1.
- INP sustituyó a FID como métrica de respuesta el 12 de marzo de 2024. Si una guía todavía te habla de FID, está desactualizada.
- Se evalúan con datos de usuarios reales en el percentil 75: el 75 % de las visitas tiene que cumplir el umbral.
- Tener las tres en verde no te sube al primer puesto. Tenerlas en rojo sí puede frenar a una página que compite con otras de calidad parecida.
- Las cifras de laboratorio son estimaciones. Mídelas varias veces y en frío antes de decidir nada.
¿Qué son las Core Web Vitals y qué mide cada una?
Son tres métricas centradas en lo que percibe una persona, no en lo que mide un servidor. Google las describe en su documentación de Core Web Vitals como el rendimiento de carga, la capacidad de respuesta y la estabilidad visual de una página.
Fuente: documentación de Google Search Central y web.dev, consultadas el 30/09/2026.
El cambio de FID a INP no fue cosmético. FID solo medía el retraso de la primera interacción; INP mide todas las interacciones de la visita y se queda con la peor. Muchas webs que aprobaban con FID suspenden con INP porque el problema aparece al abrir un menú o un filtro, no en el primer clic. Google lo anunció en web.dev el 12 de marzo de 2024.
¿Las Core Web Vitals afectan al posicionamiento?
Sí, pero como una señal más y no como un atajo. Google dice que recomienda encarecidamente tener buenas Core Web Vitals para tener éxito en la búsqueda y que se alinean con lo que sus sistemas de clasificación quieren premiar. No dice en ningún sitio que tenerlas en verde te suba de posición por sí solo.
La forma honesta de verlo es esta: la relevancia y la calidad del contenido deciden casi todo, y la experiencia de página pesa cuando dos resultados están parejos. Nuestra propia web es la prueba. En junio de 2026 tenía el bloque técnico en 88 sobre 100 y las métricas de escritorio impecables, y aun así no posicionaba ni una sola búsqueda: le faltaba contenido. Optimizar la velocidad de una web vacía es pulir el escaparate de una tienda sin producto.
¿Datos de laboratorio o datos de campo?
Los de campo son los que cuentan para Google; los de laboratorio sirven para diagnosticar. Los datos de campo salen de usuarios reales de Chrome que navegan por tu web y se recogen en el informe CrUX (Chrome User Experience Report). Los de laboratorio los genera una herramienta como Lighthouse simulando una carga en un dispositivo y una conexión concretos.
La trampa habitual es optimizar para el laboratorio. Lighthouse puede darte un LCP de 3,4 segundos mientras tus usuarios reales ven 2 segundos, o al revés, porque tus visitas tienen móviles y conexiones distintas a las de la simulación. Y hay un problema que afecta a casi todas las pymes: si tu web tiene poco tráfico, Google no tiene suficientes datos de campo y PageSpeed Insights te lo dice con un aviso. En ese caso solo tienes el laboratorio, y hay que leerlo con prudencia.
¿Cómo se miden paso a paso?
- Search Console, informe de Core Web Vitals. Agrupa tus URLs por estado con datos de campo. Es el punto de partida porque te dice qué grupo de páginas falla, no una sola URL.
- PageSpeed Insights, URL por URL. Arriba enseña los datos de campo si los hay; abajo, el diagnóstico de laboratorio con las oportunidades concretas.
- Repite la medición. Al menos tres veces, y descarta la primera si la caché estaba fría. Una sola lectura no es un dato.
- Chrome DevTools, pestaña Performance. Para encontrar qué elemento es el LCP, qué script bloquea la interacción o qué bloque se desplaza.
- Anota fecha, herramienta y dispositivo. Sin eso no podrás comparar el antes y el después.
Si quieres ver cómo encaja esto con el resto de revisiones técnicas, lo explicamos en la guía de SEO técnico, los datos estructurados son la otra pieza técnica que más revisamos, y las herramientas que usamos a diario están en herramientas SEO.
Caso real: las Core Web Vitals de kuasar.es
Nuestra home en escritorio va sobrada; en móvil, el LCP sigue fuera del umbral y ya sabemos por qué. Estas son las mediciones de nuestras auditorías técnicas de 2026, todas de laboratorio porque el tráfico todavía no da datos de campo suficientes.
Fuente: Lighthouse vía DataForSEO y auditoría de Ubersuggest, mediciones sin caché, auditorías técnicas internas de julio, agosto y septiembre de 2026.
Tres cosas que aprendimos. La primera: el CLS se debía a un solo desplazamiento. El bloque de botones de la cabecera de la home se movía cuando cargaba la imagen principal, que llegaba con carga diferida y sin espacio reservado, y cuando entraban las dos fuentes web. Una sola corrección en una sola plantilla resuelve casi todo el problema.
La segunda: las herramientas estimaban que la doble redirección de http://www a https:// costaba 630 milisegundos en móvil. Al medirla nosotros, con y sin caché, el sobrecoste real estaba entre 230 y 330 milisegundos. Sigue mereciendo corregirse, pero no era el cuello de botella que sugería la cifra.
La tercera: una de las mediciones dio 4,16 segundos de LCP. Al repetirla dos veces más bajó al rango de 3,4: la primera lectura era un arranque en frío del servidor. Si la hubiéramos reportado tal cual, habríamos declarado un empeoramiento que no existía.
¿Cómo se mejora el LCP?
Haciendo que el elemento principal llegue antes y pese menos. Casi siempre es una imagen de cabecera, y casi siempre el problema está en uno de estos puntos:
- La imagen principal pesa demasiado. Pásala a WebP o AVIF y ajústala al tamaño real en que se muestra.
- La imagen principal tiene carga diferida. Lo que se ve nada más entrar nunca debe llevar
loading=«lazy»; al contrario, conviene precargarla. - El servidor tarda en responder. Una caché de página y un buen alojamiento bajan el tiempo hasta el primer byte.
- Hay redirecciones encadenadas antes de llegar a la página. Cada salto suma tiempo antes de empezar a cargar nada.
¿Cómo se mejora el INP?
Quitando trabajo al hilo principal del navegador cuando el usuario interactúa. Los culpables habituales son scripts de terceros (chats, píxeles de publicidad, mapas de calor), maquetadores que cargan todo su código en todas las páginas y funciones que hacen demasiado de golpe tras un clic. Revisa qué scripts cargas y en qué páginas: muchas webs arrastran herramientas que nadie usa desde hace años.
¿Cómo se mejora el CLS?
Reservando el espacio de todo lo que llega tarde. Imágenes y vídeos con ancho y alto declarados o con aspect-ratio, huecos fijos para banners y anuncios, y fuentes web con font-display: swap y tamaños de reserva parecidos para que el texto no salte al cambiar de tipografía. Es la métrica que más rápido se arregla cuando localizas el elemento que se mueve.
¿Y si mi web está hecha con WordPress?
WordPress no es lento por sí mismo; lo son los temas pesados, los maquetadores y el exceso de plugins. Un plugin de optimización ayuda mucho, pero también puede servir versiones antiguas en caché o aplicar carga diferida a la imagen principal, que es justo lo que empeora el LCP. Después de cada cambio, purga la caché y vuelve a medir. Lo explicamos a fondo en la guía de SEO en WordPress, y el trabajo recurrente que evita que la velocidad se degrade con el tiempo está en mantenimiento WordPress.
Preguntas frecuentes
¿Cuáles son los umbrales buenos de las Core Web Vitals?
LCP por debajo de 2,5 segundos, INP por debajo de 200 milisegundos y CLS por debajo de 0,1. Se evalúan en el percentil 75 de las visitas reales, así que tres de cada cuatro visitas tienen que cumplirlos.
¿Qué pasó con el FID?
Dejó de ser una Core Web Vital el 12 de marzo de 2024, cuando lo sustituyó el INP. El INP mide todas las interacciones de la visita y no solo la primera, por eso es más exigente.
¿Por qué PageSpeed Insights me da una nota distinta cada vez?
Porque la parte de laboratorio es una simulación que varía con la carga del servidor, la caché y la red en el momento de medir. Repite la medición varias veces y fíjate en la tendencia, no en una sola cifra.
¿Tener las Core Web Vitals en verde me sube en Google?
No por sí solo. Son una señal de experiencia de página que pesa cuando varios resultados son parecidos en relevancia y calidad. Sin contenido que responda a la búsqueda, una web rapidísima sigue sin posicionar: la velocidad es una parte del pilar técnico del posicionamiento web, no el atajo.
¿Mi web tiene poco tráfico y no aparecen datos de campo, qué hago?
Trabaja con los datos de laboratorio, pero mide varias veces y en frío, y céntrate en las plantillas que más se repiten. Cuando el tráfico crezca, Search Console empezará a mostrar el informe con datos reales.