Medir antes de otimizar

O problema

Muita otimização nasce de impaciência.

A página parece lenta.

A lista parece pesada.

A API parece demorar.

Aí o time começa a mexer no código antes de responder uma pergunta básica:

• onde exatamente está o custo?

Sem essa resposta, o risco é alto:

• otimizar a parte errada
• adicionar complexidade inútil
• declarar vitória em cima de uma melhora que ninguém provou

Modelo mental

Pensa assim:

percepção levanta hipótese; medição confirma ou derruba.

Isso vale para frontend, backend, banco e fila.

O ponto não é virar escravo de dashboard.

O ponto é não tratar sensação como diagnóstico.

Performance madura tem uma ordem simples:

1. observar o problema
2. escolher a métrica certa
3. capturar baseline
4. mudar alguma coisa
5. comparar de novo

Se você pulou essa ordem, provavelmente está otimizando no escuro.

Quebrando o problema

Primeiro: qual fluxo está ruim?

“O sistema está lento” é quase sempre descrição ruim.

Você precisa recortar melhor:

• abrir a home?
• salvar formulário?
• buscar dados?
• renderizar tabela?

Sem recorte, a medição vira ruído.

Depois: que métrica representa essa dor?

Nem toda lentidão pede a mesma métrica.

Alguns exemplos:

• tempo de resposta de uma API
• tempo até a tela ficar interativa
• duração de uma query
• quantidade de re-render desnecessário
• tempo de processamento de um job

Métrica boa precisa representar o que realmente piorou para o usuário ou para o sistema.

Medir qualquer número fácil só porque ele existe não ajuda.

Baseline é o que impede autoengano

Antes de mudar o código, você precisa registrar o estado atual.

Esse baseline pode ser:

• tempo médio
• percentil relevante
• contagem de renderizações
• uso de CPU
• tamanho de payload

O formato importa menos que o princípio:

você precisa ter um “antes” para comparar com o “depois”.

Sem isso, a equipe só fica torcendo para ter melhorado.

Medir também ajuda a descartar suspeitas erradas

Esse é um benefício subestimado.

Às vezes todo mundo jura que o problema está no componente, mas o atraso real está:

• na rede
• no banco
• num script terceiro
• numa etapa de hydration

Medição não serve só para validar uma solução.

Ela serve para impedir que você invista energia no alvo errado.

Nem toda melhora vale o custo

Esse ponto costuma separar experiência real de otimismo técnico.

Uma otimização pode até melhorar um número, mas trazer:

• código mais difícil de manter
• acoplamento estranho
• branch extra de comportamento
• mais risco de bug

Se o ganho foi pequeno e o custo de manutenção foi alto, talvez não tenha valido.

Exemplo simples

Imagina uma lista de clientes que “parece lenta”.

A reação impulsiva seria sair colocando:

• memo
• useMemo
• useCallback

em tudo.

Uma abordagem melhor seria:

1. abrir o profiler
2. ver se o gargalo é render, rede ou processamento
3. medir quantas renderizações estão acontecendo
4. comparar antes e depois da mudança

Se a lentidão real vinha da API, entupir o componente de micro-otimização não resolveu o problema.

Só deixou o código mais chato.

Erros comuns

• Otimizar sem baseline.
• Medir uma métrica que não representa a dor real.
• Confiar só na sensação da máquina local.
• Declarar sucesso sem comparar antes e depois.
• Manter uma otimização cara mesmo quando o ganho foi irrelevante.

Como um senior pensa

Quem tem mais experiência trata performance como investigação, não como reflexo.

O raciocínio costuma ser:

antes de comprar complexidade, eu quero prova de onde está o custo e de quanto essa mudança melhora a métrica que importa.

Esse padrão protege o time de duas coisas bem comuns:

• tuning vaidoso
• complexidade performática sem retorno

Senioridade aqui não é conhecer toda ferramenta de profiling.

É saber que performance sem evidência vira opinião com cara de técnica.

O que o entrevistador quer ver

Em entrevista, esse tema aparece muito quando o avaliador quer testar critério.

Ele quer ver se você:

• separa hipótese de evidência
• fala de baseline e comparação
• escolhe métrica de acordo com o problema
• entende que otimização também tem custo de manutenção

Uma resposta forte costuma soar assim:

Primeiro eu recorto o fluxo que está ruim. Depois escolho uma métrica que representa essa dor e capturo o baseline. Só então eu proponho mudança. Se a alteração não melhora de forma relevante a métrica que importa, eu não compro a complexidade dela.

O que não foi medido ainda é suspeita, não diagnóstico.

Otimização boa não é a mais esperta. É a que melhora algo importante sem piorar o sistema ao redor.