Core Web Vitals: Qué Son y Cómo Mejorarlas para el SEO de Tu Web

Agencia de SEO · Málaga · Actualizado septiembre 2026

Qué son las Core Web Vitals y por qué importan para el SEO

Las Core Web Vitals son un conjunto de métricas que Google utiliza para evaluar la experiencia de usuario real de una página web. Desde su introducción como factor de ranking en junio de 2021, estas métricas han pasado de ser una curiosidad técnica a convertirse en un elemento imprescindible de cualquier auditoría SEO seria.

Google mide tres aspectos fundamentales de la experiencia de usuario: la velocidad de carga del contenido principal (LCP), la capacidad de respuesta ante las interacciones del usuario (INP) y la estabilidad visual del diseño mientras se carga la página (CLS). Cada métrica tiene umbrales claros que clasifican tu web como «buena», «necesita mejorar» o «deficiente».

¿Por qué Google les da tanta importancia? Porque el buscador quiere enviar a sus usuarios a páginas que funcionen bien. Un estudio de Google reveló que las páginas que cumplen los umbrales de Core Web Vitals tienen un 24% menos de probabilidad de abandono por parte del usuario. En mercados competidos donde varias webs tienen contenido similar y perfiles de enlaces parecidos, las Core Web Vitals pueden ser el desempate que determine quién aparece primero.

Además, estas métricas se basan en datos reales de usuarios (CrUX, Chrome User Experience Report), no en pruebas de laboratorio. Esto significa que Google evalúa cómo se comporta tu web con visitantes reales, con conexiones reales y en dispositivos reales, no en condiciones ideales de un test.

Las tres métricas: LCP, INP y CLS

En septiembre de 2026, las tres Core Web Vitals vigentes son LCP, INP y CLS. Es importante señalar que en marzo de 2024, INP sustituyó oficialmente a FID (First Input Delay), ampliando la medición de interactividad a toda la sesión de navegación, no solo a la primera interacción.

Para que Google considere que tu web «aprueba» las Core Web Vitals, necesitas que al menos el 75% de las visitas de una URL alcancen el umbral «bueno» en las tres métricas simultáneamente. No basta con que la media sea buena; se evalúa el percentil 75 (p75) de las sesiones reales.

Cómo medir tus Core Web Vitals

Existen dos tipos de datos para evaluar tus Core Web Vitals: datos de campo (reales) y datos de laboratorio (simulados). Ambos son útiles, pero Google usa exclusivamente los datos de campo para su factor de ranking.

Herramientas con datos de campo (las que importan para el ranking)

Google Search Console es la herramienta principal. Su informe de «Experiencia de la página» muestra qué URLs aprueban o suspenden las Core Web Vitals, agrupadas por estado. Es el primer sitio donde debes mirar porque refleja exactamente lo que Google ve.

PageSpeed Insights (PSI) muestra datos de campo del CrUX para URLs concretas, combinados con una auditoría de laboratorio Lighthouse. El apartado superior con el gráfico de barras de colores son los datos reales; las puntuaciones numéricas de abajo son datos de laboratorio.

CrUX Dashboard permite consultar el historial de Core Web Vitals de tu dominio a lo largo de meses, ideal para detectar tendencias y verificar si los cambios que hiciste tuvieron impacto.

Herramientas de laboratorio (para diagnosticar)

Lighthouse (integrado en Chrome DevTools, pestaña «Lighthouse») simula una carga en condiciones controladas. No mide INP porque necesita interacciones reales, pero es excelente para diagnosticar problemas de LCP y CLS. También se puede ejecutar desde la terminal con lighthouse --only-categories=performance.

Chrome DevTools > Performance permite grabar sesiones completas de navegación para analizar exactamente qué ocurre milisegundo a milisegundo. Es la herramienta más potente pero también la más compleja.

Web Vitals Extension es una extensión de Chrome que muestra las tres métricas en tiempo real mientras navegas por tu web. Muy útil para verificar cambios rápidamente durante el desarrollo.

Cómo mejorar el LCP (Largest Contentful Paint)

El LCP mide cuánto tarda en renderizarse el elemento visual más grande del viewport: suele ser una imagen hero, un vídeo, o un bloque de texto grande. El objetivo es que se muestre en menos de 2,5 segundos.

Optimización de imágenes

Las imágenes son la causa más frecuente de un LCP lento. Convierte todas las imágenes a formato WebP o AVIF, que ofrecen la misma calidad visual con un 25-50% menos de peso. Usa el atributo width y height para reservar espacio, y añade loading="lazy" a las imágenes que no están en el viewport inicial, pero nunca a la imagen LCP: esa debe cargar inmediatamente con fetchpriority="high".

Optimización del servidor

El tiempo de respuesta del servidor (TTFB) es la base del LCP. Si tu servidor tarda 2 segundos en responder, es imposible que el LCP sea bueno. Implementa caché del servidor (Varnish, Redis, o caché de página estática), usa un CDN para servir assets desde ubicaciones cercanas al usuario, y asegúrate de que tu hosting tenga recursos suficientes.

Eliminación de recursos bloqueantes

CSS y JavaScript en el <head> bloquean el renderizado. Extrae el CSS crítico (el necesario para pintar el contenido above-the-fold) e inclúyelo inline en el HTML. El resto del CSS puede cargarse de forma asíncrona con <link rel="preload" as="style">. Para JavaScript, usa defer o async en todos los scripts que no sean esenciales para el primer pintado.

Preconnect y preload

Si tu página carga recursos de dominios externos (fuentes de Google, CDN de imágenes, analytics), añade <link rel="preconnect"> para esos dominios. Para la imagen LCP específicamente, usa <link rel="preload" as="image"> para que el navegador la descargue antes de descubrir la etiqueta <img> en el HTML.

Cómo mejorar el INP (Interaction to Next Paint)

El INP evalúa la capacidad de respuesta de tu página midiendo el tiempo desde que el usuario interactúa (clic, toque, tecla) hasta que el navegador renderiza el siguiente frame visual. A diferencia de FID, que solo medía la primera interacción, INP evalúa todas las interacciones y reporta el peor caso representativo (percentil 98).

Reduce el JavaScript del hilo principal

El hilo principal del navegador es compartido entre JavaScript y el renderizado visual. Si un script largo está ejecutándose, las interacciones del usuario quedan en cola esperando. Identifica las «long tasks» (tareas de más de 50 ms) con Chrome DevTools > Performance y divídelas usando requestAnimationFrame() o scheduler.yield().

Divide el trabajo pesado

Si tienes código que procesa datos extensos (filtros de productos, ordenaciones de tablas, validaciones complejas), usa Web Workers para moverlo fuera del hilo principal. Otra técnica es dividir el trabajo en chunks pequeños usando setTimeout(fn, 0) o la API scheduler.postTask() para permitir que el navegador procese eventos de usuario entre cada chunk.

Reduce el tamaño del DOM

Un DOM excesivamente grande (más de 1.500 nodos) hace que cada interacción sea más lenta porque el navegador necesita recalcular estilos y layout para más elementos. Elimina nodos innecesarios, usa virtualización para listas largas (solo renderiza los elementos visibles) y evita anidar elementos más de 32 niveles.

Cuidado con third-party scripts

Scripts de terceros (analytics, chat widgets, ads) son una causa frecuente de INP deficiente. Cárgalos de forma diferida: los que no son esenciales pueden esperar al evento load o incluso a la primera interacción del usuario. Evalúa si realmente necesitas todos los scripts que tienes: cada uno que eliminas es tiempo de CPU que recuperas.

Cómo mejorar el CLS (Cumulative Layout Shift)

El CLS mide los desplazamientos inesperados de elementos visibles durante la vida de la página. Un CLS alto significa que mientras el usuario intenta leer o hacer clic, los elementos se mueven: una experiencia frustrante que Google penaliza.

Reserva espacio para imágenes y vídeos

Siempre declara width y height en las etiquetas <img> y <video>, o usa CSS aspect-ratio. Sin dimensiones explícitas, el navegador no sabe cuánto espacio reservar hasta que descarga el recurso, provocando un salto cuando lo inserta. Para iframes (vídeos de YouTube, mapas), usa un contenedor con aspect-ratio: 16/9.

Evita insertar contenido dinámico por encima del viewport

Banners de cookies, barras de notificación y anuncios que se insertan en la parte superior de la página empujan todo el contenido hacia abajo. Solución: reserva el espacio con min-height antes de cargar el contenido, o usa position: fixed/sticky para que se superponga sin desplazar nada.

Fuentes web y FOUT

Cuando una fuente web tarda en cargar, el navegador puede mostrar primero texto en una fuente genérica y luego cambiarlo (FOUT), causando un layout shift. Usa font-display: swap combinado con <link rel="preload" as="font" crossorigin> para las fuentes críticas. Si es posible, usa fuentes del sistema como fallback con métricas de tamaño similares (size-adjust en la declaración @font-face).

Animaciones seguras

Solo anima propiedades que no causan layout: transform y opacity. Animar width, height, top, left o margin provoca recalculos de layout que se cuentan como CLS. Si necesitas animar tamaños, usa transform: scale() como alternativa.

Errores comunes al optimizar Core Web Vitals

Confundir datos de laboratorio con datos de campo. Lighthouse puede dar 100 puntos y aun así suspender las Core Web Vitals en Search Console. Lo que importa para el ranking son los datos de campo (CrUX). Los datos de laboratorio solo sirven para diagnosticar.

Optimizar solo la home. Google evalúa las Core Web Vitals URL por URL, agrupándolas por patrones similares. Una homepage rápida no compensa un blog lento o fichas de producto pesadas. Prioriza las URLs que más tráfico reciben.

Aplicar lazy loading a la imagen LCP. Añadir loading="lazy" a la imagen principal del viewport inicial retrasa su carga porque el navegador espera a saber si está visible. La imagen LCP debe cargar inmediatamente, incluso con fetchpriority="high".

Ignorar el móvil. Google usa mobile-first indexing, así que evalúa las Core Web Vitals de la versión móvil de tu web. Muchos sitios aprueban en desktop pero suspenden en móvil por imágenes demasiado grandes, scripts excesivos o diseños que no adaptan bien al viewport reducido.

No esperar datos suficientes. Los datos de CrUX se acumulan en ventanas de 28 días. Después de hacer cambios, necesitas al menos 28 días para que el dataset se renueve completamente y refleje la mejora. Muchos propietarios de webs se desesperan a los 3 días al no ver cambios.

Añadir scripts de terceros sin control. Cada widget, plugin de chat, tracker o herramienta de marketing que añades a tu web consume recursos del hilo principal. Evalúa periódicamente cuáles usas realmente y elimina los que no aportan. Un script innecesario puede arruinar un INP que estaba dentro de umbrales.

Preguntas frecuentes sobre Core Web Vitals

¿Cuánto impactan las Core Web Vitals en el ranking?

Las Core Web Vitals son un factor de ranking confirmado por Google, pero no el más importante. El contenido relevante, los enlaces y la autoridad del dominio siguen pesando más. Sin embargo, en SERPs competidas donde varias páginas tienen contenido similar, las Core Web Vitals pueden ser el desempate que te suba o baje posiciones.

¿Qué pasó con FID? ¿Ya no existe?

FID (First Input Delay) fue reemplazado oficialmente por INP (Interaction to Next Paint) en marzo de 2024. INP es una métrica más completa porque mide la latencia de todas las interacciones durante la sesión, no solo la primera. Si ves referencias a FID en guías antiguas, sustituye mentalmente por INP.

¿Necesito datos de campo para aprobar las Core Web Vitals?

Sí. Google usa exclusivamente datos del CrUX (Chrome User Experience Report) para evaluar las Core Web Vitals como factor de ranking. Si tu web no tiene suficiente tráfico para generar datos de CrUX, Google no puede evaluar tus Core Web Vitals. En ese caso, las métricas no penalizan ni benefician tu ranking, pero tampoco puedes usarlas como ventaja competitiva.

¿Cuánto tiempo tardan en reflejarse las mejoras?

Los datos de CrUX se basan en una ventana de 28 días de datos reales de usuarios. Después de implementar mejoras, necesitas esperar al menos 28 días para que los datos se renueven completamente. En la práctica, puedes empezar a ver mejoras parciales a los 14-21 días a medida que los nuevos datos van sustituyendo a los antiguos.

¿Puedo aprobar Core Web Vitals con un hosting compartido barato?

Depende del tráfico y la complejidad de tu web. Un hosting compartido puede ser suficiente para un blog con poco tráfico si el sitio está bien optimizado. Pero para webs con tráfico medio-alto o ecommerce, un VPS o hosting cloud es prácticamente necesario para mantener un TTFB bajo, que es la base del LCP. Si tu TTFB supera los 600 ms consistentemente, difícilmente conseguirás un LCP bueno sin mejorar el servidor.