Core Web Vitals: conseguir un sitio que carga en menos de un segundo
LCP, INP, CLS: qué miden realmente los Core Web Vitals, las herramientas adecuadas para auditarlos y el método concreto para que un sitio cargue en menos de un segundo.
Un sitio que tarda más de tres segundos en mostrarse pierde buena parte de sus visitantes antes incluso de terminar de cargar. Google lo sabe, y lo ha convertido en un criterio oficial de clasificación mediante tres métricas precisas: los Core Web Vitals. Esto es lo que miden realmente, cómo auditarlos sin fiarse del primer número que aparece, y el método para que un sitio cargue en menos de un segundo.
Qué miden realmente los Core Web Vitals
Tres métricas, cada una con un umbral «bueno» al que aspirar:
| Métrica | Qué mide | Bueno | Mejorable | Malo |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Tiempo de aparición del elemento visible más grande en pantalla | ≤ 2,5 s | ≤ 4 s | > 4 s |
| INP (Interaction to Next Paint) | Capacidad de respuesta ante un clic, un toque o una escritura | ≤ 200 ms | ≤ 500 ms | > 500 ms |
| CLS (Cumulative Layout Shift) | Estabilidad visual durante la carga (elementos que «saltan») | ≤ 0,1 | ≤ 0,25 | > 0,25 |
El INP sustituyó al FID (First Input Delay) en 2024: ya no mide solo el primer retraso de respuesta, sino la capacidad de respuesta durante toda la visita. Un sitio puede responder rápido al primer clic y volverse lento después; el INP capta ese caso.
Por qué importa tanto
Dos razones, independientes entre sí. La primera es el posicionamiento: desde 2021, los Core Web Vitals forman parte de las señales de clasificación de Google. No es el factor número uno, pero con un contenido equivalente, desempata entre dos páginas competidoras.
La segunda razón, más concreta, es el comportamiento de los visitantes. Un sitio lento, o cuyos botones se esquivan justo cuando se pulsan, genera abandonos y formularios que nunca se envían. En móvil, con una conexión menos estable y un procesador menos potente, estos defectos se amplifican: ahí suele decidirse la diferencia entre un visitante que se queda y otro que se va.
Las herramientas para saber dónde estás, antes de tocar nada
Antes de corregir cualquier cosa, hay que medir correctamente, lo que implica distinguir dos tipos de datos:
- Datos de laboratorio (Lighthouse en Chrome DevTools, PageSpeed Insights en modo «diagnóstico»): una simulación puntual, en un dispositivo y una conexión estandarizados. Útil para depurar, pero no es lo que viven tus visitantes reales.
- Datos de campo (la pestaña de experiencia real de usuarios en PageSpeed Insights, o el informe «Core Web Vitals» de Search Console): mediciones agregadas de los últimos 28 días, tomadas en los dispositivos y conexiones reales de tus visitantes. Es el único dato que cuenta para el posicionamiento en Google.
Un sitio puede obtener una puntuación excelente en laboratorio y seguir siendo malo en condiciones reales, si la mayoría de su tráfico viene de móviles de gama baja. Cruza siempre ambos datos antes de sacar conclusiones.
El método: las palancas que realmente marcan la diferencia
Reducir el LCP
La mayor parte de la ganancia viene de tres ajustes: servir las imágenes en el formato correcto (AVIF o WebP) y en el tamaño correcto, no dejar que el JavaScript bloquee la visualización del contenido principal, y precargar (preload) la imagen o la fuente que compone el elemento más visible de la página.
Estabilizar el CLS
La causa más frecuente es sencilla: imágenes o vídeos sin dimensiones (width/height o aspect-ratio) definidas de antemano, que empujan el contenido al cargarse. Reservar el espacio desde el principio elimina casi todos los saltos visuales.
Mejorar el INP
La verdadera palanca es la cantidad de JavaScript ejecutado durante la carga. Es uno de los principios que aplico en mis propios proyectos, detallado en este artículo sobre Astro y GSAP: entregar cero JavaScript por defecto, y cargar los scripts de interacción solo cuando realmente se vuelven útiles.
Un ejemplo concreto: antes / después
En una renovación técnica típica, partiendo de un sitio construido sobre una plantilla genérica sobrecargada de scripts, este es el orden de magnitud de las mejoras obtenidas al empezar de nuevo sobre una base más limpia:
| Métrica | Antes de la renovación | Después de la renovación |
|---|---|---|
| LCP | 4,1 s | 0,9 s |
| INP | 340 ms | 110 ms |
| CLS | 0,22 | 0,01 |
Esto no es magia: es el resultado de una renovación técnica del sitio que trata el rendimiento como una restricción de diseño desde el principio, en lugar de un parche aplicado después.
Lo que hay que recordar
Los Core Web Vitals no son una puntuación que perseguir para marcar una casilla de Google. Son tres síntomas concretos —lentitud, inestabilidad, pesadez— que, una vez corregidos, se traducen directamente en visitantes que se quedan y formularios que se envían hasta el final.
Hablemos de tu proyecto
Si tu sitio acumula señales en rojo en Search Console, o simplemente quieres partir de una base rápida desde el diseño, envíame un mensaje: puedo auditar la situación actual y decirte con precisión qué está lastrando tu rendimiento.