El Impacto Real De La Velocidad (En Pesos Argentinos)
Una tienda online en CABA tardaba 5.2 segundos en cargar.
Lentitud: LCP (Largest Contentful Paint) = 5.2s.
Después de optimizar: LCP = 0.9s.
Cambios en el negocio:
- Bounce rate: 62% → 18% (baja de 44 puntos)
- Conversión: 2.1% → 3.8% (+80%)
- AOV (ticket promedio): $4,200 → $5,600 (+33%)
Solo velocidad. Sin cambiar producto, precios, marketing.
¿Cuánto dinero es eso en 30 días? A $5,400 promedio × 30% más conversiones × 1,000 visitas día = ~$486.000 ARS incrementales.
La velocidad no es "nice to have." Es dinero.
Estos números no son teóricos. Según el HTTP Archive Web Almanac 2024, solo el 43% de las páginas web pasan los Core Web Vitals en mobile. El 57% restante está perdiendo ranking y usuarios en este momento.
Las Tres Métricas Que Importan (Core Web Vitals)
Google dice: "Si optimizás estas tres, ya ganas."
1. LCP (Largest Contentful Paint)
¿Qué es? El tiempo hasta que aparece el contenido IMPORTANTE de la página.
Meta: <2.5 segundos.
Mide: ¿Cuán rápido ven los usuarios el contenido principal?
Problema típico en Argentina:
- Sitio que descarga héroe image de 8MB
- JavaScript que tarda 3s en renderizar
- Fuentes que tardan en cargar
Solución rápida:
- Optimizar imágenes (WebP + compresión)
- Lazy load de imágenes under-the-fold
- Inline CSS crítico
- Async JavaScript
2. FID (First Input Delay)
¿Qué es? El tiempo entre que el usuario hace click y el sitio responde.
Meta: <100ms.
Mide: ¿Qué tan responsivo se siente el sitio?
Problema típico:
- JavaScript pesado en main thread
- Tasks de larga duración (>50ms)
- Sin optimización de event listeners
Solución rápida:
- Code splitting
- Defer JavaScript no crítico
- Worker threads
3. CLS (Cumulative Layout Shift)
¿Qué es? Cuánto se mueve el contenido mientras carga.
Meta: <0.1.
Mide: ¿El sitio se "sacude" mientras carga?
Problema típico:
- Imágenes sin dimensions definidas
- Ads que se cargan después (shift el layout)
- Fuentes que cambian tamaño al cargar
Solución rápida:
- Width/height en imágenes
- Reserve space para ads
- Font-display: swap (o preload)
Diagnóstico: Causas Frecuentes de Lentitud
Antes de optimizar, identificá la causa real. Esta tabla cubre el 90% de los problemas que encontramos en auditorías de sitios argentinos:
| Causa | Impacto en LCP | Dificultad de fix | Solución directa |
|-------|---------------|------------------|-----------------|
| Imágenes sin comprimir | Alto (+2-4s) | Baja | Convertir a WebP/AVIF, comprimir a <300KB |
| JavaScript bloqueante en <head> | Alto (+1-3s) | Media | Mover a defer o async |
| Sin caché en servidor | Medio (+0.5-1s) | Baja | Activar Cache-Control: max-age=31536000 |
| Fuentes web sin preload | Medio (+0.3-0.8s) | Baja | <link rel="preload" as="font"> |
| Scripts de terceros (Analytics, Chat, Pixel) | Alto (+1-5s) | Media | Cargar con strategy="lazyOnload" |
| TTFB alto (servidor lento) | Alto (+1-3s) | Alta | CDN (Cloudflare) o upgrade de hosting |
| Bundle JS demasiado grande | Alto (+1-4s) | Alta | Code splitting, tree shaking |
| Sin lazy loading de imágenes | Medio (+0.5-2s) | Baja | Agregar loading="lazy" a imágenes off-screen |
Cómo auditar en 5 minutos: Abrí Chrome DevTools → pestaña Network → recargá la página → filtrá por "Img" y "JS". Si algún archivo pesa más de 500KB, ahí está el problema.
Cómo Encontrar Los Problemas (Herramientas Gratis)
PageSpeed Insights
Ve a: https://pagespeed.web.dev/
Entra tu URL. Te da:
- Score (0-100)
- Problemas específicos
- Oportunidades de mejora
Nota: Es más severo que usuarios reales. Score 65 = "está bien."
Chrome DevTools (Lighthouse)
F12 → Lighthouse tab → Analizar página.
Te da breakdown de dónde se pierden ms.
Pro tip: Simula "Slow 4G" para ver si tu sitio aguanta conexiones malas.
WebPageTest
https://www.webpagetest.org/
Es como Lighthouse pero en 10x detalle.
Perfecto para encontrar "leaks" que no ves en otros tools.
Las 5 Optimizaciones Que Dan Más ROI
1. Optimizar Imágenes (El 80% Del Problema)
Realidad: Una imagen sin optimizar pesa 5-8MB. Optimizada: 150-300KB.
Solución:
Herramienta: TinyPNG, ImageOptim, o WebP converter
Pasos:
1. Exporta PNG/JPG
2. Comprime (pierde ~5% calidad)
3. Convierte a WebP (30-40% más chico)
4. Implementa WebP con fallback:
<picture>
<source srcset="image.webp" type="image/webp">
<img src="image.jpg" alt="...">
</picture>
Impacto: LCP puede mejorar 1-2 segundos solo con esto.
2. Lazy Loading
Las imágenes under-the-fold NO necesitan cargar al iniciar.
<img src="..." loading="lazy" alt="...">
Una línea. Reduce carga inicial 50% en páginas largas.
3. Minify + Compress
CSS: Elimina comentarios, espacios, newlines. JavaScript: Lo mismo. HTML: Minifica también.
Herramientas: Webpack, Gulp, CSSNano.
Ganancia típica: 20-30% menos bytes.
4. Caching
Si usuario vuelve, no descargue TODO otra vez.
Browser cache: Archivos estáticos (imágenes, CSS) cache por 30-365 días.
// .htaccess o headers en serverless
Cache-Control: public, max-age=31536000
CDN: Distribuye contenido desde servidores cerca del usuario.
En Argentina: Cloudflare es mejor que nada.
5. Code Splitting (Si Usas React/Vue)
No mandes TODO el JavaScript en una descarga.
import { lazy, Suspense } from 'react';
const HeavyComponent = lazy(() => import('./Heavy'));
export default function App() {
return (
<Suspense fallback={<div>Loading...</div>}>
<HeavyComponent />
</Suspense>
);
}
Resultado: JavaScript inicial 50% más chico.
Scripts de Terceros: El Problema Invisible
Google Analytics, Facebook Pixel, chat widgets, Hotjar, Microsoft Clarity — cada uno que agregás suma entre 50KB y 500KB de JavaScript extra que se ejecuta en el browser del usuario.
Según Google Chrome Team (2023), los scripts de terceros causan el 57% del tiempo de bloqueo del thread principal en sitios web promedio. Eso significa que más de la mitad del tiempo que un usuario espera antes de poder interactuar con tu sitio, lo está esperando por código que ni siquiera es tuyo.
Auditoría de scripts de terceros:
- Chrome DevTools → pestaña Coverage → recargá la página
- Cualquier script con más de 40-50% de código sin usar es candidato a diferir o eliminar
- La pestaña Network te muestra cuánto pesa cada script externo
Estrategia para Next.js (la correcta):
// MAL: Carga inmediata bloquea rendering
<Script src="https://analytics.com/tag.js" />
// BIEN: Carga después de que el usuario puede interactuar
<Script
src="https://analytics.com/tag.js"
strategy="lazyOnload"
/>
// MEJOR: Solo cargar si es necesario
<Script
src="https://analytics.com/tag.js"
strategy="afterInteractive"
/>
Regla práctica: Google Analytics y Facebook Pixel son afterInteractive. Chat widgets y Hotjar son lazyOnload. Si no podés justificar un script de terceros, eliminalo — cada uno que sacás es tiempo que tu usuario recupera.
Mobile: El 70% Del Tráfico Que Se Optimiza Último
Según el HTTP Archive 2024, el 70.4% del tráfico web global es mobile. En Argentina, donde el uso de datos móviles es la forma principal de acceso a internet para millones de personas, ese porcentaje es igual o mayor.
El problema es que el LCP en mobile es consistentemente 1.5 a 2 veces más lento que en desktop para el mismo sitio, porque:
- Conexiones 4G en Argentina promedian 15-25 Mbps vs 80-120 Mbps de WiFi
- CPUs de teléfonos de gama media ejecutan JavaScript 4-5x más lento que una laptop
- El mismo bundle de 800KB tarda 3 veces más en procesarse en mobile
Optimizaciones específicas para mobile:
<!-- Viewport correcto -->
<meta name="viewport" content="width=device-width, initial-scale=1">
<!-- Fuentes: mínimo 16px para evitar zoom automático en iOS -->
body { font-size: 16px; }
<!-- Touch targets: mínimo 44x44px para dedos reales -->
button { min-height: 44px; min-width: 44px; }
<!-- Imágenes responsive: no servir 1200px a un teléfono de 390px -->
<img
src="image-400.webp"
srcset="image-400.webp 400w, image-800.webp 800w, image-1200.webp 1200w"
sizes="(max-width: 768px) 100vw, 50vw"
alt="..."
/>
La métrica que más importa en mobile: Lighthouse en modo "Moto G4 + Slow 4G". Si tu sitio pasa 90 ahí, está bien para el 95% de usuarios argentinos.
Caso Real: E-commerce Argentino Optimizado
Antes:
- LCP: 4.8s
- JS: 850KB
- Imágenes: 25MB totales
- PageSpeed: 35/100
Optimizaciones hechas:
- Imágenes a WebP + compresión: -18MB
- Code splitting React: -500KB JS
- Lazy load: images after fold
- CDN para estáticos
- Minify + cache headers
Después:
- LCP: 0.9s
- JS: 320KB
- Imágenes: 2MB totales
- PageSpeed: 89/100
Tiempo de trabajo: 20 horas (3 developers × 2.5 días).
ROI: +$486K en 30 días = $4.86M anualizados.
Errores Comunes
Error 1: Obsesionar Con PageSpeed Score
Score 100 no existe. Score 85+ es "excelente." Score 65+ es "bueno."
No hagas cambios radicales por mejorar 5 puntos.
Error 2: Optimizar Sin Medir
Cambias algo, asumir que mejora. Casi siempre empeora.
Siempre: Medir antes, cambiar, medir después.
Error 3: Olvidarse De Mobile
Desktop rápido, mobile lento.
Los usuarios no usan desktop. Optimizá para 4G lento.
FAQ: Lo Que Preguntan
¿Cuánto cuesta optimizar?
Auditoría + plan: $2-5K ARS. Implementación: depende. Puede ser 10 horas o 100.
¿Qué si soy hosting compartido?
Cambiar hosting es opción. Pero 80% de mejoras vienen de código (imágenes, JS), no de hosting.
¿Performance Afecta SEO?
Sí. Google dice que Page Speed es factor de ranking. Probablemente 1-3% del score total.
Pero 100% afecta conversión (user experience).
¿Cada cuánto medir?
Mensual. O después de cambios grandes.
Siguiente Paso: Audita Tu Velocidad
Entra a PageSpeed Insights (arriba).
Si score < 65, es hora de optimizar.
Nosotros hacemos auditorías + implementación de optimizaciones. Somos especialistas en performance en Argentina.
¿Necesitás sitio más rápido?
📧 Email: [email protected]
O conocé nuestro servicio de desarrollo web profesional.
Última actualización: Diciembre 2024 Tiempo de lectura: 11 minutos Dificultad: Intermedia
Preguntas frecuentes
¿Cómo mejorar la velocidad de carga de un sitio web?
Las optimizaciones de mayor impacto son: convertir imágenes a WebP o AVIF (ahorra 30-50% de peso), implementar lazy loading en imágenes fuera del viewport, activar compresión Brotli en el servidor, diferir JavaScript no crítico, usar una CDN y habilitar caché agresivo para assets estáticos. Con estas técnicas combinadas, un sitio que carga en 5 segundos puede pasar a menos de 2 segundos sin cambiar el diseño ni la funcionalidad.
¿Qué son los Core Web Vitals y por qué importan para SEO?
Son las métricas de rendimiento que Google usa como señal de ranking desde 2021. LCP (Largest Contentful Paint) mide velocidad de carga del contenido principal, objetivo menor a 2.5 segundos. INP (Interaction to Next Paint) mide respuesta a interacciones del usuario, objetivo menor a 200ms. CLS (Cumulative Layout Shift) mide estabilidad visual, objetivo menor a 0.1. Sitios que pasan estos umbrales tienen ventaja directa en posicionamiento frente a competidores más lentos.
¿Cuánto tráfico pierde un sitio web lento?
Los datos son contundentes: por cada segundo adicional de carga, la tasa de rebote aumenta 32% (Google/SOASTA), la tasa de conversión cae 7% (Akamai) y el tiempo en página baja 11%. Un sitio que tarda 5 segundos en cargar pierde en promedio el 90% de usuarios respecto a uno que carga en 1 segundo. Para e-commerce, Amazon calculó que cada 100ms de mejora en velocidad equivale a 1% más de ingresos.
¿Qué puntaje de Lighthouse es bueno para un sitio web?
Lighthouse por encima de 90 en Performance, Accessibility, Best Practices y SEO es considerado excelente. Un score de 95+ en Performance coloca al sitio en el 5% superior de velocidad. Para sitios Next.js bien optimizados con imágenes en WebP, SSR, lazy loading y compresión activa, un Lighthouse de 95+ es alcanzable. Scores por debajo de 70 en Performance indican problemas graves que impactan en ranking y conversión.
Escrito por
Agustin Policano
Consultor en desarrollo web y SEO tecnico
Apasionado por crear experiencias digitales excepcionales y compartir conocimiento con la comunidad.