La mayoría de los visitantes no abandonan una página lenta porque odien la marca. La abandonan porque esperar se siente como fricción, y la fricción en la primera pantalla mata la conversión. Los Core Web Vitals son el intento de Google de medir esa fricción de una forma que tanto desarrolladores como propietarios del sitio puedan debatir.
Las tres métricas, traducidas
LCP, Largest Contentful Paint
Cuánto tarda en aparecer el contenido principal de la página. Para la mayoría de los sitios, esto es la imagen principal, el encabezado principal o la primera foto de producto. Un buen LCP se siente rápido; un mal LCP se siente como si la página todavía estuviera pensando.
INP, Interaction to Next Paint
Cómo de receptiva se siente la página cuando intentas interactuar con ella, hacer clic en un botón, desplegar un menú, abrir filtros. Un mal INP se siente como si la página te ignorara por un instante.
CLS, Cumulative Layout Shift
Cuánto salta el contenido mientras la página se carga. Un mal CLS es la sensación de ir a por un botón y ver cómo se mueve a otro sitio, normalmente porque un anuncio, una imagen o un banner se cargaron tarde.
Por qué estas métricas afectan al negocio, no solo al SEO
- Un primer renderizado lento hace que la gente cierre la pestaña antes de que aparezca el contenido.
- Las interacciones poco receptivas hacen que formularios, filtros y pagos se sientan rotos.
- Los saltos de diseño provocan clics erróneos, que generan frustración, devoluciones y tickets de soporte.
- Google usa estas métricas como señal de posicionamiento, así que un rendimiento pobre también reduce con qué frecuencia te encuentran de entrada.
El impacto es acumulativo: los pequeños problemas de rendimiento se suman a lo largo de las sesiones, y las pequeñas mejoras también se acumulan.
Qué suele marcar la mayor diferencia
- Imágenes. Con el tamaño correcto, formatos modernos (WebP/AVIF), con carga diferida por debajo del pliegue, y con dimensiones explícitas para que el navegador no tenga que adivinar.
- Fuentes. Limítalas a las que realmente usas, alójalas tú mismo cuando sea posible, y precarga la que renderiza el texto principal.
- Scripts de terceros. Analítica, widgets de chat, herramientas de A/B y gestores de etiquetas suelen ser la mayor fuente de INP lento. Cárgalos de forma diferida, y solo en las páginas donde se necesiten.
- JavaScript no utilizado. Enviar menos código significa menos análisis, menos ejecución, menos energía en dispositivos modestos.
- Tiempo de respuesta del servidor. Un backend lento pone un suelo a todo lo demás. La caché, la optimización de consultas y un nivel de alojamiento sensato importan.
- Espacio reservado. Usa anchura/altura explícitas o relaciones de aspecto CSS para imágenes, anuncios, iframes y banners de modo que el diseño no salte después.
Errores habituales
- Medir solo en tu propio portátil rápido. Los usuarios están en redes móviles y dispositivos de gama media. Usa datos de campo (monitorización de usuarios reales) junto a las pruebas de laboratorio.
- Perseguir un único número. Una puntuación de Lighthouse perfecta en una ejecución no significa gran cosa; sí lo hacen métricas de campo consistentes a lo largo de semanas.
- Añadir herramientas para arreglar el rendimiento. Más scripts rara vez hacen que un sitio sea más rápido.
- Tratar el rendimiento como algo de una sola vez. Sin monitorización, retrocede cada vez que el equipo añade un nuevo widget.
Una secuencia sensata
- Obtén datos de campo de referencia para LCP, INP y CLS en tus 5 páginas principales.
- Arregla primero la imagen principal y el encabezado principal, afectan desproporcionadamente al LCP.
- Audita los scripts de terceros; elimina o difiere cualquier cosa que no sea estrictamente necesaria.
- Reserva espacio para imágenes, anuncios y elementos de carga tardía.
- Monitoriza de forma continua, y trata las regresiones como errores.
