6 min leitura • Guide 754 of 877
Otimização de Performance no Desenvolvimento
Performance é uma feature. GitScrum ajuda times a rastrear trabalho de performance junto com desenvolvimento de features e manter budgets de performance.
Mentalidade de Performance
Por que Performance Importa
IMPACTO DE PERFORMANCE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ EXPERIÊNCIA DO USUÁRIO: │
│ │
│ Tempo de carga Percepção do usuário │
│ ────────────── ────────────────────────────────────── │
│ 0-100ms Instantâneo │
│ 100-300ms Leve delay, aceitável │
│ 300-1000ms Perceptível, ainda OK │
│ 1-3s Lento, usuários percebem │
│ 3-10s Frustrante, usuários saem │
│ >10s Inutilizável │
│ │
│ IMPACTO NO NEGÓCIO: │
│ │
│ • 1 segundo de delay = 7% queda em conversão │
│ • 53% usuários mobile saem se > 3 segundos │
│ • Google rankeia sites mais rápidos melhor │
│ • Lento = percebido como não confiável │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ ANTI-PADRÕES DE PERFORMANCE: │
│ │
│ ❌ "Vamos otimizar depois" │
│ → Dívida técnica acumula │
│ → Mais difícil de corrigir quando arquitetura está definida│
│ │
│ ❌ "Otimização prematura é o mal" │
│ → Citação mal entendida │
│ → Não micro-otimize, mas projete para performance │
│ │
│ ❌ "É rápido na minha máquina" │
│ → Teste em dispositivos e conexões reais │
│ → Use monitoramento de performance │
└─────────────────────────────────────────────────────────────┘
Budgets de Performance
Definindo Budgets
DEFININDO BUDGETS DE PERFORMANCE:
┌─────────────────────────────────────────────────────────────┐
│ │
│ BUDGETS FRONTEND: │
│ │
│ Métrica Budget Atual Status │
│ ───────────────── ────────── ──────── ────── │
│ LCP (Largest Paint) < 2.5s 2.1s ✅ OK │
│ FID (Input Delay) < 100ms 85ms ✅ OK │
│ CLS (Layout Shift) < 0.1 0.05 ✅ OK │
│ Bundle size (JS) < 300KB 285KB ⚠️ Perto limit│
│ Bundle size (CSS) < 50KB 42KB ✅ OK │
│ Peso total página < 1MB 920KB ⚠️ Perto limit│
│ │
│ BUDGETS API: │
│ │
│ Endpoint Budget p95 Status │
│ ───────────────── ────────── ───────── ────── │
│ GET /api/users < 200ms 180ms ✅ OK │
│ GET /api/projects < 300ms 420ms ❌ Acima │
│ POST /api/tasks < 500ms 350ms ✅ OK │
│ Search endpoint < 1s 1.2s ❌ Acima │
│ │
│ ─────────────────────────────────────────────────────────── │
│ │
│ QUANDO BUDGET EXCEDIDO: │
│ │
│ 1. Flag no pipeline CI/CD │
│ 2. Criar tarefa de performance no GitScrum │
│ 3. Deve corrigir antes ou com próximo release │
│ 4. Revisar impacto arquitetural │
└─────────────────────────────────────────────────────────────┘
Enforcement de Budget
VERIFICAÇÕES AUTOMATIZADAS DE BUDGET:
┌─────────────────────────────────────────────────────────────┐
│ │
│ PIPELINE CI: │
│ │
│ Build │
│ ↓ │
│ Tests │
│ ↓ │
│ Performance Checks ←── GATE │
│ ↓ │
│ Deploy │
│ │
│ OUTPUTS DA VERIFICAÇÃO: │
│ │
│ ┌─────────────────────────────────────────────────────────┐│
│ │ 📊 Relatório de Budget de Performance ││
│ │ ││
│ │ Análise de Bundle: ││
│ │ ✅ main.js: 142KB (budget: 200KB) ││
│ │ ⚠️ vendor.js: 185KB (budget: 150KB) +35KB ACIMA ││
│ │ ││
│ │ Scores Lighthouse: ││
│ │ ✅ Performance: 87 (budget: 85) ││
│ │ ✅ Accessibility: 92 (budget: 90) ││
│ └─────────────────────────────────────────────────────────┘│
│ │
│ AÇÕES QUANDO EXCEDE: │
│ │
│ • Falha no CI (blocking) │
│ • Notificação para time │
│ • Issue criada automaticamente │
│ • Requer aprovação para override │
│ │
└─────────────────────────────────────────────────────────────┘
Rastreamento no GitScrum
Tarefas de Performance
GESTÃO DE PERFORMANCE NO GITSCRUM:
┌─────────────────────────────────────────────────────────────┐
│ │
│ TAREFA DE PERFORMANCE: │
│ ────────────────────── │
│ │
│ Título: [PERF] Otimizar tempo de carregamento do dashboard│
│ │
│ Critérios de Aceitação: │
│ ☐ Tempo de carregamento < 2s (atualmente 4.5s) │
│ ☐ LCP < 2.5s │
│ ☐ Bundle JS < 200KB │
│ │
│ Labels: performance, frontend, p1 │
│ │
│ MÉTRICAS DE ANTES/DEPOIS: │
│ ────────────────────────── │
│ • Antes: 4.5s carregamento, 380KB bundle │
│ • Depois: 1.8s carregamento, 165KB bundle │
│ • Melhoria: 60% mais rápido │
│ │
│ ALOCAÇÃO DE CAPACIDADE: │
│ ──────────────────────── │
│ • Reservar 10-20% do sprint para performance │
│ • Tratar como trabalho de primeira classe │
│ • Não postergar indefinidamente │
│ │
└─────────────────────────────────────────────────────────────┘
Melhores Práticas
Checklist de Implementação
CHECKLIST DE PERFORMANCE NO DESENVOLVIMENTO
═══════════════════════════════════════════
BUDGETS:
☐ Budgets definidos para métricas chave
☐ Verificação automatizada no CI
☐ Alertas quando excede
☐ Processo de resolução definido
MEDIÇÃO:
☐ Baseline estabelecido
☐ Monitoramento contínuo
☐ Percentis rastreados (p50, p95, p99)
☐ RUM implementado
PROCESSO:
☐ Performance como critério de aceitação
☐ Capacidade reservada para performance
☐ Reviews regulares de métricas
☐ Profiling antes de otimizar
CULTURA:
☐ Performance é responsabilidade de todos
☐ Medir antes de otimizar
☐ Não postergar para "depois"
☐ Celebrar melhorias
Performance considerada desde o início evita retrabalho custoso depois.