Core Web Vitals en 2025: guía para no técnicos

Los Core Web Vitals son la métrica de experiencia de usuario que Google usa como factor de ranking. Si tu web carga lento, se mueve al pulsar botones o se ve inestable, Google te penaliza aunque tengas el mejor contenido. Esta guía explica los Core Web Vitals en lenguaje claro, sin tecnicismos innecesarios, para que puedas auditar y mejorar tu web aunque no seas desarrollador.

1. Qué son los Core Web Vitals

Los Core Web Vitals son tres métricas que miden la experiencia real del usuario al usar tu web:

• LCP (Largest Contentful Paint): cuánto tarda en cargarse el elemento más grande visible. Mide velocidad de carga percibida.
• INP (Interaction to Next Paint): cuánto tarda la web en responder cuando el usuario pulsa algo. Mide responsividad. Sustituyó a FID en 2024.
• CLS (Cumulative Layout Shift): cuánto "salta" el contenido mientras carga. Mide estabilidad visual.

Google usa estas tres métricas (junto con otras de seguridad y mobile-friendly) para decidir si tu web ofrece buena experiencia. Si las suspendes, tu posicionamiento orgánico se resiente.

2. Objetivos y umbrales

Los umbrales oficiales que debes perseguir son:

• LCP: menos de 2,5 segundos (verde). Entre 2,5 y 4 segundos (ámbar). Más de 4 (rojo).
• INP: menos de 200 ms (verde). Entre 200 y 500 ms (ámbar). Más de 500 ms (rojo).
• CLS: menos de 0,1 (verde). Entre 0,1 y 0,25 (ámbar). Más de 0,25 (rojo).

Tu objetivo es que el 75% de las visitas reales estén en verde. No importa la media: importa la distribución.

3. Cómo medir los Core Web Vitals

Herramientas gratuitas para medir:

• PageSpeed Insights: la herramienta oficial de Google. Te da LCP, INP y CLS con recomendaciones concretas.
• Search Console: te muestra los Core Web Vitals de tus usuarios reales por URL, no solo en labor.
• Chrome DevTools (pestaña Performance): para depurar problemas concretos.
• Web Vitals Chrome extension: para medir en cualquier web mientras navegas.

El dato que vale es el de usuarios reales (campo), no el de laboratorio. Search Console es la fuente que más te interesa.

4. Causas más frecuentes de LCP alto

El LCP se dispara por:

• Imágenes grandes sin optimizar (formato JPG en vez de WebP).
• Fuentes de Google Fonts cargadas de forma bloqueante.
• Banners o hero images pesadas sin tamaño definido.
• Servidores lentos o sin CDN.
• Render-blocking de CSS y JavaScript innecesarios.

Soluciones rápidas:

• Convierte imágenes a WebP o AVIF.
• Usa font-display: swap para fuentes.
• Define siempre ancho y alto en imágenes.
• Usa un CDN (Cloudflare, Vercel, Netlify) para servir contenido estático cerca del usuario.
• Pre-carga la imagen principal con preload.

5. Causas más frecuentes de INP alto

El INP alto se debe a JavaScript que bloquea la respuesta a la interacción. Causas típicas:

• Demasiados event listeners en el documento.
• Animaciones pesadas que bloquean el hilo principal.
• Librerías grandes que se cargan de golpe.
• Third-party scripts (analytics, chat, anuncios) mal configurados.

Soluciones:

• Code splitting: carga JavaScript solo cuando se necesita.
• Diferir scripts no críticos con defer o async.
• Mueve trabajo pesado a Web Workers.
• Audit third-party scripts y elimina los que no aportan.

6. Causas más frecuentes de CLS alto

El CLS mide los "saltos" visuales. Causas típicas:

• Imágenes sin ancho/alto definidos.
• Banners o anuncios que aparecen tarde sin espacio reservado.
• Fuentes que cambian de tamaño al cargar.
• Modales o popups que desplazan el contenido.

Soluciones:

• Define siempre dimensiones en imágenes y vídeos.
• Reserva espacio para anuncios y banners dinámicos.
• Usa font-display: optional para evitar saltos de fuente.
• Evita insertar contenido encima del que ya está visible.

7. Cómo priorizar las mejoras

No intentes optimizar todo a la vez. Prioriza por:

1. El problema más grave (la métrica en rojo).
2. Las páginas con más tráfico (home, landing principal).
3. Las páginas de conversión (producto, checkout, contacto).

Cada mejora en home tiene más impacto que en una página secundaria. Si optimizas solo 3 páginas, que sean las que más negocio aportan.

8. La paradoja del CWV y el contenido

Algunas webs obtienen CWV excelentes porque no tienen contenido ni imágenes. Eso es trampa: Google también mide calidad de contenido. El objetivo es CWV bueno y contenido bueno, no uno a costa del otro. Una web moderna con renderizado estático (SSG) y buen CDN puede tener ambas sin sacrificar nada.

9. Mi stack preferido para CWV perfectos

Para proyectos donde la experiencia es crítica, mi combinación favorita es:

• Next.js con renderizado estático para páginas de contenido.
• Vercel o Cloudflare como CDN edge.
• Imágenes en WebP/AVIF con next/image.
• Fuentes con next/font y display: swap.
• JavaScript diferido por defecto.

Con esto es habitual lograr LCP < 1s, INP < 100ms y CLS < 0,05 sin esfuerzo extraordinario.

Conclusión

Los Core Web Vitals no son una moda técnica: son un factor de ranking que decide si tu contenido llega a leerse. Si quieres auditar los CWV de tu web y trazar un plan de mejora, en mi consultoría lo hacemos con datos reales de tu Search Console y herramientas oficiales.

Preguntas frecuentes

¿Mi web carga en 3 segundos, está bien?

Para LCP, 3 segundos está en ámbar. No es catastrófico, pero pierdes posicionamiento respecto a competidores que cargan en menos de 2,5 segundos. Es fácilmente mejorable en la mayoría de casos.

¿Los CWV afectan a un blog personal sin negocio?

Sí. Google los usa como factor de ranking en cualquier tipo de web, comercial o no. Un blog con malos CWV recibe menos tráfico orgánico que uno con buenos CWV.

¿Hace falta ser desarrollador para mejorar los CWV?

Para las mejoras básicas (imágenes, fuentes, hosting) no. Para las avanzadas (code splitting, refactoring JS) sí. Una buena consultoría inicial puede identificar el 80% de mejoras con cambios sencillos.