El Impacto del Rendimiento en el Negocio
El rendimiento impacta directamente ingresos y engagement. Páginas más lentas llevan a mayores tasas de rebote y menor conversión. QA juega un rol crítico estableciendo budgets, monitoreando regresiones y verificando que las técnicas de optimización funcionen correctamente.
Técnicas de Optimización a Probar
Optimización de Imágenes
| Técnica | Qué Probar |
|---|---|
| Formatos modernos (WebP, AVIF) | Imágenes servidas en formato moderno con fallback |
| Imágenes responsive (srcset) | Tamaño correcto para viewport del dispositivo |
| Lazy loading | Imágenes bajo el fold cargan al hacer scroll |
| Compresión | Comprimidas sin pérdida visible de calidad |
| Dimensiones correctas | Atributos width/height (previene CLS) |
Optimización de JavaScript
| Técnica | Qué Probar |
|---|---|
| Code splitting | Solo código de la ruta actual carga en cada página |
| Tree shaking | Código no usado eliminado de producción |
| Minificación | Archivos JS minificados en producción |
| Carga defer/async | Scripts no críticos no bloquean renderizado |
Performance Budgets
| Métrica | Budget Ejemplo |
|---|---|
| Peso total de página | <500KB |
| JavaScript | <150KB |
| CSS | <50KB |
| Imágenes | <200KB por página |
| LCP | <2.5s |
| TBT | <200ms |
Análisis Waterfall
El gráfico waterfall en DevTools muestra la secuencia de carga. Busca: TTFB largo, recursos que bloquean renderizado, recursos grandes, cadenas de dependencias, y scripts de terceros como cuellos de botella.
Ejercicio: Auditoría de Optimización de Rendimiento
Paso 1: Establecer Línea Base
| Métrica | Valor | Budget | Pasa/Falla |
|---|---|---|---|
| Peso total | KB | <500KB | |
| Bundle JS | KB | <150KB | |
| CSS | KB | <50KB | |
| Solicitudes | <50 | ||
| LCP | s | <2.5s | |
| TBT | ms | <200ms |
Paso 2: Auditoría de Imágenes
| Verificación | Pasa/Falla |
|---|---|
| Imágenes usan WebP o AVIF | |
| srcset responsive implementado | |
| Imágenes bajo el fold con lazy loading | |
| Imagen hero carga eager (sin lazy) | |
| Todas las imágenes con width/height |
Paso 3: Auditoría de JavaScript
| Verificación | Pasa/Falla |
|---|---|
| Code splitting implementado | |
| Archivos JS minificados | |
| Sin scripts bloqueantes en head | |
| Scripts de terceros async |
Solución: Auditoría de Rendimiento de Ejemplo
Línea base: Peso total 2.3MB (FALLA), JS 450KB (FALLA), LCP 4.2s (FALLA)
Principales cuellos de botella:
- Imagen hero: 1.4MB PNG → WebP (ahorro ~1.1MB)
- JavaScript: bundle único 450KB → Code-split (ahorro ~300KB inicial)
- Widget de chat: 200KB síncrono → Cargar bajo interacción
Después de optimización:
- Peso total: ~480KB
- JS: ~150KB inicial
- LCP: ~2.0s
Prioridad: Imágenes WebP → lazy loading → code split → diferir terceros → budgets en CI
Puntos Clave
- Testing de rendimiento debe ser continuo, no puntual — usa performance budgets en CI/CD
- Las imágenes son la mayor oportunidad de optimización (50-70% del peso)
- Code splitting y lazy loading reducen peso inicial sin eliminar funcionalidades
- El análisis waterfall identifica los recursos específicos que causan cuellos de botella
- Scripts de terceros son un costo oculto común — cárgalos asincrónicamente
- Siempre prueba rendimiento en móvil con CPU y red limitados