Qué son los Core Web Vitals y cómo mejorarlos

Las tres métricas, en una frase cada una

LCP (Largest Contentful Paint) mide cuánto tarda en aparecer el elemento visible más grande de la pantalla inicial: normalmente una imagen o un titular. Es la métrica de «¿ya ha cargado?» desde el punto de vista de la persona que mira.

INP (Interaction to Next Paint) mide cuánto tarda la página en responder visiblemente cuando alguien pulsa, toca o escribe. Sustituyó al antiguo FID en marzo de 2024, y es más exigente: no mira solo la primera interacción, sino todas.

CLS (Cumulative Layout Shift) mide cuánto se mueve el contenido mientras carga. Es la métrica del botón que se desplaza justo cuando ibas a pulsarlo, y la única de las tres que puede empeorar mucho después del primer segundo.

• LCP bueno: 2,5 segundos o menos
• INP bueno: 200 milisegundos o menos
• CLS bueno: 0,1 o menos
• El umbral se mide en el percentil 75 de las visitas reales, no en la media

Laboratorio y campo no son lo mismo

Aquí se pierde mucha gente. Lighthouse, la pestaña de rendimiento del navegador o PageSpeed Insights en su parte simulada son datos de laboratorio: una ejecución controlada, con una red y un dispositivo fijos. Sirven para diagnosticar, porque te dicen qué está causando qué.

Los datos de campo son otra cosa: son lo que experimentaron personas reales con su móvil y su conexión durante los últimos veintiocho días, recogidos por Chrome y publicados de forma agregada. Es lo que Search Console muestra, y es lo que cuenta a efectos de clasificación.

La consecuencia práctica es que una web puede sacar 100 en Lighthouse y seguir en rojo en Search Console. No es una contradicción: significa que el laboratorio no está reproduciendo las condiciones de tus visitantes, y casi siempre apunta a scripts de terceros que no se cargan en la prueba, a un servidor lento en horas punta o a un público con dispositivos más modestos.

Las causas que aparecen en casi todas las auditorías

Después de unas cuantas auditorías, la lista de sospechosos se repite con una regularidad casi aburrida. Estas son, por orden de frecuencia:

• La imagen del encabezado sin optimizar: en JPEG a 2.400 píxeles de ancho para mostrarse a 800, sin dimensiones declaradas y sin prioridad de carga.
• Tipografías: cuatro o cinco pesos descargados cuando la web usa dos, sin subconjunto latino y sin precarga.
• Scripts de terceros: chat, mapa, píxel de publicidad y herramienta de pruebas A/B, todos bloqueando el hilo principal y ninguno con un responsable claro.
• CSS enorme del que la página usa una fracción, cargado de forma que bloquea el primer pintado.
• Banners de consentimiento que se insertan tarde y empujan el contenido hacia abajo: es la causa número uno de CLS en webs europeas.
• Un servidor que responde lento al documento HTML: si el primer byte tarda un segundo, el LCP ya parte con un segundo perdido.

Por dónde empezar si tienes una tarde

El orden importa, porque el esfuerzo se reparte muy mal. Empieza por la imagen del encabezado de la plantilla con más tráfico: convierte a AVIF o WebP, sírvela al tamaño en que se muestra, declara ancho y alto, y márcala como prioritaria. Es una hora de trabajo y suele mover el LCP más que todo lo demás junto.

Después, el inventario de terceros. Haz una lista de todos los scripts externos y pregunta a quién le sirve cada uno. En casi todos los proyectos aparece al menos uno que nadie usa desde hace dos años y que sigue costando trescientos milisegundos a cada visita.

Y por último, el banner de cookies: reserva su espacio en la maquetación en lugar de dejar que empuje el contenido. Es el arreglo más barato del CLS y el que más agradece cualquiera que use la web con una mano en el metro.

Cómo evitar que se degrade otra vez

Una web optimizada vuelve al rojo sola. Basta con que alguien suba una imagen sin comprimir o con que marketing añada un píxel nuevo. La única defensa que funciona es automatizar la comprobación: un presupuesto de peso por plantilla y una revisión en cada despliegue que falle si se supera.

No hace falta nada sofisticado. Un informe de Lighthouse en la integración continua con umbrales mínimos y un límite de kilobytes por tipo de recurso ya evita el noventa por ciento de las regresiones, porque convierte un problema invisible en un despliegue que no pasa.