Core Web Vitals: qué son, umbrales y cómo mejorarlos

El umbral se evalúa sobre el percentil 75 de las visitas: no alcanza con que la página vaya bien en promedio, tiene que ir bien para tres de cada cuatro personas. Es una diferencia grande cuando buena parte del tráfico llega por redes móviles.

Cuánto importan los Core Web Vitals para el ranking

Menos de lo que sugiere la cantidad de gente que las persigue. Son un factor de ranking confirmado, con peso bajo: entre dos páginas equivalentes en todo lo demás, la más rápida gana. Es la última etapa del diagnóstico técnico, no la primera. Entre una página lenta con la mejor respuesta y una rápida con una respuesta pobre, gana la lenta.

Dicho eso, no son un capricho: el impacto sobre conversión y sobre abandono es mucho más grande que el impacto sobre posiciones, y ese es el argumento que conviene usar internamente.

Dato de campo y dato de laboratorio: no miden lo mismo

Es la confusión que más tiempo hace perder, y conviene resolverla antes de tocar nada.

El dato de campo sale de visitas reales, agregadas a lo largo de semanas. Es lo que aparece en el informe de Search Console y en la parte de arriba de PageSpeed Insights. Es lo que cuenta.

El dato de laboratorio es una simulación: una carga, en un dispositivo simulado, con una conexión simulada. Es el puntaje de 0 a 100 que devuelve la herramienta. No cuenta para nada en la evaluación, y una página puede tener 98 en laboratorio y estar en rojo en campo.

Sirven para cosas distintas. El campo dice si tenés un problema; el laboratorio ayuda a encontrar dónde está. Usar el segundo para lo primero lleva a celebrar arreglos que nadie experimentó.

Cómo mejorar el LCP: las 5 causas en orden de frecuencia

Las causas, en el orden en que aparecen en la práctica:

1. El servidor tarda en contestar. Si la primera respuesta demora, todo lo demás arranca tarde. Se ve como un TTFB alto y suele resolverse con caché o con un alojamiento mejor, no tocando la página.
2. Hay CSS o JavaScript bloqueando el pintado. El navegador no dibuja nada hasta terminar de procesarlos. Los que no hacen falta para la primera pantalla no deberían bloquear.
3. La imagen principal pesa de más o carga tarde. Formato moderno, tamaño real del que se muestra, y —el error clásico— no poner carga diferida al elemento que justamente es el LCP.
4. La página se arma con JavaScript en el navegador. El contenido principal no existe hasta que el script terminó de correr.
5. Las fuentes retrasan el texto. Si el texto es el elemento más grande, esperar la fuente es esperar el LCP.

Cómo mejorar el INP: el hilo principal está ocupado

INP mide desde que alguien toca algo hasta que la pantalla cambia. Casi siempre hay una única causa de fondo: el hilo principal está ocupado y no puede atender.

• Scripts de terceros. Etiquetas de analítica, chats, píxeles de publicidad. Es la causa más frecuente y la que menos se controla desde el propio código.
• Tareas largas propias. Cálculos o renderizados que bloquean por cientos de milisegundos en vez de partirse en pedazos.
• DOM enorme. Cuantos más nodos, más caro es cada cambio.
• Manejadores de eventos caros. El clic dispara trabajo pesado antes de mostrar cualquier señal visual.

Un atajo que casi siempre paga: mostrar la reacción visual primero —el botón se marca como presionado— y hacer el trabajo después.

Cómo mejorar el CLS: 4 causas y sus arreglos

Esta es la más barata de arreglar y la que peor experiencia genera cuando está mal.

• Imágenes y videos sin dimensiones declaradas. El navegador no sabe cuánto espacio reservar y empuja todo cuando llegan. Es dos atributos, y arregla una métrica entera: está con el resto en optimizar imágenes.
• Anuncios, banners o incrustaciones sin espacio reservado. Mismo problema, con más altura.
• Fuentes que cambian al cargar. El texto se redibuja con otra métrica y mueve lo de abajo.
• Contenido insertado arriba de lo que ya se veía. Avisos de cookies, barras de promoción, mensajes de error.

La referencia de cada métrica está en web.dev: Web Vitals e INP. Google explica su peso en experiencia en la página.

En qué orden arreglar los Core Web Vitals

1. Mirá el dato de campo y separá por plantilla. Rara vez el problema es «el sitio»: suele ser un tipo de página. Search Console agrupa URLs parecidas justamente para eso.
2. Arreglá CLS primero. Es lo más barato, casi siempre son dimensiones faltantes, y el resultado se ve entero.
3. Después LCP. Empezá por el tiempo de respuesta del servidor y por la imagen principal, que juntos explican la mayoría de los casos.
4. INP al final. Es el más caro, porque suele exigir sacar o aplazar scripts que alguien del equipo puso ahí por una razón.
5. Volvé a medir en campo, semanas después. No antes, por lo que dice la nota de arriba.

Lo que se arregla en una tarde: dimensiones de imágenes, espacio reservado, carga diferida bien puesta, formato de imágenes. Lo que requiere tocar la arquitectura: renderizado en el navegador, la pila de etiquetas de terceros, el tiempo de respuesta del servidor. Conviene saber en cuál de los dos grupos está el problema antes de prometer una fecha.