Segundo a Vercel, eliminar waterfalls assíncronos é a prioridade número um para melhorar performance em aplicações React em produção. Mesmo assim, a maioria dos dashboards corporativos que eu encontro na mentoria ainda comete erros básicos de configuração que deixam tudo absurdamente lento.
Se o seu painel de controle demora segundos para carregar, se a navegação trava ou se o usuário precisa esperar uma eternidade para ver dados simples, provavelmente o problema não é o servidor. É o jeito que as queries estão configuradas no frontend.
Neste artigo, vou mostrar os erros mais comuns que encontrei em um projeto real, como queries sem filtro, requisições em cascata, Context API sobrecarregado e falta de tratamento de erros. Mais do que apontar os problemas, vou explicar como cada um impacta a experiência do usuário e o que você pode fazer para resolver.
Dashboard que busca tudo sem filtro: o primeiro grande vilão
Um dos problemas mais graves e mais comuns em dashboards React é quando a tela principal faz queries que trazem absolutamente tudo do banco de dados. Sem filtro, sem paginação, sem limite.
No caso que analisei, o dashboard principal estava buscando todos os cursos, todos os módulos e todas as informações de progresso da plataforma inteira. A ideia era computar o progresso do curso matriculado, mas para isso a aplicação transferia dados de absolutamente todos os cursos cadastrados. O resultado? Lentidão perceptível logo na primeira tela.
Esse padrão é o que a documentação oficial do TanStack Query classifica como um dos maiores “footguns” de performance. Quando você faz uma query que retorna 10.000 registros e filtra no cliente para usar apenas 50, está desperdiçando banda, memória e tempo de processamento tanto do servidor quanto do navegador.
A correção passa por reestruturar a API para aceitar filtros no lado do servidor. Em vez de buscar todos os cursos e computar progresso localmente, o correto é enviar o ID do usuário e receber apenas os cursos matriculados com o progresso já calculado. Essa mudança simples pode reduzir o payload em mais de 90%.
Queries sequenciais e o efeito cascata nas requisições
O segundo problema encontrado foi na página de portais. Quando o usuário entrava no sistema, a página fazia N queries sequenciais, cada uma trazendo blocos de 100 registros, em vez de uma única query otimizada. O resultado era um efeito cascata clássico, onde cada requisição só começava depois que a anterior terminava.
A documentação do TanStack Query é muito clara sobre isso: cada waterfall representa no mínimo um roundtrip completo ao servidor. Em redes com latência de 250ms, como uma conexão 3G, um triplo waterfall soma 1000ms apenas de latência de rede, sem contar o processamento. Se você achatar essa cadeia para apenas dois roundtrips, cai para 500ms. É metade do tempo, só reorganizando as queries.
Ryan Carniato, criador do SolidJS, afirmou que “waterfalls são singularmente mais importantes do que todo o resto junto” quando se fala em otimização de performance. E ele não está exagerando.
No fluxo de pagamento do mesmo sistema, havia três queries sequenciais no checkout premium. Cada step esperava o anterior terminar para iniciar. Para o usuário, isso significava uma tela de loading que parecia infinita justamente no momento mais crítico: a hora de pagar.
A solução técnica envolve usar useQueries para paralelizar requisições independentes, ou reestruturar a API para consolidar dados em endpoints únicos. Quando queries realmente dependem uma da outra, a opção enabled do React Query permite declarar dependências de forma explícita, e mover o waterfall para o servidor (via Server Components) reduz drasticamente o impacto da latência.
Admin que busca 10.000 roles e filtra no cliente
Um caso especialmente grave: a tela de administração buscava todos os roles do sistema, mais de 10.000 registros, e depois fazia busca linear localmente para filtrar por cada usuário. Isso transforma o que deveria ser uma consulta SQL indexada de milissegundos em um loop de processamento pesado no navegador.
Segundo dados publicados na DEV Community, substituir listas renderizadas diretamente por virtualização com react-window em tabelas com mais de 10.000 linhas reduziu o tempo de renderização de 1.2 segundo para 200 milissegundos. Uma melhoria de 6x só com virtualização.
Mas a raiz do problema aqui não é a renderização, é a query. Filtrar 10.000 registros no cliente é um antipadrão de arquitetura. O servidor deve receber os parâmetros de busca, aplicar filtros no banco de dados e retornar apenas os resultados relevantes. Paginação e busca server-side não são luxo, são requisitos básicos para qualquer sistema que lida com volumes significativos de dados.
Context API sobrecarregado: 7 propriedades, infinitos re-renders
O sistema analisado tinha sete propriedades em um único contexto React. Quando qualquer uma dessas propriedades mudava, todos os componentes consumidores eram re-renderizados, mesmo os que não usavam o valor alterado. É o comportamento padrão do React, e é exatamente por isso que especialistas alertam contra o uso excessivo do Context API.
Os números são expressivos: segundo a mesma pesquisa da DEV Community, migrar de Context para Zustand em um dashboard reduziu re-renders em 70% e melhorou a latência de interação de 180ms para 45ms. Isso é a diferença entre uma interface que parece responsiva e uma que o usuário percebe como travada.
A recomendação prática é clara: se você tem múltiplos valores de estado em um único contexto, separe-os. Use um provider por recurso. E para estado global complexo em dashboards com dezenas de componentes, considere seriamente migrar para Zustand, Jotai ou Redux Toolkit, que oferecem granularidade fina de atualizações sem o problema de re-renders em cascata.
Resiliência e UX: quando o erro vira tela branca
O último problema identificado é talvez o mais grave do ponto de vista do usuário: qualquer erro de JavaScript causava uma tela branca sem nenhum fallback. Sem Error Boundaries, sem mensagem de erro, sem botão de “tentar novamente”. Apenas uma tela vazia.
Error Boundaries são um recurso do React desde a versão 16, e a Vercel identificou em fevereiro de 2026 que a falta de resiliência em aplicações React continua sendo um problema sistêmico. Das mais de 40 regras de performance publicadas pela equipe de engenharia da Vercel, o tratamento de erros aparece como fundamental para a experiência do usuário.
A implementação é simples: envolva seções críticas do dashboard com Error Boundaries que exibam uma mensagem amigável e um botão para recarregar a seção. Para queries, o React Query oferece a propriedade onError e o hook useErrorBoundary que integra nativamente com o sistema de error boundaries do React.
Como auditar seu dashboard hoje
Se você reconheceu alguns desses problemas no seu próprio sistema, aqui está um checklist prático:
- Audite suas queries: verifique o tamanho dos payloads na aba Network do DevTools. Se alguma query retorna mais de 100 registros sem paginação, é um sinal de alerta
- Identifique waterfalls: no DevTools, observe se as requisições começam sequencialmente ou em paralelo. Queries independentes devem ser paralelas
- Conte os re-renders: use o React DevTools Profiler para identificar componentes que re-renderizam sem necessidade
- Revise seu Context: se mais de 3 propriedades compartilham um único Context, considere dividir ou migrar para um state manager dedicado
- Adicione Error Boundaries: cada seção independente do dashboard deve ter seu próprio tratamento de erros
Conclusão
Performance em dashboards React não é sobre usar a ferramenta mais nova ou a técnica mais sofisticada. É sobre não cometer erros fundamentais de configuração que transformam uma aplicação simples em um pesadelo de lentidão.
Queries sem filtro, waterfalls de requisições, filtragem no cliente, Context sobrecarregado e falta de tratamento de erros. São problemas comuns, bem documentados e com soluções conhecidas. O primeiro passo é reconhecer que eles existem no seu código.
Sou Thulio, mentoro 300+ Software Houses desde 2016 e vejo esses mesmos padrões se repetindo em projetos de todos os tamanhos. A boa notícia é que cada um desses problemas tem solução, e nenhuma delas exige reescrever o sistema do zero.
Este artigo foi baseado no vídeo “Otimizando React Query: Acelere seu Dashboard AGORA!” do nosso canal no YouTube.
Assista ao vídeo completo: https://www.youtube.com/watch?v=j67fXBpoAsk
