Por que seu app construído com IA fica lento com usuários reais
Um app construído com IA, rápido na demo, fica lento quando os dados crescem. As seis causas comuns, como achar a sua e as correções, quase todas pequenas.
Nesta página · 3 seções
Principais pontos
- Apps construídos com IA são rápidos com dados de teste e lentos com dados reais, porque o código faz no navegador ou no banco de dados um trabalho que cresce a cada linha.
- As causas comuns são carregar tabelas inteiras, falta de índices, políticas de row level security lentas, requisições demais por página e ausência de paginação.
- A maioria das correções é pequena e localizada. Meça primeiro, corrija a página mais lenta e meça de novo.
A demo era instantânea. Três meses depois, com algumas centenas de clientes e alguns milhares de registros, o dashboard leva oito segundos e os usuários estão reclamando. Nada foi alterado, então o que aconteceu?
Os dados cresceram. O código gerado por ferramentas de IA é escrito para funcionar, e com dez linhas de teste quase tudo funciona. Os problemas só aparecem quando o mesmo código encontra volumes reais. Este post cobre as seis causas comuns, como saber qual é a sua e como corrigi-las. Ele faz parte do guia para deixar um protótipo construído com IA pronto para usuários reais.
Como descobrir o que está lento?
Meça antes de mudar qualquer coisa. Abra a página lenta com as ferramentas de desenvolvedor do navegador na aba Network e recarregue. Você está procurando três coisas: requisições que levam mais de um segundo, respostas muito grandes e dezenas de requisições onde algumas bastariam.
Depois, olhe o banco de dados. No Supabase, rode a consulta lenta com explain analyze no editor SQL; a documentação sugere procurar sequential scans e números de custo altos, e oferece um index advisor que recomenda índices para uma consulta específica (Supabase).
As seis causas comuns
1. Carregar a tabela inteira e filtrar no navegador
A página pede todos os pedidos e depois filtra, ordena e conta tudo em JavaScript. Com 50 pedidos, tudo bem; com 50.000, o navegador baixa megabytes para mostrar uma lista de 20. A correção é pedir ao banco de dados exatamente o que a página mostra: o filtro, a ordenação e o limite vão para a consulta, e os totais vêm de um count ou de uma pequena consulta de resumo.
2. Falta de índices
Uma consulta que filtra por user_id, status ou created_at sem índice lê a tabela inteira toda vez. A orientação do Supabase é indexar as colunas usadas em filtros e joins (Supabase). Muitas vezes esse é o maior ganho isolado, e custa uma linha de SQL por índice.
3. Políticas de row level security lentas
As políticas de segurança rodam em cada linha que uma consulta toca. Escritas do jeito óbvio, elas podem ser a parte mais lenta da consulta. Os testes do próprio Supabase mostram grandes ganhos com três mudanças: indexar as colunas que uma política usa (mais de 100 vezes mais rápido em tabelas grandes), envolver auth.uid() em um select (de 179 ms para 9 ms) e adicionar o mesmo filtro na própria consulta (de 171 ms para 9 ms) (Supabase). Se você ainda não configurou as políticas, comece por RLS no Supabase para apps construídos com IA.
4. Uma requisição por item
Uma lista de 30 projetos em que cada card busca o dono, as tarefas e os comentários separadamente faz 90 requisições para mostrar uma página. A correção é buscar os dados relacionados em uma única consulta (o Supabase permite selecionar tabelas relacionadas na mesma requisição) ou carregar os detalhes só quando um card é aberto.
5. Sem paginação
Listas que carregam “tudo” ficam mais lentas a cada dia. Pior: as APIs limitam quantas linhas uma requisição retorna, então uma lista pode parar de mostrar registros novos, sem aviso, depois de passar desse limite. Pagine os resultados com limit e offset ou com um cursor, e mostre o total separadamente.
6. O plano de hospedagem
Planos gratuitos são feitos para testar, não para atender clientes. O plano gratuito do Supabase, por exemplo, inclui um banco de dados de 500 MB e pausa projetos depois de uma semana de inatividade (Supabase); o primeiro visitante depois de uma pausa espera o projeto acordar. Antes do lançamento, passe para um plano pago e confira onde o seu banco de dados e a sua hospedagem rodam: um servidor em outro continente em relação aos seus usuários adiciona atraso a cada requisição.
Qual correção vem primeiro?
Comece pela página de que os usuários reclamam e meça a requisição mais lenta dela. Na maioria dos apps construídos com IA a ordem é a mesma: índices primeiro (minutos para adicionar, muitas vezes o maior ganho), depois as consultas que carregam dados demais, depois a paginação, depois o número de requisições por página. Corrija uma coisa, meça de novo e pare quando a página estiver rápida o suficiente. Reescrever o app por causa de velocidade raramente é necessário.
Problemas de velocidade e problemas de segurança muitas vezes têm a mesma causa: o navegador fazendo um trabalho que o servidor deveria fazer. Quando corrigir um, verifique o outro; chaves secretas no seu frontend cobre o lado da segurança.
Perguntas frequentes
Por que meu app no Supabase está lento?
As causas mais comuns são a falta de índices em colunas usadas em filtros e em políticas de segurança, consultas que carregam tabelas inteiras e políticas de row level security escritas sem os padrões de performance que o Supabase recomenda. Rode a consulta lenta com explain analyze para ver qual é o caso.
Preciso reescrever meu app construído com IA para deixá-lo mais rápido?
Normalmente não. A maior parte da lentidão vem de algumas poucas consultas: adicionar índices, filtrar no banco de dados em vez de no navegador e paginar listas longas resolvem a maioria dos casos. Uma reescrita só vale a pena quando o próprio modelo de dados não se encaixa no produto.
O plano gratuito do Supabase basta para um app já lançado?
Ele foi feito para desenvolvimento e projetos pequenos. Inclui um banco de dados de 500 MB e pausa projetos depois de uma semana de inatividade, então um app com clientes reais deve passar para um plano pago antes do lançamento.