Listas de dashboard rápidas com 100k linhas: por onde começar

Por que telas de lista ficam lentas à medida que os dados crescem

Uma tela de lista geralmente parece ok até que deixa de ser. Usuários começam a notar pequenas travadas que se acumulam: rolagem com gagueira, a página fica presa por um instante após cada atualização, filtros demoram segundos para responder e aparece um spinner a cada clique. Às vezes a aba do navegador parece congelada porque a thread de UI está ocupada.

100k linhas é um ponto de virada comum porque estressa todas as partes do sistema ao mesmo tempo. O conjunto de dados ainda é normal para um banco, mas já é grande o suficiente para tornar ineficiências pequenas óbvias no navegador e na rede. Se você tentar mostrar tudo de uma vez, uma tela simples vira um pipeline pesado.

O objetivo não é renderizar todas as linhas. O objetivo é ajudar alguém a encontrar o que precisa rápido: as 50 linhas certas, a próxima página, ou um recorte estreito baseado em um filtro.

Ajuda dividir o trabalho em quatro partes:

• Rede: quantos bytes você envia e com que frequência.
• Banco de dados: quanto dado você escaneia, ordena e agrega por requisição.
• Renderização no navegador: quantos nós do DOM você cria, mede e pinta.
• Trabalho em JavaScript: com que frequência você re-renderiza, recalcula colunas ou recomputa resultados.

Se qualquer uma dessas partes for cara, a tela inteira fica lenta. Uma busca simples pode disparar uma requisição que ordena 100k linhas, retorna milhares de registros e então força o navegador a renderizá-los todos. É assim que digitar fica travado.

Quando equipes constroem ferramentas internas rapidamente (inclusive com plataformas estilo vibe-coding como Koder.ai), telas de lista costumam ser o primeiro lugar onde o crescimento real de dados expõe a diferença entre "funciona no conjunto de demo" e "parece instantâneo todo dia".

Escolha a meta de performance certa

Antes de otimizar, decida o que significa ser rápido nessa tela. Muitas equipes correm atrás de throughput (carregar tudo) quando os usuários precisam principalmente de baixa latência (ver algo atualizar rápido). Uma lista pode parecer instantânea mesmo que nunca carregue as 100k linhas, desde que responda rápido ao rolar, ordenar e filtrar.

Uma meta prática é tempo até a primeira linha, não tempo até carregar tudo. Usuários confiam na página quando veem as primeiras 20 a 50 linhas rapidamente e as interações continuam suaves.

O que medir (e por quê)

Escolha um pequeno conjunto de números que você possa acompanhar sempre que mudar algo:

• Tempo até a primeira linha após abrir a página ou alterar um filtro
• Tempo para um filtro ou ordenação mostrar resultados atualizados
• Tamanho da resposta (tamanho aproximado do payload JSON)
• Consultas lentas (especialmente COUNT(*) e SELECTs amplas)
• Picos na thread principal do navegador (gagueira na rolagem, lag ao digitar)

Esses pontos se mapeiam para sintomas comuns. Se a CPU do navegador sobe quando você rola, o frontend está fazendo muito trabalho por linha. Se o spinner espera mas a rolagem fica bem depois, o problema normalmente é backend ou rede. Se a requisição é rápida mas a página ainda congela, quase sempre é renderização ou processamento pesado no cliente.

Um teste rápido frontend vs backend

Tente um experimento simples: mantenha a UI igual, mas limite temporariamente o backend para retornar apenas 20 linhas com os mesmos filtros. Se ficar rápido, seu gargalo é tamanho de carga ou tempo de consulta. Se continuar lento, olhe para renderização, formatação e componentes por linha.

Exemplo: uma tela interna de Orders parece lenta quando você digita na busca. Se a API retorna 5.000 linhas e o navegador as filtra a cada pressionar de tecla, digitar vai travar. Se a API demora 2 segundos por causa de um COUNT em um filtro sem índice, você vai ver espera antes de qualquer linha mudar. Fixes diferentes, mesma reclamação do usuário.

Noções básicas de frontend: mantenha a renderização barata

O navegador costuma ser o primeiro gargalo. Uma lista pode parecer lenta mesmo quando a API é rápida, simplesmente porque a página está tentando pintar demais. A primeira regra é simples: não renderize milhares de linhas no DOM de uma vez.

Mesmo antes de adicionar virtualização completa, mantenha cada linha leve. Uma linha com wrappers aninhados, ícones, tooltips e estilos condicionais complexos em cada célula custa caro a cada rolagem e atualização. Prefira texto simples, alguns badges pequenos e apenas um ou dois elementos interativos por linha.

Altura de linha estável ajuda mais do que parece. Quando cada linha tem a mesma altura, o navegador pode prever o layout e a rolagem fica suave. Linhas de altura variável (descrições que quebram linha, notas expansíveis, avatares grandes) disparam medições extras e reflows. Se precisar de detalhes extras, considere um painel lateral ou uma área expansível única, não uma linha multi-linha completa.

Formatação é outro custo silencioso. Datas, moedas e manipulação pesada de strings somam quando repetidos em muitas células.

Regra prática simples

Se um valor não está visível, não o calcule ainda. Faça cache de formatações caras e calcule sob demanda, por exemplo quando uma linha fica visível ou quando o usuário abre uma linha.

Um conjunto de ações rápidas que frequentemente traz ganhos notáveis:

• Limite a renderização inicial a uma página pequena (ou janela virtual)
• Mantenha altura de linha fixa e evite células multi-linha
• Empurre UI pesada (tooltips, menus) para hover ou clique
• Memoize ou faça cache da formatação de datas e valores monetários por linha
• Evite re-renderizar todas as linhas quando só um filtro muda

Exemplo: uma tabela interna de Invoices que formata 12 colunas de moedas e datas vai gaguejar na rolagem. Cachear os valores formatados por invoice e adiar trabalho para linhas fora de tela pode deixá-la instantânea, mesmo antes de trabalhar o backend profundamente.

Virtualização: como rolar 100k linhas suavemente

Virtualização significa que a tabela só desenha as linhas que você realmente pode ver (mais um pequeno buffer acima e abaixo). Conforme você rola, ela reaproveita os mesmos elementos DOM e troca os dados dentro deles. Isso impede que o navegador tente pintar dezenas de milhares de componentes de linha de uma vez.

A virtualização é um bom ajuste quando você tem listas longas, tabelas largas ou linhas pesadas (avatares, chips de status, menus de ação, tooltips). Também é útil quando usuários rolam bastante e esperam uma vista contínua e suave em vez de pular página a página.

Onde a virtualização fica complicada

Não é mágica. Algumas coisas costumam causar surpresas:

• Alturas de linha variáveis (texto que quebra, linhas expansíveis) podem quebrar a rolagem suave a menos que você meça alturas ou mantenha linhas de tamanho previsível.
• Cabeçalhos e colunas fixas podem conflitar com o container virtualizado se o layout depender de CSS complexo.
• Navegação por teclado (setas para cima/baixo, page up/down, foco em células) precisa de cuidado extra para que o foco não pule para linhas desmontadas.
• Ações em massa precisam de uma regra clara: selecionar linhas visíveis, selecionar em todo o filtro ou selecionar em todo o dataset.

A abordagem mais simples é chata: altura fixa por linha, colunas previsíveis e não muitas widgets interativas dentro de cada linha.

Virtualização mais paginação (sem confundir usuários)

Você pode combinar ambos: use paginação (ou carregar mais com cursor) para limitar o que busca no servidor, e virtualização para manter a renderização barata dentro do slice buscado.

Um padrão prático é buscar um tamanho de página normal (frequentemente 100 a 500 linhas), virtualizar dentro dessa página e oferecer controles claros para navegar entre páginas. Se usar rolagem infinita, adicione um indicador visível “Carregado X de Y” para que os usuários entendam que ainda não estão vendo tudo.

Escolhas de paginação que se mantêm rápidas

Se você precisa de uma lista que permaneça utilizável conforme os dados crescem, paginação costuma ser o padrão mais seguro. É previsível, funciona bem para fluxos administrativos (revisar, editar, aprovar) e suporta necessidades comuns como exportar “página 3 com estes filtros” sem surpresas. Muitas equipes voltam para paginação depois de tentar rolagens mais fancy.

Rolagem infinita pode ser agradável para navegação casual, mas tem custos ocultos. Pessoas perdem a noção de posição, o botão voltar frequentemente não retorna ao mesmo ponto e sessões longas podem acumular memória conforme mais linhas são carregadas. Um meio-termo é um botão Carregar mais que ainda usa páginas, assim os usuários se mantêm orientados.

Paginação por offset vs keyset

Paginação por offset é o clássico page=10&size=50. É simples, mas pode ficar mais lenta em tabelas grandes porque o banco pode ter que pular muitas linhas para alcançar páginas finais. Também pode parecer estranho quando novas linhas chegam e itens mudam de página.

Paginação por keyset (frequentemente chamada de cursor) pede as “próximas 50 linhas após o último item visto”, geralmente usando um id ou created_at. Ela tende a ficar rápida porque não precisa contar e pular tanto trabalho.

Uma regra prática:

• Use offset para listas menores, datasets estáveis e quando for necessário pular para um número de página exato.
• Use keyset para listas muito grandes, inserções frequentes e navegação Próximo/Anterior.

Mostrar totais sem pagar o preço sempre

Usuários gostam de ver totais, mas um “count all matching rows” completo pode ser caro com filtros pesados. Opções incluem cachear contagens para filtros populares, atualizar a contagem em segundo plano depois que a página carrega ou mostrar uma contagem aproximada (por exemplo, “10.000+”).

Exemplo: uma tela interna de Orders pode mostrar resultados instantaneamente com paginação por keyset, e preencher o total exato apenas quando o usuário para de mudar filtros por um segundo.

Se você está construindo isso no Koder.ai, trate comportamento de paginação e contagem como parte da especificação da tela desde cedo, para que as queries geradas e o estado da UI não entrem em conflito depois.

Filtros e buscas que parecem instantâneos

A maioria das telas de lista fica lenta porque começa muito aberta: carrega tudo e depois pede para o usuário filtrar. Inverta isso. Comece com padrões sensatos que retornem um conjunto pequeno e útil (por exemplo: últimos 7 dias, Meus itens, Status: Aberto) e torne “Todo o período” uma escolha explícita.

Busca por texto é outra armadilha comum. Se você executa uma query a cada tecla, você cria um backlog de requisições e uma UI que pisca. Faça debounce na entrada de busca para só consultar depois que o usuário fizer uma pausa breve e cancele requisições antigas quando uma nova começar. Uma regra simples: se o usuário ainda está digitando, não bata no servidor ainda.

Filtrar só parece rápido quando também é claro. Mostre chips de filtro perto do topo da tabela para que os usuários vejam o que está ativo e possam remover com um clique. Mantenha os rótulos dos chips humanos, não nomes crus de campos (por exemplo, Dono: Sam em vez de owner_id=42). Quando alguém diz “meus resultados desapareceram”, geralmente é um filtro invisível.

Padrões que mantêm listas grandes responsivas sem complicar a UI:

• Default para filtros mais restritos e um intervalo de datas curto
• Debounce na busca por texto e cancelamento de requisições em andamento
• Mostrar chips de filtro e uma ação Limpar tudo
• Oferecer visualizações salvas para tarefas comuns
• Bloquear filtros caros até que ao menos um filtro de estreitamento esteja definido

Visualizações salvas são o herói discreto. Em vez de ensinar usuários a montar combos de filtros uma vez, dê alguns presets que batem com fluxos reais. Uma equipe de ops pode alternar entre Pagamentos falhados hoje e Clientes de alto valor. Esses podem ser um clique, instantâneos e mais fáceis de manter rápidos no backend.

Se você construir uma ferramenta interna em um construtor guiado por chat como o Koder.ai, trate filtros como parte do fluxo do produto, não um acréscimo. Comece pelas perguntas mais comuns e desenhe a visão padrão e as visualizações salvas ao redor disso.

Modelagem de consultas: peça menos, compute menos

Uma tela de lista raramente precisa dos mesmos dados que uma página de detalhe. Se sua API retorna tudo sobre tudo, você paga duas vezes: o banco faz mais trabalho e o navegador recebe e renderiza mais do que usa. Query shaping é o hábito de pedir apenas o que a lista precisa agora.

Comece retornando apenas as colunas necessárias para renderizar cada linha. Para a maioria dos dashboards isso é um id, alguns rótulos, um status, um responsável e timestamps. Texto grande, blobs JSON e campos computados podem esperar até o usuário abrir a linha.

Evite joins pesados para a primeira pintura. Joins são ok quando batem em índices e retornam resultados pequenos, mas ficam caros quando você junta várias tabelas e então ordena ou filtra pelos dados unidos. Um padrão simples é: busque a lista de uma tabela rapidamente e depois carregue detalhes relacionados sob demanda (ou em lote para as linhas visíveis apenas).

Mantenha opções de ordenação limitadas e ordene por colunas indexadas. “Ordenar por qualquer coisa” soa útil, mas frequentemente força ordenações lentas em datasets grandes. Prefira algumas escolhas previsíveis como created_at, updated_at ou status e garanta que essas colunas tenham índice.

Cuidado com agregações no servidor. COUNT(*) em um conjunto filtrado grande, DISTINCT em uma coluna ampla ou cálculos de total de páginas podem dominar seu tempo de resposta.

Uma abordagem prática:

• Modele a resposta da lista para 5 a 10 campos
• Busque detalhes da linha só quando ela for aberta
• Permita 2 a 4 opções de ordenação, todas suportadas por índices
• Trate COUNT e DISTINCT como opcionais e cache/approxime quando possível

Se você construir ferramentas internas no Koder.ai, defina uma query leve para listas separada da query de detalhes no planejamento, assim a UI permanece rápida conforme os dados crescem.

Táticas de banco de dados para tabelas grandes

Se você quer uma tela de lista que permaneça rápida em 100k linhas, o banco precisa fazer menos trabalho por requisição. A maioria das listas lentas não é “dados demais.” São padrões de acesso errado.

Comece com índices que correspondam ao que seus usuários realmente fazem. Se sua lista costuma ser filtrada por status e ordenada por created_at, você quer um índice que dê suporte a ambos, nessa ordem. Caso contrário o banco pode escanear muito mais linhas do que você espera e depois ordenar, o que fica caro rápido.

Correções que geralmente trazem os maiores ganhos:

• Adicione índices compostos que espelhem seu filtro + ordenação comum (por exemplo tenant_id, status, created_at).
• Prefira paginação por keyset (cursor) em vez de OFFSET profundo. OFFSET faz o banco caminhar por muitas linhas só para pulá-las.
• Trate contagem total como opcional. Totais exatos podem ser lentos em conjuntos filtrados grandes. Cacheie contagens, pré-compute ou mostre “10.000+” quando números exatos não forem exigidos.
• Mantenha linhas enxutas. Não selecione campos de texto grandes, blobs JSON ou objetos aninhados para a lista.
• Modele queries para retornar só o que a UI renderiza: poucos campos, IDs estáveis e cursor para a próxima página.

Exemplo simples: uma tabela interna Orders que mostra nome do cliente, status, valor e data. Não junte todas as tabelas relacionadas e puxe notas completas do pedido para a vista de lista. Retorne apenas as colunas usadas na tabela e carregue o resto em uma requisição separada quando o usuário clicar no pedido.

Se você está construindo com uma plataforma como Koder.ai, mantenha essa mentalidade mesmo se a UI for gerada por chat. Garanta que os endpoints gerados suportem paginação por cursor e campos seletivos, para que o trabalho do banco continue previsível conforme a tabela cresce.

Plano passo a passo para acelerar uma tela de lista existente

Se uma página de lista está lenta hoje, não comece reescrevendo tudo. Comece definindo qual é o uso normal e então otimize esse caminho.

Um plano prático em cinco passos

1. Defina a visão padrão. Escolha filtros padrão, ordem e colunas visíveis. Listas ficam lentas quando tentam mostrar tudo por padrão.

2. Escolha um estilo de paginação que combine com o uso. Se usuários olham principalmente as primeiras páginas, paginação clássica é suficiente. Se pulam muito (página 200+) ou você precisa de desempenho estável independente da profundidade, use paginação por keyset (baseada em uma ordenação estável como created_at mais um id).

3. Adicione virtualização ao corpo da tabela. Mesmo se o backend for rápido, o navegador pode travar ao renderizar muitas linhas de uma vez.

4. Faça busca e filtros parecerem instantâneos. Debounce na digitação para não disparar requisição a cada tecla. Mantenha o estado de filtro na URL ou em um store compartilhado para que refresh, botão voltar e compartilhamento funcionem bem. Cacheie o último resultado bem-sucedido para evitar flash de tabela vazia.

5. Meça, então ajuste consultas e índices. Logue tempo do servidor, tempo no banco, tamanho do payload e tempo de render. Depois aparar a query: selecione apenas as colunas que mostra, aplique filtros cedo e adicione índices que combinem com o filtro + ordenação padrão.

Exemplo: um dashboard de suporte interno com 100k tickets. Padrão para Aberto, atribuído ao meu time, ordenado por mais novo, mostrar seis colunas e buscar só ticket id, subject, assignee, status e timestamps. Com paginação por keyset e virtualização, você mantém banco e UI previsíveis.

Se construir no Koder.ai, esse plano se encaixa bem em um fluxo iterativo: ajuste a visão, teste rolagem e busca, depois afine a query até a página permanecer snappy.

Erros comuns que fazem listas engasgar

A maneira mais rápida de quebrar uma tela de lista é tratar 100k linhas como uma página normal de dados. A maioria das dashboards lentas tem algumas armadilhas previsíveis.

Uma grande é renderizar tudo e esconder com CSS. Mesmo que pareça que só 50 linhas estão visíveis, o navegador ainda paga por criar 100k nós do DOM, medi-los e repintar na rolagem. Se precisa de listas longas, renderize só o que o usuário pode ver (virtualização) e mantenha componentes de linha simples.

Busca também pode arruinar performance quando cada tecla dispara um scan completo da tabela. Isso acontece quando filtros não têm índice, quando você busca em muitas colunas ou quando faz queries de contains em campos de texto enormes sem um plano. Uma boa regra: o primeiro filtro que o usuário tende a usar deve ser barato no banco, não apenas conveniente na UI.

Outro problema comum é buscar registros completos quando a lista só precisa de resumos. Uma linha de lista normalmente precisa de 5 a 12 campos, não do objeto inteiro, não de descrições longas e não de dados relacionados. Puxar dados extras aumenta trabalho no banco, tempo de rede e parsing no frontend.

Exportar e calcular totais pode travar a UI se o trabalho for feito na thread principal ou se você esperar por uma requisição pesada antes de responder. Mantenha a UI interativa: inicie exports em background, mostre progresso e evite recalcular totais a cada mudança de filtro.

Por fim, muitas opções de ordenação podem atrapalhar. Se usuários podem ordenar por qualquer coluna, você vai acabar ordenando grandes conjuntos em memória ou forçando o banco a planos lentos. Limite ordenações a um pequeno conjunto de colunas indexadas e faça a ordenação padrão casar com um índice real.

Checagem rápida:

• Se você pode rolar para sempre sem carregar, provavelmente renderizou demais.
• Se digitar na busca trava, sua query provavelmente está escaneando.
• Se a API de lista retorna JSON enorme, você está buscando demais.
• Se exportar congela a página, o trabalho está acontecendo no lugar errado.
• Se toda ordenação é lenta, índices e opções de ordenação precisam de ajuste.

Checklist rápido e próximos passos

Trate a performance de listas como um recurso de produto, não um ajuste pontual. Uma tela de lista é rápida só quando parece rápida enquanto pessoas reais rolam, filtram e ordenam com dados reais.

Use este checklist para confirmar que corrigiu as coisas certas:

• Primeira pintura é rápida: a página carrega um payload pequeno e mostra as primeiras linhas imediatamente.
• Rolagem permanece suave: virtualização ativada, CPU do navegador não dispara e alturas de linha são previsíveis.
• Filtros parecem responsivos: digitar ou selecionar um filtro atualiza resultados rápido e filtros não são resetados ao paginar ou atualizar.
• Ordenação é sensata: permita só ordenações suportadas por índice ou campo precomputado e mantenha ordem consistente entre páginas.
• Requisições estão modeladas: a API retorna só as colunas mostradas, mais IDs estáveis e cursors, não objetos completos “só por precaução”.

Um cheque simples: abra a lista, role por 10 segundos e depois aplique um filtro comum (por exemplo Status: Aberto). Se a UI congelar, o problema geralmente é renderização (linhas DOM demais) ou uma transformação pesada no cliente (ordenar, agrupar, formatar) acontecendo a cada atualização.

Próximos passos, na ordem, para não ficar pulando entre consertos:

1. Meça um fluxo de usuário fim a fim (carregar, rolar, filtrar, ordenar) e escreva tempos alvo.
2. Ative virtualização e limite formatações caras nas células (datas, moeda, avatares).
3. Mova filtragem e ordenação para o servidor e limite opções ao que pode ser rápido.
4. Aperte suas queries e payloads, então meça de novo.

Se você construir isso com Koder.ai (koder.ai), comece no Planning Mode: defina exatamente as colunas da lista, campos de filtro e o formato da resposta primeiro. Depois itere usando snapshots e rollback quando um experimento deixar a tela mais lenta.