Core Web Vitals: Por Qué Gana la Web Rápida

La mayoría de visitantes decide si se queda en una web en los primeros segundos. Google lo sabe, y por eso la velocidad forma parte de su algoritmo de posicionamiento a través de unas métricas llamadas Core Web Vitals.

La respuesta corta

Hay tres cifras que cumplir: Largest Contentful Paint por debajo de 2,5 segundos, Interaction to Next Paint por debajo de 200 milisegundos y Cumulative Layout Shift por debajo de 0,1. Se miden sobre visitas reales desde dispositivos reales, no en un laboratorio, y puedes comprobar tu web gratis en unos minutos.

Las tres métricas, en cristiano

LCP — Largest Contentful Paint. Cuánto tarda en aparecer lo principal de la página: normalmente la imagen o el titular de cabecera. Es la métrica que el visitante vive como «¿esto carga o no?». Por debajo de 2,5 segundos es bueno; por encima de 4, malo.

INP — Interaction to Next Paint. Con qué rapidez responde la página cuando alguien toca, hace clic o escribe. Sustituyó al First Input Delay en marzo de 2024 porque el FID solo medía la primera interacción, lo que favorecía a webs que después iban pesadas. Por debajo de 200 milisegundos es bueno.

CLS — Cumulative Layout Shift. Cuánto se mueve la página mientras carga. Es la métrica culpable de que toques el botón equivocado porque una imagen empujó la maquetación en el último momento. Por debajo de 0,1 es bueno.

Por qué esto importa comercialmente

El efecto en posicionamiento es real pero moderado: Google usa la velocidad como criterio de desempate, no como as en la manga. El efecto en conversión es el que paga el trabajo.

Cada segundo de más antes de que la página sea usable te cuesta visitantes que nunca te dirán que se fueron. Un pago lento, un formulario lento, una galería lenta: cada uno pierde clientes en silencio. Y, a diferencia de un problema de diseño, no recibes ningún aviso. Nadie escribe para decir que tu web iba lenta; simplemente pasan al siguiente resultado.

Hay un efecto de segundo orden. Las webs lentas parecen baratas. Quien compara tres proveedores se forma una idea de tu competencia por cómo se comporta la web, mucho antes de leer tus credenciales.

Cómo medir la tuya con honestidad

Dos herramientas, ambas gratuitas, y responden a preguntas distintas.

• PageSpeed Insights hace una prueba de laboratorio y, si tienes tráfico suficiente, muestra tus datos de campo reales del Chrome User Experience Report. Los datos de campo son los que Google usa de verdad.
• Las DevTools de Chrome, pestaña Lighthouse, con la limitación activada. Usa «Slow 4G» y una CPU 4 veces más lenta. Eso se aproxima a un Android de gama media, que es como llega buena parte de tus visitantes.

El error habitual es probar en un escritorio con la fibra de la oficina y concluir que la web va rápida. Va rápida para ti. Pruébala como navegan tus clientes.

Los cinco culpables de siempre

Por nuestra experiencia, casi toda web de empresa lenta falla por una de estas razones, más o menos en este orden de impacto:

• Imágenes demasiado grandes. Una foto de 3 MB que el navegador reduce se sigue descargando como 3 MB. Servir formatos modernos (WebP o AVIF) al tamaño que realmente se muestra suele recortar el peso de la página entre un 60 % y un 80 %.
• Scripts de terceros. Widgets de chat, rastreadores, píxeles publicitarios, mapas incrustados, sellos de reseñas. Cada uno es código del servidor de otro que ni controlas ni puedes optimizar. Cinco de ellos pesan más que toda tu web.
• Plantillas infladas. Los temas comerciales incluyen el código de cualquier función que pudieran llegar a necesitar. Te lo descargas entero, lo use tu web o no.
• Tipografías y CSS que bloquean el pintado. Una fuente propia cargada de forma ingenua deja el texto invisible hasta que llega el fichero.
• Imágenes y elementos incrustados sin dimensiones. Es la causa habitual de un mal CLS: el navegador no sabe cuánto espacio reservar, así que todo se desplaza cuando la imagen por fin llega.

Qué hacemos nosotros

Construimos rápido desde el principio, porque añadir rendimiento después sale mucho más caro que diseñarlo:

• Formatos de imagen modernos, generados automáticamente en los tamaños que cada maqueta usa de verdad, siempre con ancho y alto declarados
• HTML renderizado en el servidor, para que el contenido se vea antes de que cargue JavaScript
• Código dividido por página, para que el navegador descargue solo lo que esa página necesita
• Tipografías cargadas sin bloquear el primer pintado
• Scripts de terceros cuestionados uno a uno: cada uno tiene que ganarse su peso
• Cada compilación medida contra los objetivos de Core Web Vitals en un perfil móvil limitado antes de publicar

Si tu web actual va lenta

La buena noticia es que el trabajo de rendimiento tiene un retorno altísimo y no siempre hace falta rehacerla. En una web existente, comprimir y redimensionar imágenes, quitar dos o tres scripts externos que no usas y declarar las dimensiones de los medios suele llevarte casi todo el camino. Mide primero, arregla lo más gordo, vuelve a medir.

Una web rápida no es un lujo. Es la diferencia entre un visitante que se convierte en cliente y otro que ya se ha ido.