Performance de software: os passos essenciais para começar a otimizar

Quando uma aplicação fica lenta, o instinto da maioria dos times é começar a mexer. Trocar uma biblioteca, adicionar um cache, subir uma máquina maior. É a reação errada, e é cara, porque ataca sintomas antes de entender a doença.

Performance tem método. Existe uma ordem certa de passos, e ela começa muito antes de você tocar em uma linha de código. Este artigo é para quem já entende que precisa otimizar e quer saber por onde começar de forma disciplinada, sem desperdiçar semanas no lugar errado.

Não vou tratar isso como uma lista de truques. Truques resolvem casos específicos e envelhecem rápido. Método resolve qualquer caso e se sustenta.

Passo 0: defina o que "rápido" significa

Antes de qualquer coisa, responda: o que é aceitável? "O sistema está lento" não é um problema acionável. "A página de listagem precisa responder em menos de um segundo para 95% das requisições" é.

Sem um alvo, você nunca sabe quando parar. Otimização sem meta é um buraco sem fundo, sempre dá para deixar mais rápido, e sempre custa mais esforço para ganhar menos. Definir limites aceitáveis de tempo de resposta, idealmente por percentil, transforma uma sensação difusa em um critério objetivo.

Esse passo parece burocrático, mas é o que separa um esforço de otimização de uma caça sem fim. E é uma conversa de produto e negócio tanto quanto de engenharia: o que é "rápido o bastante" depende do que o usuário está tentando fazer.

Passo 1: meça antes de mexer

A regra mais importante de toda esta disciplina: você não otimiza o que não mede. Sem instrumentação, qualquer mudança é um chute, e chutes acertam por sorte.

Instrumente a aplicação com métricas, logs estruturados e, idealmente, tracing distribuído. O objetivo é responder a uma pergunta simples: onde o tempo está sendo gasto? Quase sempre a resposta surpreende. O gargalo raramente está onde a intuição aponta.

Um padrão recorrente: o time jura que o problema é a linguagem ou o framework, instrumenta, e descobre que 80% do tempo está em uma única consulta ao banco. Sem medir, esse time teria reescrito a aplicação inteira e o problema continuaria lá.

A ferramenta importa menos do que o hábito. Pode ser uma solução completa de observabilidade ou um log bem colocado. O que não pode faltar é o dado.

Passo 2: ataque o maior gargalo primeiro

Com os dados em mãos, a priorização fica óbvia. Existe uma regra prática poderosa: a maior parte da lentidão costuma vir de uma minoria das causas. Ataque a maior primeiro.

Resista à tentação de fazer dez micro-otimizações que somam pouco. Encontre o item que sozinho responde pela maior fatia do tempo e resolva ele. O ganho de eliminar o principal gargalo costuma ser maior do que o de todas as outras melhorias somadas.

Depois de resolver o maior, meça de novo. O gargalo se moveu. O segundo maior agora é o novo alvo. Performance é um processo iterativo de medir, corrigir e remedir, não um mutirão único.

Passo 3: comece pelo banco de dados

Na maioria das aplicações de negócio, o banco é onde mais tempo se perde. Por isso ele merece atenção prioritária. Três verificações resolvem uma fração enorme dos problemas:

Índices ausentes. Consultas que varrem a tabela inteira porque falta um índice na coluna filtrada. É o erro mais comum e o de correção mais barata.
O problema N+1. Quando o código faz uma consulta para a lista e depois uma consulta adicional para cada item da lista. Cem itens viram cento e uma consultas. Resolve-se carregando os dados relacionados de uma vez.
Consultas que trazem dados demais. Buscar a tabela inteira para usar três colunas é desperdício de banco, rede e memória.

Essas três correções, sozinhas, transformam a percepção de velocidade de muitos sistemas. E nenhuma delas exige trocar de tecnologia.

Passo 4: use cache com consciência

Cache é a otimização mais sedutora e a mais perigosa. Ele entrega ganhos imediatos e introduz uma classe inteira de bugs novos: dados desatualizados.

A regra de ouro: só cacheie aquilo que pode ficar levemente velho sem causar dano. E sempre defina, de forma explícita, como o cache será invalidado. Cache sem estratégia de invalidação não é otimização, é uma bomba-relógio.

Para dados sensíveis, saldos, status de pedido, informações que mudam e cuja exatidão importa, pense duas vezes. Em sistemas que lidam com dinheiro ou com decisões do cidadão, a correção do dado vence a velocidade. Mostrar um número errado mais rápido não ajuda ninguém.

Vale também lembrar que cache existe em várias camadas: no navegador do usuário, em uma camada intermediária, no servidor, no banco. Cada uma resolve um problema diferente e tem custo de invalidação próprio. O erro do iniciante é empilhar caches sem entender qual está respondendo o quê, e aí, quando um dado fica errado, ninguém sabe em qual camada ele ficou preso. Mapear conscientemente onde o cache atua é parte de usá-lo bem.

Passo 5: só então pense em infraestrutura

Subir uma máquina maior ou adicionar mais instâncias é, frequentemente, o primeiro passo que os times tomam. Deveria ser um dos últimos.

Escalar infraestrutura sem antes corrigir os gargalos de código e banco é jogar dinheiro no problema. Você paga mais para fazer o mesmo trabalho ineficiente, só que em paralelo. O custo cresce, e a ineficiência continua lá, agora mais cara.

Quando a otimização de código já foi feita e o limite real é de capacidade, aí sim infraestrutura entra. E a forma certa quase sempre é escalar horizontalmente, adicionar instâncias, o que exige que a aplicação seja sem estado. Essa é uma decisão de arquitetura que vale ser tomada cedo, porque consertar depois é trabalhoso.

O erro que invalida todos os passos

Existe uma falha cultural que sabota qualquer roteiro: otimizar por intuição e celebrar sem medir o resultado. O time mexe em algo, sente que ficou mais rápido e segue em frente. Sem medição depois da mudança, você não sabe se melhorou, se piorou ou se nada aconteceu.

Toda otimização precisa de um antes e um depois mensuráveis. Caso contrário, você está apenas movendo código e torcendo.

A reflexão honesta: a maior parte dos problemas de performance não exige gênios nem ferramentas caras. Exige disciplina. Medir, priorizar, corrigir o maior gargalo, remedir. Times que seguem essa ordem resolvem em dias o que times que chutam não resolvem em meses.

Performance bem feita é menos sobre talento e mais sobre processo. Quem internaliza esses passos para de apagar incêndio e passa a prevenir.

Se o seu time vive resolvendo lentidão no escuro, talvez o problema não seja técnico, mas de método. Há outros artigos no blog sobre qualidade, observabilidade e escalabilidade que complementam este roteiro. Se quiser trocar ideia sobre como estruturar isso na sua organização, vale conversar.