App web lento? Como usar o Claude Opus 5.5 para achar e corrigir as ineficiências

Fala aí, beleza? A página demora 4 segundos pra abrir, o usuário reclama, alguém chuta que "deve ser o banco" e ninguém tem um número na mão pra provar nada

Esse post é sobre matar esse chute

A Anthropic lançou o Claude Opus 5.5 em 22/09/2026, o primeiro modelo da família Claude 5.5, e um dos casos que ela mesma colocou na vitrine é exatamente esse: encontrar e corrigir ineficiências em software. Na avaliação interna, ao receber a tarefa de reduzir o tempo de carregamento de todas as páginas de um app web, o Opus 5.5 teve sucesso em 39 de 40 execuções, enquanto o Opus 5 fazia melhorias menores que ainda por cima alteravam o comportamento do app

Número bonito, né? Mas ele não serve de nada se tu jogar o repo inteiro no chat e pedir "otimiza aí"

O que eu vou montar aqui é um ciclo com medição antes e depois. Não é prompt mágico, não existe prompt mágico, essas coisas toscas ficam pro pessoal do hype =)

O que você precisa antes de abrir o Claude:

Três coisas. E a terceira é a que quase todo mundo pula

1. Acesso ao Opus 5.5

Ele está disponível nas plataformas da Anthropic e nas nuvens da Amazon (AWS), Google Cloud e Microsoft Azure. Também já apareceu no GitHub Copilot, anunciado no changelog do GitHub no mesmo 22/09/2026

Ou seja: tanto faz se tu vive no terminal, na IDE ou chamando API direto, tem porta de entrada

2. O repositório do app

Óbvio, mas com um detalhe: tu precisa conseguir rodar e medir o app, não só ler o código. Análise estática acha coisa feia, mas coisa feia não é necessariamente coisa lenta

Formação Recomendada

Formação Claude Code

Domine Claude Code do absoluto zero até o avançado

• 120 aulas
• 4 projetos
• 9h 45min

Conhecer formação

3. Evidência de lentidão

Aqui mora o jogo todo

Evidência é: tempo de carregamento medido, log de queries com tempo de execução, trace de requisição, profile do navegador, waterfall de rede. Qualquer coisa que seja NÚMERO

"Tá lento" não é evidência

"O endpoint /pedidos responde em 3,8s no p95 e dispara 214 queries" é evidência

Sem linha de base o ciclo não fecha, porque no final tu não vai conseguir dizer se melhorou ou se tu só mexeu no código e teve sorte

Tome cuidado com isso: é muito comum "otimizar" e depois descobrir que o ganho veio do cache quente da segunda execução, não da mudança 😅

Passo a passo: da evidência de lentidão à correção medida

1. Meça a linha de base e registre o número num lugar fixo

Escolhe UMA página ou UM endpoint. Roda a medição várias vezes, descarta a primeira (cache frio, conexão nova, JIT aquecendo) e anota uma faixa, não um valor solto

Anota no próprio repositório, num arquivo simples:

# baseline.md
rota: /pedidos
medições (5 execuções, cache quente): 3,71s | 3,84s | 3,79s | 3,92s | 3,77s
queries por request: 214
maior query: SELECT ... FROM itens WHERE pedido_id = ? (repetida 198x)
data: 22/09/2026

O erro comum deste passo: medir uma vez só. Uma medição não é linha de base, é anedota

2. Monte o pacote de evidência que vai pro modelo

Não é o repo inteiro. É o recorte: o trace, a lista de queries com tempo, os arquivos que participam daquela rota (controller, service, query, template, componente de front) e o baseline.md que tu acabou de criar

O Opus 5.5 tem janela de 1.000.000 de tokens de contexto, então dá pra ser generoso no recorte e incluir o caminho inteiro da requisição sem picotar

Mas generoso não é burro: contexto grande serve pra tu mandar a rota completa COM as evidências, não pra tu mandar node_modules junto

O erro comum deste passo: entregar o repositório inteiro e nenhuma medição. Aí o modelo faz o que qualquer um faria sem dado: adivinha

3. Peça hipóteses ranqueadas, não solução

Essa é a virada de chave. Tu não quer que ele saia editando arquivo de cara, tu quer a lista de suspeitos ordenada

Contexto: app web, rota /pedidos, baseline em baseline.md (3,7s a 3,9s, 214 queries).
Anexei o trace, o log de queries e os arquivos da rota.

Tarefa: liste hipóteses para a lentidão dessa rota, ranqueadas por
(impacto estimado no tempo de carregamento) x (custo de implementação).

Para cada hipótese, diga:
- qual evidência do material anexado sustenta a hipótese
- qual mudança mínima testaria a hipótese
- qual métrica deveria mudar se a hipótese estiver certa

Restrição dura: nenhuma mudança pode alterar o comportamento observável
do app (mesma resposta, mesma ordenação, mesmos dados).
Não edite nenhum arquivo ainda.

Repara na restrição de comportamento. Ela não está ali de enfeite: na própria avaliação da Anthropic, o ponto fraco do Opus 5 foi justamente entregar melhoria pequena que mexia no comportamento do app. Deixa explícito o que é proibido

O erro comum deste passo: aceitar a primeira hipótese porque ela parece inteligente. Hipótese ranqueada existe pra tu testar a de cima, não pra tu ler e concordar

4. Escolha o modelo e o nível de esforço na sessão

No Claude Code, o comando /model abre um seletor interativo e tu troca de modelo sem sair da sessão. O nível de esforço tem o seletor dele, pelo /effort

/model
/effort

E dá pra fixar isso no arquivo de settings pela chave effortLevel, que aceita low, medium, high ou xhigh:

{
  "effortLevel": "high"
}

O ajuste por modelo fica salvo sob a chave modelSettings, então tu consegue ter preferência diferente por modelo em vez de um valor global pra tudo

Detalhe que pega muita gente: no Opus 5.5 o raciocínio adaptativo fica SEMPRE ligado e não dá pra desativar, e o padrão do effort nesse modelo é medium. No Opus 5 e nos Opus anteriores o padrão era high

Ou seja: se tu migrou e achou que ele ficou "mais apressado" numa análise difícil, provavelmente não ficou, tu só está rodando num esforço menor que o de antes

O erro comum deste passo: assumir que o padrão continua o mesmo da rotina antiga

5. Aplique UMA correção por vez

Pega a hipótese do topo, pede a mudança mínima que testa ela, aplica, roda a suíte de testes

Uma. Só uma

Aplique apenas a hipótese 1, com a menor mudança possível.
Não toque em nada fora do caminho dessa rota.
Ao final, me diga exatamente qual métrica eu devo remedir.

O erro comum deste passo: aplicar três otimizações no mesmo commit. Aí o tempo cai 40% e tu nunca vai saber qual das três fez o trabalho (e qual das três está te esperando com um bug daqui a duas semanas)

6. Meça de novo e compare com a linha de base

Mesma quantidade de execuções, mesmo descarte da primeira, mesma máquina, mesmo estado de dados. Atualiza o baseline.md com o depois

# depois da hipótese 1 (N+1 em itens)
medições (5 execuções, cache quente): 0,94s | 1,02s | 0,97s | 0,99s | 1,01s
queries por request: 17
testes: 312 passando, 0 falhando

Se o número não mexeu, a hipótese estava errada. Reverte e vai pra hipótese 2, sem drama

Hipótese descartada com evidência também é progresso, é assim que investigação funciona

O erro comum deste passo: medir o "depois" de um jeito diferente do "antes". Comparação só vale com o mesmo método nos dois lados

Onde esse fluxo costuma render mais:

O ciclo é sempre o mesmo, o que muda é qual evidência tu entrega e qual métrica fecha a conta

Consultas repetidas em loop

O clássico N+1. A página é simples, o HTML é pequeno, e o banco leva 200 queries iguais com parâmetro diferente

Evidência pra entregar: log de queries da requisição com contagem e tempo de cada uma, mais o trecho de código que renderiza a listagem

Métrica que fecha o ciclo: número de queries por request. É a mais honesta que existe aqui, porque não depende de rede nem de máquina

Carga desnecessária no primeiro render

A tela mostra 10 itens e o backend traz 10 mil, ou traz 40 colunas pra usar 3, ou monta um objeto gigante pra jogar fora quase tudo

Evidência pra entregar: tamanho do payload da resposta, trace do handler e o componente que consome o dado

Métrica que fecha o ciclo: bytes de resposta e tempo até o primeiro conteúdo aparecer

Assets pesados

Bundle inchado, imagem em tamanho original, fonte bloqueando a renderização, biblioteca inteira importada pra usar uma função

Evidência pra entregar: waterfall de rede do navegador e o relatório de build com o peso por arquivo

Métrica que fecha o ciclo: peso total transferido e tempo até a página ficar interativa

Trabalho síncrono que poderia ser adiado

Envio de email, geração de PDF, chamada a serviço externo, tudo isso acontecendo DENTRO do request enquanto o usuário olha pro spinner

Evidência pra entregar: trace da requisição com o tempo gasto em cada chamada externa

Métrica que fecha o ciclo: tempo de resposta do endpoint, comparando o antes e o depois de mandar o trabalho pra fila

E vale dizer: esse mesmo ritual de evidência primeiro, hipótese depois, serve pra outros tipos de varredura no código, tipo achar falhas de segurança no código. Muda o alvo, não muda o método

O que muda em relação ao Opus 5 (e o que pode quebrar):

Se tu já tinha rotina rodando no Opus 5, algumas coisas mudaram de verdade. Umas boas, umas que quebram código

Começa pelo bolso:

Além do preço por token, a Anthropic afirma que o Opus 5.5 custa 40% menos para rodar que o Opus 5, entregando desempenho no nível do Claude Fable 5.1 na maioria das tarefas. Pra um ciclo como esse aqui, que é repetitivo por natureza (mede, hipotetiza, aplica, mede de novo), isso conta MUITO no fim do mês

E como tu vai reenviar o mesmo contexto várias vezes, o cache pesa: escrita de cache de 5 minutos custa US$ 5, escrita de 1 hora custa US$ 8 e leitura de cache custa US$ 0,20 por milhão de tokens. Reaproveitar o pacote de evidência entre as iterações sai bem mais barato que remontar tudo do zero a cada rodada

Agora a parte chata, que é o que quebra compatibilidade com código escrito pro Opus 5. São 4 mudanças documentadas:

• Não dá pra desativar o thinking. Se tua integração mandava o flag pra desligar, revisa
• Uso forçado de ferramenta retorna erro. Aquele padrão de obrigar a chamada de uma tool específica não passa mais
• Blocos de thinking ficam atrelados ao modelo e à conversa. Reaproveitar bloco de thinking entre modelos ou entre conversas não rola
• A ferramenta de computer use computer_20251124 não é aceita na Claude API e no Google Cloud

E tem uma pegadinha silenciosa, que merece atenção especial: o texto entre chamadas de ferramenta volta dentro de blocos de thinking cujo texto vem VAZIO na configuração padrão de exibição

Na prática isso significa que aplicação que transmitia esse texto como atualização de progresso simplesmente emudece, e tu vai achar que travou

Não travou. É só ajustar o valor de display 🙂

Se a tua dúvida ainda é mais básica, tipo qual modelo usar em cada tarefa, esse é outro papo e ele continua valendo

Vale usar o Opus 5.5 para caçar gargalo?

Vou ser honesto sobre o que os dados sustentam e o que não sustentam

O que está publicado e pesa a favor:

• a avaliação da própria Anthropic no cenário de reduzir tempo de carregamento de todas as páginas de um app web, com 39 de 40 execuções bem sucedidas, contra melhorias menores e que alteravam comportamento no Opus 5
• 54 pontos no Artificial Analysis Intelligence Index, na variante Claude Opus 5.5 (Adaptive Reasoning, High Effort, Default Fallback)
• custo menor que o Opus 5, tanto no preço por token quanto nos 40% a menos por tarefa

O que não muda de dono: a medição

O modelo lê evidência, cruza código e ranqueia suspeito muito bem. Ele não roda o teu app em produção, não conhece o teu volume de dados real e não sabe qual é o p95 do teu endpoint às 19h de sexta

Esse número é teu

E repara que o benchmark ali em cima é de alto esforço, enquanto o padrão do Opus 5.5 é medium. Se tu vai comparar performance com o que leu em algum lugar, compara a configuração também, senão a conversa fica torta

Veredito: pra esse tipo de tarefa, os dados publicados são bons o suficiente pra justificar colocar o Opus 5.5 no fluxo. Mas eu não rodei essa avaliação aqui, então o que tu está lendo é leitura de dado publicado, não teste próprio. Faça o teu, com a tua linha de base, no teu app

Conclusão:

O ciclo cabe numa frase: mede, entrega evidência, pede hipótese ranqueada, aplica UMA mudança, mede de novo

E o próximo passo é bem menor do que tu imagina: escolhe UMA página lenta, aquela que todo mundo reclama, registra o tempo atual dela num arquivo e roda o fluxo só nela

Se fechar com número melhor e teste passando, aí sim tu escala pro resto do app

Se não fechar, tu perdeu uma tarde e ganhou uma hipótese descartada com evidência, o que ainda é MUITO melhor que o chute de corredor 😀

até o próximo post!