Core Web Vitals: qué son LCP, INP y CLS y cómo mejorarlos

Las tres métricas y sus umbrales

INP reemplazó al FID en marzo de 2024. A diferencia del FID, no mira solo la primera interacción: toma casi la peor de toda la visita.

Datos de campo y datos de laboratorio

Google evalúa con datos de campo: mediciones de visitas reales hechas con Chrome, reunidas en el informe CrUX (Chrome User Experience Report) sobre una ventana móvil de 28 días. Una prueba como Lighthouse, en cambio, es de laboratorio: carga la página una vez, con un equipo y una red simulados. Sirve para diagnosticar, pero no es la nota que cuenta.

Por eso puede pasar que Lighthouse te dé 95 y Search Console marque tus páginas como lentas: tus visitas usan teléfonos más modestos y redes peores que la simulación. Hay más sobre esto en cómo leer una prueba de velocidad. Dónde mirar cada cosa:

• PageSpeed Insights muestra arriba los datos de campo, si tu sitio tiene suficiente tráfico, y abajo el diagnóstico de laboratorio.
• Search Console, en la sección Métricas web principales, agrupa las páginas con problemas y separa celular de computadora.
• Las herramientas de desarrollo de Chrome, en la pestaña Rendimiento, muestran LCP, INP y CLS en vivo mientras usás la página.

LCP: las cuatro partes de un número

El LCP se puede separar en cuatro tramos. Saber cuál es el largo te ahorra horas de pruebas a ciegas:

• Tiempo hasta el primer byte (TTFB): lo que tarda el servidor en empezar a mandar el HTML. Acá pesa el hosting: disco, versión de PHP, caché de página. Conviene que quede por debajo de 0,8 segundos.
• Demora en descubrir el recurso: cuánto pasa hasta que el navegador se entera de que existe la imagen principal. Crece si la imagen la inserta JavaScript o si es un fondo definido en CSS.
• Descarga del recurso: depende del peso. Una foto de 1,5 MB en una red móvil puede llevarse sola más de un segundo.
• Demora de pintado: el recurso llegó, pero algo bloquea el dibujo, como una hoja de estilos pesada o un script sincrónico en el encabezado.

Arreglos concretos para el LCP

• Que la imagen principal esté en el HTML como <img>, con fetchpriority="high" y sin loading="lazy". Diferir la carga de la imagen de arriba de todo es uno de los errores más comunes.
• Servila en WebP o AVIF y en el ancho real en que se muestra, con srcset para que el celular baje la versión chica. Hay más detalle en el peso de las imágenes.
• Poné en línea el CSS mínimo para lo que se ve primero y cargá el resto sin bloquear el pintado.
• Bajá el TTFB con caché de página: en WordPress, un plugin de caché hace que la mayoría de las visitas reciban HTML ya armado, sin ejecutar PHP ni consultar la base.

CLS: que nada se mueva después de aparecer

• Declarale width y height a cada imagen y video, o una proporción con aspect-ratio en CSS. El navegador reserva el lugar antes de que llegue el archivo.
• Reservá un espacio fijo para banners, anuncios e incrustaciones: mapas, videos, formularios de terceros.
• Las fuentes web cambian el tamaño del texto cuando llegan. Usá font-display: swap con una fuente de respaldo ajustada con size-adjust para que ocupe casi lo mismo, o precargá la fuente de los títulos.
• El aviso de cookies o de una promoción tiene que aparecer superpuesto, no empujando la página hacia abajo.
• Animá con transform, que no mueve el diseño; las animaciones que cambian top, height o margin sí lo mueven.

INP: el hilo principal ocupado

Cuando tocás un botón, el navegador tiene que ejecutar el código que responde y volver a pintar. Si en ese momento está ocupado con otra tarea larga de JavaScript, tu toque espera en la fila. Las tareas de más de 50 ms son las sospechosas, y muchas vienen de scripts de terceros: chats, píxeles de publicidad, mapas, reproductores, mapas de calor.

• Hacé un inventario de los scripts de terceros y sacá los que nadie mira.
• Cargá el chat o el mapa recién cuando el usuario toca el botón que lo abre, no al entrar a la página.
• En WordPress, revisá los plugins que cargan JavaScript en todas las páginas aunque se usen en una sola.
• En código propio, partí las tareas largas y dejá lo que no es urgente para después del pintado.

Qué arreglar primero, según lo que ves

La parte que depende del hosting

El servidor influye en un solo tramo, pero es el que va primero: si el HTML tarda un segundo en empezar a llegar, ningún ajuste del diseño baja el LCP de ahí. En el hosting de InHosting los sitios corren sobre discos SSD, con Nginx, HTTP/2 y la versión de PHP que elijas, en un servidor ubicado en Buenos Aires, cerca de un público argentino.

Lo que el hosting no puede arreglar es una portada de 4 MB, diez scripts de publicidad o un tema que dibuja todo con JavaScript. Antes de mudarte buscando velocidad, mirá cuánto pesa tu página de inicio y cuánto tarda el primer byte: esos dos números te dicen si el problema está en el servidor o en el sitio.