La velocidad mata: lo que le cuesta tener una web lenta
Cada 100 ms de tiempo de carga reducen las conversiones cerca de un 1 %. Le mostramos cómo encontrar y arreglar las partes más lentas de su stack.
El tiempo de carga es una cifra de ingresos. No es una métrica técnica: es una cifra de ingresos. Amazon ha publicado que cada 100 ms adicionales de latencia cuestan un 1 % en ventas. Los propios datos de Google muestran que la tasa de rebote sube un 32 % cuando la carga pasa de 1 s a 3 s.
Su sitio es probablemente lento de formas que aún no ha medido.
Los números reales
Largest Contentful Paint (LCP) es la métrica que más correlaciona con la conversión. Umbrales de Google:
- Bueno: por debajo de 2,5 s
- Necesita mejora: 2,5 s-4 s
- Pobre: más de 4 s
La mayoría de los sitios corporativos que auditamos están entre 3 s y 6 s. La diferencia entre 6 s y 2 s no es una victoria de diseño: es una victoria de tasa de conversión que aparece en los ingresos.
A dónde se va el tiempo
Imágenes: las imágenes sin optimizar son el culpable más habitual. Una imagen hero de 4 MB servida a usuarios móviles es un impuesto de 4 MB sobre cada primera impresión.
Scripts de terceros: analítica, widgets de chat, píxeles publicitarios. Cada uno bloquea el renderizado. Un sitio de marketing típico carga entre 8 y 12 scripts de terceros.
Recursos bloqueantes del render: CSS y JS cargados en la cabecera del documento que impiden al navegador pintar nada.
Tiempo de respuesta del servidor (TTFB): si el servidor tarda 800 ms en responder, ninguna optimización de frontend cierra esa brecha.
Renderizado en cliente: las SPA que envían una página HTML vacía y luego se hidratan son inherentemente lentas en la primera carga.
El stack de soluciones
Para la mayoría de los sitios, las correcciones de mayor palanca, en orden:
- Mover a un runtime CDN-edge: Vercel, Cloudflare Pages o equivalente. TTFB por debajo de 100 ms a nivel global.
- Servir imágenes optimizadas: use
next/imageo Cloudflare Image Resizing. WebP, dimensiones correctas, lazy loading. - Diferir scripts no críticos: cargue la analítica y los widgets de chat después de que la página sea interactiva.
- Eliminar CSS bloqueante del render: inline del CSS crítico, defer del resto.
- Cambiar a renderizado en servidor: pre-renderice el HTML para que el usuario vea el contenido al instante.
Medir correctamente
No pruebe el rendimiento desde su oficina con una máquina rápida. Use:
- WebPageTest con conexión móvil 4G acelerada.
- Lighthouse CI en su pipeline de build para detectar regresiones.
- Core Web Vitals en Google Search Console para datos de usuarios reales.
El objetivo es ser visiblemente rápido en un Android de gama media sobre una red móvil congestionada. Todo lo demás es optimizar para una audiencia que no se daría cuenta de todos modos.