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

La velocidad es la única mejora de calidad cuyo argumento de negocio no hay que defender. Una web lenta pierde a la gente antes de que lea una palabra, y a quien pierde es desproporcionadamente al que está en el móvil, con datos, y te encontró en un buscador — es decir, clientes nuevos.

Google mide esto con tres números, recogidos de usuarios reales de Chrome y no de una prueba de laboratorio. Estos son, y esto es lo que de verdad los mueve.

Los tres números

Largest Contentful Paint (LCP) — cuánto tarda en aparecer el elemento más grande de la pantalla. Normalmente una imagen principal o un titular. Bien es por debajo de 2,5 segundos. Es la métrica del "¿ya está?" y la que más pesa en si alguien se queda.

Interaction to Next Paint (INP) — cuando alguien toca o hace clic, cuánto tarda la página en responder visiblemente. Bien es por debajo de 200 milisegundos. Sustituyó al antiguo First Input Delay porque mide todas las interacciones, no solo la primera, lo que resultó ser un retrato mucho más justo.

Cumulative Layout Shift (CLS) — cuánto se mueve la página mientras carga. Bien es por debajo de 0,1. Es la métrica detrás de esa experiencia universal de ir a pulsar un botón y que un anuncio te lo aparte de debajo del dedo.

El umbral es que el 75 por ciento de las visitas alcance "bien". No te evalúan por tu media, sino por si la mayoría tuvo una experiencia decente.

Qué los rompe normalmente

En nuestra experiencia las causas son aburridamente constantes.

El LCP casi siempre son las imágenes. Una foto de 3 MB servida a resolución completa a un móvil, sin formato moderno y sin dimensiones. Las soluciones son poco lucidas: servir WebP o AVIF, ajustar la imagen a lo que realmente se muestra, marcar la principal como prioritaria y no cargarla nunca en diferido, y cargar en diferido todo lo que queda bajo la línea de flotación.

La segunda causa son los recursos que bloquean el pintado — una hoja de estilos o una tipografía que el navegador tiene que descargar antes de dibujar nada. Alojar las tipografías uno mismo y poner en línea el poco CSS de la primera pantalla suele arreglarlo.

El INP casi siempre es JavaScript. Demasiado, ejecutándose en el hilo principal e impidiendo que el navegador responda. La pregunta honesta en la mayoría de webs de pyme es cuánto de ese JavaScript hace algo que el visitante haya pedido. Una librería de carrusel, tres scripts de seguimiento, un chat y un framework de animación suman con facilidad un segundo de hilo principal bloqueado en un Android de gama media.

El CLS casi siempre son dimensiones que faltan. Imágenes e iframes sin ancho y alto, tipografías web que se intercambian y recolocan el texto, banners inyectados arriba después de cargar, y contenido que se expande cuando termina un script. Reserva el espacio antes de llenarlo y el problema desaparece.

Qué mueve de verdad los números

Más o menos por orden de rentabilidad:

1. Arregla la imagen principal. Formato correcto, tamaño correcto, prioridad alta, dimensiones explícitas. Este único cambio a menudo pasa por sí solo un LCP suspendido a verde.
2. Borra el JavaScript que no usas. Cada script eliminado ayuda dos veces: menos que descargar y menos que ejecutar. Empieza por las etiquetas de analítica y marketing que nadie ha mirado en un año.
3. Renderiza en el servidor. Si la página llega como HTML en vez de como una cáscara vacía que rellena JavaScript, has eliminado la mayor fuente individual de retraso. Es la razón principal por la que construimos con un framework que renderiza en servidor.
4. Aloja las tipografías tú y carga como mucho dos pesos. Una petición de tipografía a un tercero es una conexión entera más antes de que pueda aparecer texto.
5. Reserva sitio para todo lo que carga tarde. Imágenes, incrustaciones, anuncios, banners de cookies.
6. Sirve desde cerca de tus visitantes. Una empresa holandesa en un servidor de Estados Unidos paga un viaje de ida y vuelta en cada petición sin ningún motivo.

Mídelo bien

Dos herramientas, y la diferencia entre ellas importa.

PageSpeed Insights te da una puntuación de laboratorio y, si tienes tráfico suficiente, los datos de campo de usuarios reales de Chrome. Los datos de campo son los que cuentan para el buscador; la puntuación de laboratorio es un diagnóstico.

Search Console tiene un informe de Core Web Vitals que agrupa a tus usuarios reales por tipo de página. Ese es el de fiar, porque mide a tus visitantes de verdad en sus dispositivos de verdad.

Un aviso que conviene repetir: no persigas el 100. Una puntuación de laboratorio de 100 en una página que los usuarios reales encuentran lenta no vale nada, y los últimos puntos suelen costar más de lo que devuelven. Ponte en verde en los datos de campo y dedica el esfuerzo restante al contenido.

¿Es realmente un factor de posicionamiento?

Sí, y conviene ser preciso sobre cuánto. Los Core Web Vitals forman parte de las señales de experiencia de página de Google. Son reales pero modestos comparados con la relevancia y la calidad del contenido. Una página rápida que no dice nada no va a superar a una lenta que responde la pregunta.

Donde la velocidad decide de verdad es entre páginas de calidad parecida — que es la mayoría de las búsquedas competidas — y, mucho más importante, en lo que pasa después del clic. Las páginas rápidas retienen a más de los que llegan. Ese efecto es bastante mayor que el de posicionamiento, y se produce mire Google o no.

La versión corta

Arregla tus imágenes, borra el JavaScript que no necesitas, renderiza en el servidor y reserva espacio para lo que carga tarde. Ahí está casi todo el trabajo. Después mide con datos de campo y para cuando estés en verde, porque lo siguiente que hagas con esa hora valdrá más que otros dos puntos.