Core Web Vitals: Métricas que Impactan tu SEO

Qué son los Core Web Vitals y por qué Google los usa para rankear

Los Core Web Vitals son tres métricas de rendimiento web que Google incorporó como señal de ranking oficial desde 2021. Miden la experiencia real del usuario al cargar una página: cuánto tarda en mostrar el contenido principal, qué tan rápido responde a la interacción y si los elementos visuales se mueven de forma inesperada mientras la página carga.

No son métricas técnicas abstractas. Representan frustraciones reales: el botón que se mueve justo cuando lo ibas a tocar, la imagen que tarda cuatro segundos en aparecer, el formulario que no responde. Google los convirtió en señal de ranking precisamente porque correlacionan con el abandono de páginas.

Desde mayo de 2021, los sitios con malos Core Web Vitals pueden perder posiciones frente a competidores con contenido equivalente pero mejor rendimiento web. En nichos competitivos, esa diferencia puede ser la primera página versus la segunda.

Un sitio que carga en 1 segundo tiene una tasa de conversión 3 veces mayor que uno que carga en 5 segundos. Las métricas de velocidad no son solo SEO: son negocio.

LCP: Largest Contentful Paint y cómo optimizarlo

El Largest Contentful Paint (LCP) mide el tiempo que tarda en renderizarse el elemento visual más grande visible en la pantalla inicial: normalmente una imagen hero, un video de portada o un bloque de texto grande. Google considera un LCP bueno cualquier valor por debajo de 2.5 segundos. Entre 2.5 y 4 segundos es "necesita mejora". Por encima de 4 segundos, directamente malo.

Los culpables más frecuentes de un LCP lento son tres:

• Imágenes sin optimizar: un PNG de 3MB donde cabría un WebP de 180KB destruye el LCP.
• Servidores lentos o TTFB alto: si el servidor tarda más de 600ms en responder, el LCP nunca será bueno sin importar lo que hagas en el frontend.
• JavaScript que bloquea el render: scripts cargados de forma síncrona que retrasan todo lo que viene después.

Las correcciones más efectivas, por orden de impacto: usar un CDN para reducir la latencia del servidor, convertir imágenes a WebP o AVIF, añadir el atributo fetchpriority="high" a la imagen LCP para que el navegador la descargue antes, y aplazar scripts de terceros (analytics, chat widgets, píxeles de ads) con defer o async.

Una táctica que se subestima: el prefetch de recursos críticos. Añadir <link rel="preload"> para la fuente tipográfica y la imagen hero puede recortar entre 0.5 y 1.2 segundos del LCP sin cambiar una línea de código de backend.

INP (antes FID): La métrica de interactividad que cambió en 2024

En marzo de 2024, Google reemplazó First Input Delay (FID) por Interaction to Next Paint (INP) como Core Web Vital oficial. El cambio importa porque FID medía solo la primera interacción, mientras que INP mide el tiempo de respuesta durante toda la sesión del usuario. Es más difícil de optimizar y mucho más representativa de la experiencia real.

Un INP saludable es menor a 200 milisegundos. Entre 200ms y 500ms necesita mejora. Por encima de 500ms, el usuario ya percibe el retraso conscientemente.

Por qué el JavaScript es el enemigo principal del INP

El hilo principal del navegador es el cuello de botella. Cada vez que ejecutas JavaScript, el navegador no puede procesar interacciones del usuario. Las tareas largas de JS (las que duran más de 50ms) son las responsables directas de un INP alto.

Las soluciones técnicas incluyen:

• Dividir tareas largas con setTimeout(0) o la API scheduler.yield()
• Usar Web Workers para mover lógica pesada fuera del hilo principal
• Auditar y eliminar plugins o scripts de terceros que ejecuten código en cada interacción
• Implementar lazy loading de componentes JavaScript que no sean necesarios en la carga inicial

En sitios construidos con frameworks como React o Vue, el problema típico es el hydration: el proceso por el cual el JS toma control del HTML estático genera una ráfaga de trabajo en el hilo principal justo cuando el usuario quiere interactuar. Frameworks modernos como Astro o técnicas como Partial Hydration atacan este problema directamente.

flowchart TD
    A["Usuario visita la página"] --> B["Navegador descarga HTML"]
    B --> C["Descarga recursos: CSS, JS, imágenes"]
    C --> D["Renderiza elemento más grande (LCP)"]
    D --> E["Página lista para interacción"]
    E --> F["Usuario hace clic o toca"]
    F --> G["Navegador procesa interacción (INP)"]
    G --> H["¿Elementos se desplazan? (CLS)"]
    H --> I["Experiencia completada"]
  

CLS: El Core Web Vital que más irrita a los usuarios

El Cumulative Layout Shift (CLS) mide la inestabilidad visual de una página: cuánto se mueven los elementos mientras el contenido carga. Un CLS bueno es cualquier valor por debajo de 0.1. Parece un número pequeño y abstracto hasta que experimentas lo que representa: el artículo que lees de repente salta tres párrafos hacia abajo porque un banner de publicidad terminó de cargar arriba.

Las causas más comunes de CLS alto:

• Imágenes sin dimensiones declaradas: si no especificas width y height en el HTML, el navegador no puede reservar el espacio antes de descargar la imagen.
• Anuncios y embeds de tamaño variable: los bloques de AdSense o iframes de redes sociales que aparecen sin contenedor de tamaño fijo son los mayores contribuyentes al CLS en sitios con publicidad.
• Fuentes tipográficas personalizadas: el FOUT (Flash of Unstyled Text) y el FOIT (Flash of Invisible Text) desplazan el layout cuando la fuente web termina de cargar y reemplaza a la fuente del sistema.
• Contenido inyectado dinámicamente: banners de cookies, notificaciones push, barras de anuncio que aparecen en la parte superior después de la carga inicial.

Cómo corregir el CLS de forma efectiva

Para imágenes, la solución es simple: siempre declara width y height en el atributo HTML o usa CSS con aspect-ratio. Para fuentes, usa font-display: optional o font-display: swap con una fuente de sistema similar como fallback. Para anuncios, reserva el espacio con un contenedor de altura fija antes de que el ad cargue.

El CLS alto es el Core Web Vital que más afecta la percepción de calidad del sitio. Un usuario puede tolerar una carga lenta. No puede tolerar hacer clic en el botón equivocado porque la página se movió.

Cómo medir los Core Web Vitals en tu sitio web

Existen dos tipos de datos para medir Core Web Vitals: datos de campo (field data) y datos de laboratorio (lab data). Google usa exclusivamente los datos de campo para el ranking: son las mediciones reales de usuarios reales navegando tu sitio, recopiladas a través del Chrome User Experience Report (CrUX). Los datos de laboratorio (herramientas como Lighthouse) son útiles para diagnóstico pero no afectan directamente el ranking.

Las herramientas esenciales para auditar el rendimiento web de tu sitio:

• Google Search Console → Experiencia de Página: muestra tus Core Web Vitals reales de campo, segmentados por desktop y móvil. Es el primer lugar donde debes mirar.
• PageSpeed Insights: combina datos de campo (CrUX) con análisis de laboratorio (Lighthouse). Ideal para diagnosticar páginas individuales.
• Chrome DevTools → Performance: para análisis a nivel de código, ver tareas largas de JS y waterfall de recursos.
• web-vitals JavaScript library: para medir Core Web Vitals directamente en tus usuarios reales e integrarlos a tu propio analytics.

Un dato importante: si tu sitio tiene poco tráfico, es posible que Google no tenga suficientes datos de campo para evaluar tus Core Web Vitals. En ese caso, el ranking se basa en señales inferidas. Publicar herramientas como Think with Google ofrece guías actualizadas sobre cómo interpreta Google estas métricas cuando los datos de campo son insuficientes.

Para un diagnóstico completo de tu SEO técnico, los Core Web Vitals son solo una capa. Forman parte de la señal "Page Experience" junto con HTTPS, ausencia de intersticiales intrusivos y adaptación móvil. Nuestra consultoría de estrategia digital trabaja exactamente ese conjunto completo, no solo la velocidad de forma aislada.

pie title Causas mas comunes de CLS alto
    "Imágenes sin dimensiones" : 35
    "Anuncios y embeds" : 28
    "Fuentes tipograficas" : 20
    "Contenido dinamico" : 17
  

Core Web Vitals y SEO técnico: la estrategia de priorización

Mejorar los Core Web Vitals no es un proyecto de un fin de semana. Es un proceso de auditoría, priorización e iteración. La trampa más común es atacar primero los problemas más visibles en Lighthouse sin verificar si esos son los problemas que afectan el rendimiento web real de los usuarios.

Un orden de trabajo efectivo para la mayoría de sitios:

1. Audita primero en móvil: Google usa Mobile-First Indexing. Tus métricas de escritorio pueden ser perfectas y el ranking verse afectado si el móvil falla.
2. Identifica las páginas con más tráfico: optimizar las 10 páginas que reciben el 80% de las visitas tiene más impacto que un refactor general del sitio.
3. Ataca el LCP antes que el CLS: el LCP suele tener mejoras de mayor impacto y más rápidas de implementar (compresión de imágenes, CDN).
4. Audita scripts de terceros: un solo píxel de tracking mal cargado puede destruir el LCP y el INP simultáneamente.
5. Mide el impacto con datos de campo: espera 28 días después de cada cambio significativo para ver el reflejo en CrUX y Search Console.

Los recursos de Harvard Business Review documentan cómo la velocidad de carga está directamente correlacionada con métricas de negocio: retención, conversión y percepción de marca. Lo que empieza como un proyecto de SEO técnico termina afectando los resultados del negocio completo.

El seo técnico y el rendimiento web no son disciplinas separadas del marketing digital. Un sitio lento que nadie abandona convierte mejor que uno rápido con contenido pobre. Pero cuando el contenido es equivalente entre competidores, el rendimiento decide. Para ver cómo esto impacta en sectores específicos como el inmobiliario, el artículo sobre cómo la tasa de conversión inmobiliaria cambia con el tiempo de respuesta muestra el patrón con datos reales del sector.

Optimizar los Core Web Vitals sin una estrategia de contenido es como tener el coche más rápido de la carrera pero sin saber a dónde vas. El rendimiento web amplifica lo que ya funciona; no sustituye lo que falta.

Herramientas y frameworks para mantener el rendimiento web a largo plazo

La mayoría de las mejoras de Core Web Vitals se degradan con el tiempo si no se monitorean. Cada nuevo plugin, cada script de marketing adicional, cada imagen subida sin optimizar erosiona el rendimiento que se trabajó para conseguir. La clave es institucionalizar la medición.

Un stack de monitorización básico que funciona:

• Google Search Console: revisión mensual de la pestaña "Experiencia de Página" para detectar regresiones.
• SpeedCurve o Calibre: monitorización continua de rendimiento web con alertas cuando las métricas superan umbrales definidos.
• Lighthouse CI en el pipeline de desarrollo: ejecuta auditorías automáticas en cada deploy y bloquea los cambios que degraden el rendimiento por debajo de un umbral.

Para sitios con WordPress, plugins como Perfmatters o Flying Scripts permiten controlar exactamente qué scripts cargan en cada tipo de página. No hay razón para cargar WooCommerce en el blog ni el slider de la homepage en las páginas de producto.

Si tu sitio corre sobre Next.js, el framework ya incorpora optimizaciones automáticas de imagen (next/image) y tipografía (next/font) que atacan directamente los problemas más comunes de LCP y CLS. Aprovecharlas correctamente puede conseguir Core Web Vitals en verde sin trabajo manual adicional.

Para sitios que también ejecutan campañas de publicidad digital, es crítico que los píxeles de tracking no bloqueen el render. Nuestro servicio de gestión de campañas Meta y Google Ads implementa los píxeles de forma asíncrona para que no penalicen la velocidad del sitio web mientras se mantiene la atribución correcta.

Las tendencias de rendimiento web para los próximos años apuntan a métricas aún más granulares. Publicaciones especializadas como el Content Marketing Institute ya analizan cómo el rendimiento web intersecta con la experiencia de contenido en un entorno donde la IA generativa consume y redistribuye ese contenido. La velocidad del sitio web no es solo un factor de ranking clásico: es un factor de eligibilidad para aparecer en respuestas de IA.