Velocidad web: por qué cada segundo de retraso te cuesta clientes y cómo medirlo con datos reales

Los datos que la industria repite y de dónde vienen

Probablemente has escuchado algo como "un segundo de retraso reduce las conversiones en un 7%". Esa cifra viene de un estudio de Akamai de 2009. Sigue siendo citada porque se acerca bastante a lo que estudios más recientes confirman en distintos contextos.

Lo que sabemos con más certeza hoy:

• Google reportó en 2017 que las páginas que cargan en más de 10 segundos en mobile tienen 123% más probabilidad de rebote que las que cargan en 1 segundo.
• Deloitte publicó en 2020 que mejorar la velocidad de una página en 0.1 segundos puede aumentar las conversiones entre un 8% y un 10%.
• Cloudflare midió que un aumento de 1 segundo en el TTFB se correlaciona con una reducción del 11% en el tráfico orgánico.

Ningún número aplica igual a todos los negocios. Pero la dirección es inequívoca: más lento siempre es peor.

Las métricas que Google mide y que tú debes conocer

LCP — Largest Contentful Paint

El tiempo que tarda en aparecer el elemento más grande visible. Suele ser tu imagen hero o tu título principal. Objetivo: menor a 2.5 segundos. Para optimizarlo: preload de la imagen hero, formato WebP u AVIF, no usar lazy loading en el LCP, compresión adecuada.

INP — Interaction to Next Paint

El tiempo que tarda la página en responder visualmente cuando el usuario hace clic, toca o escribe. Objetivo: menor a 200ms. Para optimizarlo: reducir JavaScript largo en el hilo principal, diferir tareas no urgentes con requestIdleCallback, usar Web Workers para procesamiento pesado.

CLS — Cumulative Layout Shift

Cuánto se mueven los elementos de la página mientras carga. Objetivo: menor a 0.1. Para optimizarlo: declarar siempre las dimensiones de imágenes y videos en el HTML (width y height), reservar espacio para ads y embeds, no insertar contenido dinámico por encima del contenido existente.

TTFB — Time to First Byte

No es una métrica oficial de Core Web Vitals, pero Google la usa como señal de "responsiveness". Es el tiempo desde que el navegador hace la solicitud hasta que llega el primer byte de respuesta del servidor. Un TTFB alto indica problemas de hosting, código lento en el servidor, o falta de caché. Objetivo: menor a 800ms.

Las mejoras con mayor impacto en proyectos reales

1. Cambiar a hosting adecuado

El 40% de los problemas de velocidad que vemos en auditorías tienen una sola causa: hosting barato con TTFB de 3 a 5 segundos. No hay optimización front-end que resuelva un servidor lento. Un VPS bien configurado en una región cercana a tus usuarios (Colombia → AWS São Paulo o us-east) puede reducir el TTFB de 3 segundos a 200ms de golpe.

2. Imágenes en formato moderno con dimensiones declaradas

La imagen promedio representa el 50-70% del peso de una página web. Convertir todas las imágenes a WebP o AVIF puede reducir ese peso entre un 25% y un 50% sin pérdida perceptible de calidad. Más el atributo width y height en el HTML que elimina el CLS causado por imágenes.

3. Critical CSS inline

El CSS de los primeros 100px de tu página (above the fold) debe estar inline en el head. El resto, diferido. Esto permite que el navegador pinte la pantalla inicial sin esperar a que descargue la hoja de estilos completa.

4. Diferir JavaScript no crítico

Analytics, chat widgets, redes sociales, mapas —nada de esto debe bloquear el render inicial. Todo con defer o async. Los chat widgets de terceros especialmente: pueden añadir 500ms al INP por sí solos si se cargan antes de que la página sea interactiva.

Cómo medimos en Trement

Usamos datos de campo (CrUX dataset de Google) para conocer la experiencia real de los usuarios, no solo la del laboratorio. PageSpeed Insights y el reporte de Core Web Vitals de Search Console son nuestras fuentes de verdad. Para análisis más profundos, WebPageTest con perfil de conexión 4G Colombia.