
Lo que cambié para mejorar mi Core Web Vitals
Tres cambios concretos, sin florituras, que más impacto tuvieron en LCP, CLS e INP en los proyectos que mantengo.
Cada vez que reviso el Core Web Vitals de un proyecto en Search Console, me encuentro con los mismos tres sospechosos habituales. No hace falta reescribir nada desde cero para mejorarlos — casi siempre son un puñado de cambios concretos, algo aburridos, que se olvidan entre proyecto y proyecto hasta que vuelves a mirar el informe.
LCP: casi siempre es una imagen
El Largest Contentful Paint mide cuánto tarda en pintarse el elemento más grande visible al cargar. En el noventa por ciento de los casos que he revisado, ese elemento es una imagen de cabecera. El cambio que más impacto tiene: marcarla con fetchpriority="high" y quitarle el loading="lazy" — cargar de forma perezosa precisamente la imagen que el usuario ve la primera fracción de segundo es contradictorio, y aun así es el error que más veces me he encontrado, también en código mío de hace años.
CLS: casi siempre es la falta de un aspect-ratio
El Cumulative Layout Shift mide cuánto salta el contenido mientras carga la página. Casi siempre viene de una imagen sin dimensiones reservadas: el navegador no sabe qué alto va a ocupar hasta que termina de descargarla, así que empuja el texto de debajo hacia abajo en cuanto llega. La solución es tan simple que sorprende lo a menudo que falta: fijar un aspect-ratio explícito calculado a partir del ancho y alto reales de la imagen, para que el navegador reserve el hueco exacto desde el primer instante, antes de que el archivo haya llegado siquiera.
INP: casi siempre es JavaScript bloqueando el hilo principal
El más nuevo de los tres, el Interaction to Next Paint, mide cuánto tarda la página en responder visualmente después de que el usuario haga clic o toque algo. Aquí el villano casi siempre es un bloque de JavaScript pesado ejecutándose de golpe — un cálculo grande, un montón de componentes hidratándose a la vez. Partir ese trabajo en fragmentos más pequeños, o retrasar lo que no es crítico para la primera interacción, suele bajar el número de forma notable sin tocar la lógica en sí.
Lo que no hago
No persigo el 100 en Lighthouse como un objetivo en sí mismo — es una herramienta de laboratorio, no la experiencia real de un usuario con mala cobertura en el metro. Me fío más de los datos de campo de Search Console, que vienen de usuarios reales, que de una puntuación perfecta en un entorno de pruebas controlado que nadie más ve.