Quando uma simples mudança de layout revelou um grande problema de performance

Recentemente atualizei o layout de um projeto React.js que venho desenvolvendo. A princípio parecia apenas uma mudança visual, mas durante os testes percebi algo estranho: o projeto começou a travar no navegador e as fans do meu notebook dispararam.

Foi aí que comecei a investigar.

Abrindo o DevTools, na aba de Network, encontrei algo inesperado:

em apenas 5 minutos o projeto já tinha feito mais de 50.000 requisições, e o número continuava aumentando.

Tentei analisar a aplicação com ferramentas como PageSpeed Insights e GTmetrix, mas nenhuma delas conseguia sequer carregar o projeto que já estava em produção.

Então resolvi olhar o impacto nos recursos da máquina:

💻 Sem acessar o projeto

• CPU: ~2%
• RAM: ~7.8 GB

🌐 Com o projeto aberto por 5 minutos

• CPU: ~36%
• RAM: ~12 GB (e continuava subindo)

Tudo isso sem nem interagir com a aplicação.

Ao investigar o código, encontrei o problema:

algumas funções responsáveis por buscar dados do projeto eram muito custosas e não estavam memorizadas.

Como resultado, a cada render do React a referência dessas funções mudava, fazendo com que fossem reexecutadas constantemente, gerando refetch desnecessário.

A solução foi simples, mas extremamente eficiente:

aplicar useCallback nessas funções.

Depois disso:

✅ O consumo de recursos da máquina voltou ao normal

✅ O projeto parou de gerar requisições infinitas

✅ As ferramentas de análise finalmente conseguiram rodar

E o resultado final foi uma média de 92,5% de performance nas métricas do PageSpeed Insights e GTmetrix.

Essa experiência reforçou algo importante para mim:

não basta apenas estudar otimização, ver o impacto real dela em um projeto muda completamente a forma como você escreve código.

#react #frontend #javascript #performance #webperformance #desenvolvimentoweb #programacao #devtools #aprendizado