Já faz algum tempo que os benchmarks deixaram de ser apenas uma ferramenta técnica e passaram a ocupar espaço central no marketing de produtos e tecnologias. De linguagens de programação a frameworks web, de modelos de LLM a placas de vídeo, benchmarks são utilizados como argumentos de venda — e com razão: números impressionam.

Mas como todo dado isolado, os benchmarks contam apenas parte da história. Os números são reais, mas o contexto em que esses números são obtidos está longe da realidade da maioria dos sistemas em produção. E é justamente aí que mora o problema.

Quando o assunto é desenvolvimento, em muitos desses testes, o cenário se resume a algo extremamente simplificado: processar uma string, retornar um JSON estático, ou calcular algo em memória — tudo isso sem envolver banco de dados, sem serialização real, sem cache, sem autenticação, sem concorrência real.

Esses benchmarks não refletem o mundo real.

O que acontece no mundo real?

No mundo real, um request HTTP passa por diversas camadas:

• Autenticação e autorização (muitas vezes com JWTs, que exigem criptografia)
• Desserialização do payload recebido
• Regras de negócio, que frequentemente acessam banco de dados ou serviços externos
• Escrita em cache ou leitura de cache (Redis, por exemplo)
• Log, tracing, métricas e demais elementos de observabilidade
• Processamento concorrente, locks e contenção

Tudo isso consome tempo — e não são microssegundos. Estamos falando de milissegundos, muitas vezes dezenas deles. Um simples acesso ao banco pode levar 5, 10, 20ms. Um serviço externo pode adicionar 100ms ou mais de latência.

Decidir adoção ou migração de uma tecnologia baseando-se em menchmarks sintéticos é como escolher um carro pela velocidade de abertura da porta do carona.

Os percentuais escondem os valores reais…

Se um framework A responde uma requisição simples em 400 microssegundos e o framework B em 800 microssegundos, isso pode parecer uma diferença substancial, afinal um é 100% mais lento que o outro, ou talvez você prefira pensar que um deles é 2 vezes mais rápido, certo?

Mas se a requisição real do seu sistema leva 120ms para ser processada por conta de chamadas externas, então a diferença entre A e B representa menos de 0,5% do tempo total. Ou seja, menos da metade de 1%.

Em uma relação desse tipo temos:

Uma substituição, em nome do desempenho, pode parecer justificável ao olhar desatento, mas seria como otimizar o tempo de abrir a porta do carro para ganhar desempenho em uma corrida de 10 horas. Sim, pode fazer diferença em cenários extremos e altamente otimizados. Mas para 99.9% dos sistemas em produção, isso é irrelevante.

Aqui nos deparamos com o dilema da relevância de tal mudança. Um ganho tão pequeno não justifica, de forma consistente, decisão alguma na maioria absoluta dos casos. Estamos diante de um ganho irrisório, marginal, ínfimo.

Então por isso não devemos mudar?

Você pode encontrar diversos outros argumentos válidos, faça o exercício de buscá-los. É possível e provável que encontre argumentos mais atraentes e que justifiquem uma mudança.

Respondendo à pergunta original, “Então por isso não devemos mudar?”, onde “isso” é um ganho de desempenho de menos de 0.5%, a resposta é simples: Não há plausibilidade em realizar mudanças quando o ganho é tão marginal.

O que realmente importa?

Sob a ótica de uma empresa com fins lucrativos, o que importa é o lucro.

E isso pode ser obtido otimizando e maximizando o consumo de recursos com mais eficiência, mas também com a redução de custo. Ou trazendo mais receita, algo que contribua na margem final.

Portanto:

• Latência total da requisição
  • Aumento da eficiência.
  • Aumento da percepção do seu usuário.
  • Redução de custos.
• Capacidade de escalar horizontalmente
  • Aumento da eficiência
  • Capacidade de atender mais clientes com custo otimizado para a demanda.
• Facilidade de observabilidade
  • Menor tempo até a descoberta de bugs
  • Menor tempo reprodução e de resolução de bugs.
  • Melhoria na percepção do usuário final
  • Permite ser proativo na correção de bugs
• Custo de manutenção
  • Redução de tempo para entregar novas features
  • Redução de tempo para corrigir bugs
  • Redução dos skills de contratação
• Confiabilidade e estabilidade
  • Redução do esforço de operações para suportar a aplicação.
  • Redução das interrupções nos times de desenvolvimento para correção de bugs.
  • Redução da frustração do cliente.
  • Aumento da percepção de qualidade pelo cliente.

Quando falamos de benefícios técnicos, precisamos ter em mente que queremos:

• Mais clientes.
• Por mais tempo.
• Pagando mais durante toda a vida dele no seu software.
• Gastando menos para produzir e manter o software e infraestrutura.

E muitas vezes, para que esses objetivos sejam alcançados, empresas fazem um zilhão de coisas para criar um ambiente legal para os devs, para contratar, para reter talentos e também seus clientes.

Entenda a regra do jogo, para entender quais são os melhores argumentos.

Conclusão

Benchmarks sintéticos servem para comparar aspectos específicos, mas não devem guiar decisões arquiteturais sem contexto.

No mundo real, a performance relevante é medida de ponta a ponta, em cenários reais, sob carga real.

Antes de trocar de framework por uma diferença de microssegundos ou nanosegundos, pergunte-se: qual será o ganho real? E o que vai realmente mover o ponteiro da performance no meu sistema?

Será que não há outros argumentos mais interessantes que foram ignorados?

No fim das contas, escolher um framework apenas por benchmarks é como escolher um carro olhando apenas o velocímetro, ignorando conforto, segurança, consumo e confiabilidade.

A performance importa, mas no contexto certo.