5 min lectura • Guide 749 of 877
Optimización de Performance en Desarrollo
Performance es una feature. GitScrum ayuda a equipos a trackear trabajo de performance junto con desarrollo de features y mantener budgets de performance.
Mentalidad de Performance
IMPACTO DE PERFORMANCE
══════════════════════
EXPERIENCIA DE USUARIO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ Load time Percepción del usuario │
│ ─────────── ────────────────────────────────────────── │
│ 0-100ms Instantáneo │
│ 100-300ms Leve retraso, aceptable │
│ 300-1000ms Notable, aún OK │
│ 1-3s Lento, usuarios notan │
│ 3-10s Frustrante, usuarios se van │
│ >10s Inutilizable │
│ │
└─────────────────────────────────────────────────────────────┘
IMPACTO DE NEGOCIO:
┌─────────────────────────────────────────────────────────────┐
│ │
│ • 1 segundo de retraso = 7% drop en conversión │
│ • 53% usuarios móviles abandonan si > 3 segundos │
│ • Google rankea sitios rápidos más alto │
│ • Lento = percibido como no confiable │
│ │
└─────────────────────────────────────────────────────────────┘
ANTI-PATRONES:
┌─────────────────────────────────────────────────────────────┐
│ │
│ ❌ "Optimizaremos después" │
│ → Deuda técnica se acumula │
│ → Más difícil arreglar cuando arquitectura está fija │
│ │
│ ❌ "La optimización prematura es mala" │
│ → Cita mal entendida │
│ → No micro-optimices, pero diseña para performance │
│ │
│ ❌ "Es rápido en mi máquina" │
│ → Testea en dispositivos y conexiones reales │
│ │
└─────────────────────────────────────────────────────────────┘
Budgets de Performance
DEFINIENDO BUDGETS
══════════════════
EJEMPLO DE BUDGETS:
┌─────────────────────────────────────────────────────────────┐
│ │
│ WEB APP: │
│ ├── First Contentful Paint: < 1.5s │
│ ├── Largest Contentful Paint: < 2.5s │
│ ├── Time to Interactive: < 3.5s │
│ ├── Total Bundle Size: < 200KB gzipped │
│ └── Largest Image: < 100KB │
│ │
│ API: │
│ ├── Response time p95: < 200ms │
│ ├── Response time p99: < 500ms │
│ └── Error rate: < 0.1% │
│ │
│ DATABASE: │
│ ├── Query time: < 50ms │
│ └── No N+1 queries │
│ │
└─────────────────────────────────────────────────────────────┘
ENFORCEMENT:
┌─────────────────────────────────────────────────────────────┐
│ │
│ EN CI/CD: │
│ ├── Lighthouse CI check │
│ ├── Bundle size check │
│ └── Performance test suite │
│ │
│ Si excede budget: │
│ ├── Build falla │
│ ├── O warning prominente │
│ └── Debe resolverse antes de merge │
│ │
└─────────────────────────────────────────────────────────────┘
Identificando Bottlenecks
PROCESO DE ANÁLISIS
═══════════════════
PASO 1: MEDIR
┌─────────────────────────────────────────────────────────────┐
│ │
│ Herramientas: │
│ ├── Chrome DevTools / Lighthouse │
│ ├── WebPageTest │
│ ├── APM (Datadog, New Relic) │
│ └── Profilers del lenguaje │
│ │
│ NO adivines. MIDE. │
│ │
└─────────────────────────────────────────────────────────────┘
PASO 2: IDENTIFICAR TOP ISSUES
┌─────────────────────────────────────────────────────────────┐
│ │
│ Típicos culpables: │
│ ├── N+1 queries │
│ ├── Imágenes no optimizadas │
│ ├── JavaScript bloqueante │
│ ├── APIs lentas │
│ ├── Falta de caching │
│ └── Serialización ineficiente │
│ │
└─────────────────────────────────────────────────────────────┘
PASO 3: PRIORIZAR
┌─────────────────────────────────────────────────────────────┐
│ │
│ IMPACTO vs ESFUERZO: │
│ │
│ Alto impacto + Bajo esfuerzo → HACER PRIMERO │
│ Alto impacto + Alto esfuerzo → Planificar │
│ Bajo impacto + Bajo esfuerzo → Quick wins │
│ Bajo impacto + Alto esfuerzo → Evitar │
│ │
└─────────────────────────────────────────────────────────────┘
Tracking en GitScrum
STORIES DE PERFORMANCE
══════════════════════
TEMPLATE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ Story: Optimizar carga de página de productos │
│ │
│ ESTADO ACTUAL: │
│ ├── LCP: 4.2s │
│ ├── FCP: 2.8s │
│ └── Bundle: 450KB │
│ │
│ OBJETIVO: │
│ ├── LCP: < 2.5s │
│ ├── FCP: < 1.5s │
│ └── Bundle: < 200KB │
│ │
│ ACCEPTANCE CRITERIA: │
│ ├── ☐ Imágenes lazy loaded │
│ ├── ☐ JavaScript code-split │
│ ├── ☐ CSS critical inline │
│ └── ☐ Métricas verificadas en Lighthouse │
│ │
│ Labels: ⚡performance, 📊measurable │
│ │
└─────────────────────────────────────────────────────────────┘
BURNDOWN DE PERFORMANCE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ Target: LCP < 2.5s │
│ │
│ Sprint 1: 4.2s (baseline) │
│ Sprint 2: 3.8s (optimizó imágenes) │
│ Sprint 3: 3.1s (code splitting) │
│ Sprint 4: 2.4s (caching) ✅ │
│ │
└─────────────────────────────────────────────────────────────┘
Balance Performance vs Features
ASIGNACIÓN DE CAPACIDAD
═══════════════════════
REGLA GENERAL:
┌─────────────────────────────────────────────────────────────┐
│ │
│ Sprint típico: │
│ ├── 70-80% Features │
│ ├── 10-15% Tech debt + Performance │
│ └── 10-15% Bugs + Mantenimiento │
│ │
│ Si hay problemas de performance: │
│ └── Aumentar % temporalmente │
│ │
└─────────────────────────────────────────────────────────────┘
TRATANDO PERFORMANCE COMO REQUIREMENT:
┌─────────────────────────────────────────────────────────────┐
│ │
│ Feature: Página de checkout │
│ │
│ Requirements: │
│ ├── [Funcional] Usuario puede completar compra │
│ ├── [Funcional] Acepta múltiples formas de pago │
│ └── [Performance] Carga en < 2s en 3G │
│ │
│ La feature NO está completa si performance no cumple │
│ │
└─────────────────────────────────────────────────────────────┘