Las Core Web Vitals son un conjunto de métricas que Google introdujo en 2020 y que se convirtieron en factor de posicionamiento oficial en 2021 con la Page Experience Update. Miden tres dimensiones fundamentales de la experiencia de usuario: lo rápido que carga el contenido principal de la página, lo rápido que responde a las interacciones y lo estable que se mantiene el diseño durante la carga. Si tu web obtiene malas puntuaciones en estas métricas, Google la penaliza en las SERP frente a webs con contenido similar pero mejor rendimiento. En esta guía encontrarás todo lo que necesitas para entender, medir y optimizar las Core Web Vitals, con valores objetivo precisos, herramientas gratuitas y técnicas concretas que puedes aplicar incluso sin un desarrollador.
Fuentes: Google, web.dev/vitals
| Métrica | Bueno | Mejorable | Malo |
|---|---|---|---|
| LCP (carga) | ≤ 2,5 s | 2,5–4 s | > 4 s |
| INP (capacidad de respuesta) | ≤ 200 ms | 200–500 ms | > 500 ms |
| CLS (estabilidad visual) | ≤ 0,1 | 0,1–0,25 | > 0,25 |
Valores en el percentil 75 de las visitas reales. Fuente: Google, web.dev/vitals
Qué son las Core Web Vitals y por qué Google las usa para el posicionamiento
Las Core Web Vitals son una parte de la experiencia de página: Google no usa una única «señal de page experience», sino que sus sistemas de posicionamiento tienen en cuenta varios aspectos de la experiencia, entre ellos HTTPS, la ausencia de intersticiales intrusivos y la adaptación a móviles. Sin embargo, las tres métricas principales — LCP, INP y CLS — son las que más peso tienen en el posicionamiento. Google las recoge a partir de los datos reales de los usuarios de Chrome (el Chrome User Experience Report, abreviado CrUX) y las compara con los datos de laboratorio de las pruebas de PageSpeed. Esto significa que no basta con una buena puntuación de PageSpeed en laboratorio: lo que cuenta es la experiencia de tus visitantes reales, con sus conexiones, sus dispositivos y sus condiciones de uso. Una web que carga en 1,2 segundos en la prueba de laboratorio pero sirve imágenes sin optimizar en redes móviles puede tener tranquilamente un LCP de 4-5 segundos en el uso real. Para acceder a los datos de CrUX de tu web, tu dominio debe recibir suficiente tráfico para entrar en el conjunto de datos: si la web es nueva o tiene muy pocas visitas, Google Search Console mostrará el mensaje "datos insuficientes" y tendrás que basarte únicamente en los datos de laboratorio hasta que crezca el tráfico.
El mecanismo por el que las Core Web Vitals influyen en el posicionamiento no es tan sencillo como una puntuación numérica. Google aplica un sistema de umbrales: cada métrica tiene tres zonas — Buena (verde), Necesita mejorar (naranja) y Mala (rojo). Una página supera la evaluación de las Core Web Vitals (la que muestran Search Console y PageSpeed Insights) cuando el percentil 75 de las sesiones reales está en la zona verde en las tres métricas. El percentil 75 significa que el 75% de las sesiones debe estar por debajo del umbral verde: no la media, no la mediana. Esto es importante porque la media puede verse distorsionada por un pequeño número de sesiones muy rápidas, mientras que el percentil 75 garantiza que también los usuarios en peores condiciones tengan una experiencia aceptable. Si una sola de las tres métricas está en rojo para el 25% de los usuarios, toda la señal de Page Experience resulta negativa.
LCP — Largest Contentful Paint: velocidad de carga percibida
El LCP mide el tiempo necesario para que el elemento visual más grande visible en el viewport se renderice por completo. En la mayoría de los casos se trata de la imagen hero, el banner principal o el primer bloque grande de texto en la parte visible. El objetivo de Google es claro: por debajo de 2,5 segundos es bueno, entre 2,5 y 4 segundos necesita mejorar, por encima de 4 segundos es malo. El LCP depende de cuatro factores principales que se suman: el tiempo de respuesta del servidor (TTFB), el tiempo de bloqueo del renderizado por CSS y JavaScript, el tiempo de descarga del recurso principal y el tiempo de renderizado en el navegador. Optimizar el LCP significa actuar sobre los cuatro factores de forma coordinada: no basta con comprimir las imágenes si el servidor tarda 800 ms en responder.
Las causas más habituales de un LCP lento son imágenes hero sin optimizar, fuentes web que bloquean el renderizado, CSS y JavaScript críticos sin optimizar y un hosting lento. Para las imágenes, la solución más eficaz es usar el formato WebP o AVIF con el tamaño adecuado para cada breakpoint, combinado con el atributo loading="eager" y fetchpriority="high" en el elemento que será el LCP. Muchos desarrolladores cometen el error de aplicar loading="lazy" a todas las imágenes, incluida la hero: esto retrasa aún más la carga del elemento LCP, porque el navegador no empieza la descarga hasta que la imagen está cerca del viewport. Otra optimización fundamental es el preload: añadir <link rel="preload" as="image"> en el <head> indica al navegador que descargue la imagen LCP de inmediato, incluso antes de haber analizado todo el DOM. Para las fuentes, usar font-display: swap o font-display: optional evita el bloqueo del renderizado. font-display: optional es la opción más agresiva: si la fuente no está disponible en unos 100 ms, el navegador usa la alternativa y ya no cambia; elimina por completo el destello de texto invisible (FOIT), pero puede dar lugar a fuentes incoherentes entre páginas.
Bueno: ≤ 2,5 segundos — señal positiva para el posicionamiento
Necesita mejorar: entre 2,5 s y 4 s — neutro, conviene optimizar
Malo: > 4 segundos — señal negativa, prioridad alta
El valor se mide en el percentil 75 de las sesiones reales de los usuarios.
INP — Interaction to Next Paint: capacidad de respuesta a las interacciones
El INP (Interaction to Next Paint) sustituyó al FID (First Input Delay) como métrica de interactividad en marzo de 2024. Mientras que el FID solo medía el retraso de la primera entrada, el INP mide la latencia de todas las interacciones del usuario con la página — clics, toques y pulsaciones de teclas — y devuelve el percentil 98 de esas latencias como puntuación final. En la práctica, mide lo receptiva que es tu web cuando el usuario interactúa activamente con ella. Los objetivos son: por debajo de 200 ms es bueno, entre 200 ms y 500 ms necesita mejorar, por encima de 500 ms es malo. El INP es especialmente problemático en webs con mucho JavaScript: cada evento de clic debe esperar a que el hilo principal del navegador esté libre antes de procesarse. Si hay scripts pesados ejecutándose en segundo plano, un clic en un botón puede parecer "bloqueado" durante medio segundo o más, aunque técnicamente el navegador haya registrado el evento.
Las causas más habituales de un INP elevado son las tareas largas de JavaScript (tareas que bloquean el hilo principal durante más de 50 ms), los event listeners pesados, los reflujos masivos provocados por lecturas y escrituras alternas del DOM y las librerías de terceros sin optimizar, como widgets de chat, analíticas pesadas y A/B testing. Para mejorar el INP hay que dividir las tareas largas en fragmentos más pequeños con scheduler.yield() o setTimeout, trasladar la lógica pesada a Web Workers (hilos separados que no bloquean el hilo de la interfaz) y reducir o aplazar la carga de scripts de terceros. Google recomienda usar el panel Performance Insights de Chrome DevTools para identificar las tareas largas: cada barra roja del flame chart indica una tarea que supera los 50 ms. El enfoque más eficaz es perfilar la aplicación durante una interacción real — por ejemplo, registrar lo que ocurre cuando el usuario hace clic en el menú de navegación o en un botón de añadir al carrito — y luego optimizar las tareas más largas una a una.
CLS — Cumulative Layout Shift: estabilidad visual de la página
El CLS mide cuánto se desplaza el diseño de la página de forma inesperada durante la carga y el uso. Cada vez que un elemento se mueve sin que el usuario haya hecho nada, contribuye a la puntuación de CLS. La puntuación es un valor adimensional calculado como la fracción del área afectada multiplicada por la distancia de desplazamiento. Un CLS de 0,1 o menos se considera bueno, entre 0,1 y 0,25 necesita mejorar, por encima de 0,25 es malo. El caso clásico de CLS elevado es el botón en el que estás a punto de hacer clic y que se desplaza porque encima aparece un banner publicitario o una imagen que termina de cargarse. Es especialmente frustrante en móvil y puede llevar al usuario a pulsar sin querer enlaces equivocados.
Las causas más habituales de CLS son las imágenes sin dimensiones explícitas (el navegador no sabe cuánto espacio reservar hasta que la imagen se ha cargado), los anuncios de tamaño variable, las fuentes web que sustituyen a la alternativa y cambian el tamaño del texto, y los contenidos insertados dinámicamente por JavaScript encima de contenido existente. La solución principal para las imágenes es indicar siempre los atributos width y height en la etiqueta HTML: así el navegador puede calcular de antemano la relación de aspecto y reservar el espacio correcto. Para los anuncios, usa contenedores con dimensiones mínimas fijas. Para las fuentes, usa size-adjust y ascent-override en las declaraciones @font-face para reducir el desplazamiento causado por el cambio de fuente. Otra técnica eficaz es el skeleton loading: mostrar marcadores grises del mismo tamaño que el contenido que está por llegar reduce drásticamente el CLS, porque el espacio ya está reservado en el diseño.
- Basados en usuarios reales de Chrome
- Reflejan condiciones reales de red y dispositivo
- Disponibles en Search Console y PageSpeed
- Actualizados cada 28 días de forma continua
- Usados por Google para el posicionamiento real
- Entorno controlado y reproducible
- Disponibles inmediatamente después de cada cambio
- Útiles para depuración y desarrollo local
- No se usan directamente para el posicionamiento
- Pueden diferir mucho de los datos reales
Herramientas para medir las Core Web Vitals
Google PageSpeed Insights es el punto de partida: introduces la URL y obtienes tanto los datos de campo (si están disponibles en CrUX) como los datos de laboratorio de Lighthouse. La sección más importante es la de los datos de campo, porque muestra los valores reales en el percentil 75 para LCP, INP y CLS. La sección de laboratorio es útil para depurar, pero no refleja necesariamente lo que ve Google. Para una vista agregada de todas las páginas de la web, usa Google Search Console: el informe "Experiencia en la página" muestra cuántas URL de tu web están en verde, naranja y rojo para cada métrica, con la posibilidad de ver los detalles por grupos de URL similares. Es la herramienta más importante porque usa los mismos datos que Google utiliza para el posicionamiento. La tercera herramienta fundamental es Chrome DevTools: el panel Performance te permite grabar y analizar exactamente lo que ocurre durante la carga y las interacciones, identificando tareas largas, recursos bloqueantes y desplazamientos del diseño con precisión quirúrgica.
Para un seguimiento continuo, plantéate instalar la librería JavaScript web-vitals de Google directamente en tu web: recoge las métricas de los usuarios reales y las envía a tu sistema de analítica, para que puedas ver los valores reales segmentados por página, dispositivo y tipo de conexión. Es mucho más útil que hacer una prueba de PageSpeed una vez al mes: te permite detectar regresiones justo después de una actualización de la web y entender qué páginas tienen problemas que no aparecen en las pruebas de laboratorio. Herramientas como Vercel Speed Insights, Sentry Performance y Datadog RUM ya ofrecen esta función integrada si usas esas plataformas.
Cómo optimizar el LCP: técnicas prácticas para desarrolladores y no desarrolladores
Convierte a WebP o AVIF, redimensiona al tamaño real de visualización, añade fetchpriority="high", elimina loading="lazy" si está presente y añade el preload en el <head>. Ahorro típico: 0,5–1,5 segundos de LCP.
Usa una CDN para servir el contenido estático desde el punto geográficamente más cercano al usuario. Activa HTTP/2 y la compresión Brotli. Si usas WordPress, instala un plugin de caché como WP Rocket o W3 Total Cache. Ahorro típico: 0,2–0,8 segundos de TTFB.
Añade defer o async a todos los scripts no críticos. Extrae el CSS crítico (above-the-fold) e insértalo en línea en el <head>, cargando el resto del CSS de forma asíncrona. Herramientas como Critical o Penthouse automatizan esta tarea. Ahorro típico: 0,3–1,0 segundos.
Usa font-display: swap en las declaraciones @font-face. Precarga las fuentes críticas con <link rel="preload" as="font">. Plantéate usar fuentes del sistema como alternativa principal si la diferencia visual es mínima. Ahorro típico: 0,1–0,5 segundos.
Errores habituales que arruinan las Core Web Vitals
loading="lazy" a la imagen principal de la página es uno de los errores más frecuentes y dañinos. El navegador retrasa la descarga de la imagen hasta que está cerca del viewport, pero la imagen hero YA está en el viewport al cargar. Resultado: el LCP empeora notablemente. La imagen hero siempre debe tener loading="eager" (o ningún atributo loading) y fetchpriority="high".<script> normal bloquean el análisis del DOM. Cada kilobyte de JavaScript síncrono en el <head> retrasa tanto el LCP como el INP. Usa siempre defer o async para los scripts no críticos y plantéate aplazarlos aún más con un retardo de 3-5 segundos después del evento load para los scripts no esenciales, como los chats.Core Web Vitals en webs WordPress
WordPress es la plataforma más usada del mundo y también la que tiene los problemas de rendimiento más extendidos, a menudo causados por temas pesados, plugins mal optimizados y un hosting inadecuado. El problema principal es que WordPress, por defecto, carga decenas de scripts y estilos incluso cuando no son necesarios para la página que se está viendo: cada plugin añade sus recursos de forma indiscriminada. La primera optimización es desactivar la carga de recursos no utilizados: plugins como Asset CleanUp o Perfmatters permiten desactivar selectivamente scripts y estilos en páginas concretas. La segunda prioridad es la caché: un plugin como WP Rocket o LiteSpeed Cache (si tu hosting usa servidor LiteSpeed) reduce drásticamente los tiempos de respuesta del servidor generando versiones HTML estáticas de las páginas dinámicas. Para las imágenes, los plugins Imagify o ShortPixel convierten automáticamente a WebP y comprimen las imágenes al subirlas. Por último, plantéate un hosting gestionado para WordPress como Kinsta, WP Engine o Cloudways: cuestan más que un hosting compartido, pero ya incluyen CDN, caché avanzada y servidores optimizados para PHP, y a menudo marcan la diferencia entre un LCP de 4 segundos y uno de 1,8 segundos.
El impacto de las Core Web Vitals en el posicionamiento: ¿cuánto cuentan de verdad?
Desde que Google confirmó las Core Web Vitals como factor de posicionamiento, muchos SEO se han preguntado cuánto pesan realmente frente a otras señales. La respuesta sincera es: menos que la relevancia del contenido y los backlinks, pero lo suficiente para marcar la diferencia en mercados competitivos. Google ha declarado que las Core Web Vitals son un criterio de desempate: con el mismo contenido y la misma autoridad, la web con mejor rendimiento tiene ventaja. En la práctica, si tu web suspende en las tres CWV y tus principales competidores están en verde, estás dejando posiciones sobre la mesa. Al contrario, optimizar las CWV no hará milagros si tu contenido no responde a la intención de búsqueda del usuario o si no tienes enlaces con autoridad. La estrategia correcta es tratar las Core Web Vitals como un requisito previo de calidad: deben estar en verde para no penalizarte, y después el posicionamiento lo construyes con contenidos y link building. Los estudios de correlación muestran que las webs en las primeras posiciones tienden a tener mejores CWV que las que están más abajo, pero la causalidad no es fácil de aislar. Lo que sí es seguro es que una mejor experiencia de usuario se traduce en más tiempo en la web, menos rebotes y más conversiones: beneficios que van mucho más allá del factor de posicionamiento.
Optimizar las Core Web Vitals requiere un análisis técnico preciso e intervenciones específicas: no existe una receta universal, cada web tiene sus puntos críticos. Si quieres un análisis profesional del rendimiento de tu web con un plan de acción concreto, descubre el servicio SEO o contáctame directamente para una consultoría.
Si quieres aplicarlo a tu proyecto, echa un vistazo a mi servicio de consultoría SEO y visibilidad: precios claros desde 200 €/mes, presupuesto gratuito y respuesta en 24 horas.
