Core Web Vitals en 2026: qué son y cómo aprobar el examen de Google

Google te está poniendo nota. Y la mayoría suspende.

Desde 2021 Google usa tres métricas técnicas concretas para decidir si tu web ofrece una experiencia decente. Se llaman Core Web Vitals y son uno de los factores de ranking más subestimados que existen: si las tienes en rojo, da igual cuánto contenido y SEO tengas — Google va a empujar tu web hacia abajo.

Y según el último informe de HTTP Archive, menos del 40% de las webs en móvil aprueban los tres Core Web Vitals. Es decir, 6 de cada 10 webs están penalizadas técnicamente sin saberlo.

6 de 10

webs en móvil suspenden Core Web Vitals. Si las apruebas, ya superas al 60% de tu competencia en señales técnicas

En esta guía te explicamos qué son las tres métricas, qué valores tienes que conseguir, qué errores típicos las hunden y cómo arreglarlas.

Qué son los Core Web Vitals

Son tres métricas que miden tres dimensiones distintas de la experiencia de usuario:

Métrica	Qué mide	Objetivo
LCP (Largest Contentful Paint)	Velocidad de carga visible	< 2,5s
INP (Interaction to Next Paint)	Capacidad de respuesta	< 200ms
CLS (Cumulative Layout Shift)	Estabilidad visual	< 0,1

Google evalúa estos valores en el percentil 75 de tus usuarios reales. Es decir, no basta con que vayan rápido en tu Mac con fibra — tienen que ir rápido en el 75% de los móviles de tus usuarios reales, incluyendo Androids modestos en 4G.

LCP — Largest Contentful Paint

Mide el tiempo desde que el usuario llega a la página hasta que se renderiza el elemento más grande visible (normalmente la imagen del hero o el bloque principal de texto). Es la métrica que mejor refleja "se siente rápido o se siente lento".

Bueno: < 2,5 segundos
Mejorable: 2,5 - 4 segundos
Malo: > 4 segundos

INP — Interaction to Next Paint

Sustituyó a FID en marzo de 2024. Mide cuánto tarda la web en responder visualmente cuando el usuario hace clic, toca o teclea. Si el INP es alto, la web "se siente bloqueada" — el usuario hace clic y no pasa nada durante medio segundo.

Bueno: < 200 ms
Mejorable: 200 - 500 ms
Malo: > 500 ms

CLS — Cumulative Layout Shift

Mide cuánto se mueve el contenido inesperadamente mientras carga. Si has intentado hacer clic en un botón y de repente se mueve porque acaba de cargar un banner arriba, has sufrido CLS alto. Google lo penaliza con razón.

Bueno: < 0,1
Mejorable: 0,1 - 0,25
Malo: > 0,25

Por qué Core Web Vitals importan tanto

Tres razones, en orden de impacto:

Factor de ranking confirmado por Google. No es el factor más fuerte, pero en sectores competitivos donde todos tienen contenido bueno, mover Core Web Vitals te puede subir 2-5 posiciones.
Conversión. Cada 100ms extra de LCP reduce la conversión en un 1-2% según Google. Una web con LCP de 4s convierte un 15-30% menos que una con LCP de 1,5s. Lo desarrollamos en por qué la velocidad de tu web te está costando clientes.
Tasa de rebote. Una web con CLS alto frustra al usuario. Una web con LCP alto pierde al usuario antes de cargar.

Las causas típicas de Core Web Vitals en rojo

Por qué LCP está alto

Imágenes pesadas en el hero. Una imagen JPEG de 800KB cuando debería ser 80KB en WebP.
Hosting lento. TTFB (Time To First Byte) superior a 800ms. Cambiar de hosting es la fix más rápida.
Render bloqueado. CSS o JavaScript que paran el render hasta cargar.
Web fonts mal configurados. El navegador espera a la fuente antes de pintar texto.
Demasiados scripts de terceros. Cada tracker es 200-500ms.

Por qué INP está alto

Bundle de JavaScript enorme. 1MB de JS comprimido es exagerado para una web pyme.
Event handlers pesados. Hacer trabajo síncrono en click handlers.
Frameworks mal configurados. WordPress + 30 plugins es el caso clásico.

Por qué CLS está alto

Imágenes sin dimensiones. No tener width y height en <img>. El navegador reserva 0px y luego salta.
Banners y anuncios cargados tarde. Aparecen, empujan el contenido.
Web fonts que cambian el tamaño del texto al cargar.
Pop-ups y banners de cookies mal animados.

Cómo arreglar Core Web Vitals — checklist accionable

Quick wins (impacto alto, esfuerzo bajo)

1. Comprime y convierte imágenes. Pasa todas las imágenes a WebP o AVIF. Una imagen de 800KB pasa a 80KB con calidad visual idéntica. Solo esto mueve el LCP varios cientos de ms.

2. Define width y height en cada <img> y <video>. El navegador reserva el espacio y no hay saltos. CLS baja inmediatamente.

3. Usa loading="lazy" en imágenes fuera del primer pliegue. El navegador no las carga hasta que el usuario hace scroll cerca.

4. Pre-conecta a dominios externos críticos. <link rel="preconnect" href="https://fonts.googleapis.com"> ahorra 100-300ms en cada handshake.

5. Configura font-display: swap en tus web fonts. El navegador muestra el texto con la fuente del sistema mientras carga la tuya.

Optimizaciones medias (impacto alto, esfuerzo medio)

Minifica y comprime CSS y JS. Todos los frameworks modernos lo hacen automáticamente. Si tu web aún no, es señal de stack viejo.
Code splitting. Carga solo el JavaScript que cada página necesita, no el bundle entero en cada vista.
CDN de imágenes. Cloudinary, Cloudflare Images, Vercel Image — automáticamente convierten y sirven el formato óptimo al navegador.
Hosting decente. Vercel, Cloudflare Pages, Netlify, AWS son baratos y rapidísimos. Sal del hosting compartido a 3€/mes.

Optimizaciones técnicas (impacto alto, esfuerzo alto)

Stack moderno (Next.js, Astro, SvelteKit). Renderizado estático o híbrido = LCP < 1s posible.
Eliminar plugins. Si usas WordPress, audita cada plugin: cada uno suma JS al bundle.
Reducir el peso total del JavaScript. Objetivo razonable: < 300KB comprimidos.

Cómo medir Core Web Vitals correctamente

Tres tipos de mediciones, en orden de importancia:

1. Datos reales de usuarios (CrUX) — Google Search Console

Es la fuente que Google usa para el ranking. Datos reales de usuarios anonimizados de Chrome durante los últimos 28 días.

Ve a Search Console → "Experiencia" → "Core Web Vitals"
Verás "URLs con problemas en móvil/escritorio"
Click en cada error → te dice qué URLs y qué métrica está mal

Importante: Search Console solo muestra datos si tu web tiene tráfico suficiente. Sin tráfico, no hay datos reales.

2. PageSpeed Insights

pagespeed.web.dev. Te muestra dos cosas:

CrUX data — datos reales últimos 28 días (si los hay)
Lab data — simulación de un dispositivo móvil 4G. Útil cuando no tienes CrUX.

3. Lighthouse en Chrome DevTools

Para diagnóstico técnico detallado. Te dice qué optimización específica aplicar.

La diferencia entre "tener Core Web Vitals buenos en Lighthouse" y "tener Core Web Vitals buenos según Google" puede ser enorme. Solo cuenta CrUX (datos reales). Lighthouse es un termómetro útil, pero no es la nota final.

Caso real: pyme que pasa de rojo a verde y sube 4 posiciones

Una asesoría tenía la web en WordPress, con LCP de 4,8s, INP de 350ms y CLS de 0,28. Todo en rojo.

Hicimos 3 cosas en 6 horas:

Cambio de hosting compartido a Vercel (LCP bajó 1,2s solo con esto)
Conversión de imágenes a WebP + dimensiones explícitas (CLS de 0,28 → 0,05)
Desactivar 7 plugins de WordPress innecesarios + diferir el cargador de chat (INP de 350ms → 140ms)

Resultado: las tres métricas en verde. Subió de la posición 9 a la 5 para su keyword principal en 6 semanas. Cero cambios en contenido. Solo técnica.

Si tu stack está atascado en WordPress, este es el motivo por el que WordPress y Wix están limitando tu negocio. Stacks modernos te dan Core Web Vitals en verde de serie.

Tu siguiente paso

Hacer una auditoría rápida es gratis y te lleva 5 minutos:

Abre pagespeed.web.dev y mete tu URL
Mira el bloque "Datos de origen" (CrUX) en móvil
Anota: ¿Qué métricas están en rojo o amarillo?

Si están en rojo, tu web está perdiendo posiciones y conversiones cada día. Te hacemos una auditoría técnica gratis en 24 horas con el plan exacto para pasar a verde, priorizado por impacto.

Y si vas a hacer una web nueva, los Core Web Vitals están cubiertos desde el día 1 en nuestro stack — fíjate en cómo funciona el desarrollo web con IA y en nuestro servicio de diseño web SEO.