Core Web Vitals: hacer un sitio rápido de verdad
La velocidad no es un lujo: es un factor de posicionamiento en Google y de conversión. Desglose de los Core Web Vitals — LCP, INP, CLS — y de las palancas concretas que uso para mantenerlos en verde.
«En mi máquina va bien» no basta
La trampa clásica: el desarrollador prueba con fibra, un MacBook reciente y la caché caliente. El usuario real, en cambio, llega desde un móvil de gama media, con un 4G caprichoso y la caché vacía. Entre ambos, la experiencia no tiene nada que ver.
Los Core Web Vitals existen para medir lo que realmente vive el usuario. Google los convirtió en un factor de posicionamiento — y, sobre todo, predicen la conversión: cada segundo de carga de más ahuyenta visitantes.
Las tres métricas que cuentan
- LCP (Largest Contentful Paint) — el tiempo hasta que aparece el elemento principal (a menudo la imagen o el título del hero). Objetivo: menos de 2,5 s.
- INP (Interaction to Next Paint) — la reactividad: el retardo entre un clic y la respuesta visible. Objetivo: menos de 200 ms. Es el nervio de la guerra en los sitios cargados de JavaScript.
- CLS (Cumulative Layout Shift) — la estabilidad: esos saltos de maquetación que hacen clicar en el sitio equivocado cuando se carga una imagen o un anuncio. Objetivo: menos de 0,1.
Un sitio bonito y lento es un sitio fallido. El rendimiento no es enemigo del diseño — es una restricción que obliga a decisiones nítidas.
Las palancas que uso
Hacer un sitio rápido no tiene nada de mágico, es una suma de decisiones:
- Imágenes — formato moderno (AVIF/WebP), dimensiones correctas,
lazy loadingbajo la línea de flotación y una reserva de espacio para evitar saltos (CLS). - Fuentes —
font-display: swap, precarga de los pesos realmente usados y, sobre todo: cargar solo esos. - JavaScript — enviar el mínimo posible. El código más rápido es el que no se envía al navegador. Componentes de servidor, carga diferida de lo no crítico.
- Renderizado — priorizar lo estático (pregenerado en el build) cuando el contenido lo permite: nada supera a un archivo ya listo.
- Medición continua — un presupuesto de rendimiento y una vigilancia (Lighthouse, Speed Insights) para que una regresión se vea antes de la puesta en producción, no después.
Medir en el terreno, no en el laboratorio
Hay dos formas de medir: los datos de laboratorio (Lighthouse, entorno controlado) y los datos de campo (los usuarios reales, vía el Chrome UX Report). Ambos son útiles, pero solo el segundo refleja la realidad. Un sitio puede marcar 100 en laboratorio y decepcionar en campo por una conexión lenta o un dispositivo modesto.
Mi disciplina: optimizar en laboratorio para ir rápido, pero validar en campo antes de cantar victoria.
Por qué le importa a un cliente
Un sitio rápido no es solo una coquetería técnica. Es más visitantes que se quedan, mejor posicionamiento en Google y más conversiones. La velocidad es una de las raras mejoras que sirve a la vez al usuario, al posicionamiento y a la facturación. Por eso la trato como una exigencia, no como un extra.