# Quatro mil e trezentas conversas por clique
> A caixa de entrada do meu CRM demorava a abrir e todo mundo, eu inclusive, apontou para o banco de dados. O banco estava bem. Quem decidia carregar tudo era a tela.
Alex Mërović · 1 de novembro de 2026 · https://alexmerovic.com.br/blog/quatro-mil-e-trezentas-conversas-por-clique/
---
Anônimo, São Cristóvão carregando Cristo, 1510-20. Madeira de tília policromada. The Metropolitan Museum of Art, Nova York (The Cloisters Collection, 1973). Domínio público (CC0), via Met Open Access.
## O suspeito de sempre {: #suspeito }
Quando a caixa de entrada do CRM que construí ficou lenta, a hipótese que todo mundo oferece nessas horas foi a do banco de dados, e fui o primeiro a oferecê-la. Medi antes de agir, num relatório de 8 de outubro de 2026, e o banco não estava pesado.
{: .abre }
O que a medição mostrou foi mais banal e mais difícil de aceitar. A tela da caixa de entrada carregava 4.321 conversas, cerca de 8 MB, a cada renderização, e ainda fazia uma atualização extra assim que montava. Tudo isso rodava num servidor de um único núcleo virtual. O banco respondia depressa à pergunta que lhe faziam, que era "me dê tudo", e a tela cuidava do resto, que era receber, montar e jogar fora a maior parte.
Quem usa uma caixa de entrada olha, em geral, para as primeiras conversas e para as que ainda não leu. A lista inteira, com milhares de linhas que ninguém tinha pedido, era um custo pago por cada pessoa, em cada clique, para entregar algo que não ia ser lido. Lentidão assim tem pouco de infraestrutura e muito de uma decisão de projeto tomada uma vez, há muito tempo, quando a base tinha cem conversas e carregar tudo parecia uma gentileza.
## A pergunta que mudou o plano {: #pergunta }
Em vez de perguntar como carregar mais depressa, perguntei o que a tela precisa mostrar agora. A resposta saiu em uma frase, e quem a deu foi o dono do produto, com a regra que passou a valer: quinze conversas por vez, ou todas as não lidas, até o teto de cinquenta, e o resto aparece quando se rola a lista, por cursor.
Paginar por cursor é pedir "as próximas quinze depois desta aqui", e não "a página três". A diferença parece sutil e importa numa caixa de entrada, onde conversas novas chegam o tempo todo e deslocam a numeração. O cursor guarda um ponto de referência, e não uma posição que muda enquanto a pessoa lê.
Os números do antes e do depois, medidos em produção, foram estes: a lista inicial foi de 3,35 segundos para 0,30 segundo, e a carga de 10,5 MB para 43 KB. É uma redução de mais de cem vezes no volume que viaja, sem uma linha alterada no banco.
## O que não fiz {: #naofiz }
Havia uma tentação perfeitamente respeitável, a de criar índices. Índice é o remédio que se prescreve a qualquer lentidão de consulta, e fica bem no relatório. Testei os candidatos, e nenhum deu ganho mensurável. Não os criei. Um índice sem ganho é custo de escrita, é espaço e é uma promessa de otimização que ninguém depois se lembra de desfazer.
A primeira versão da paginação também não passou limpa. Um agente revisor a reprovou na primeira rodada, com dois defeitos graves, e a aprovou na segunda. Esse histórico me interessa porque a correção de lentidão é o tipo de mudança que parece segura, e é justamente por isso que merece segunda leitura: ela altera o que o usuário vê, não só quanto tempo leva.
A segunda onda de ajustes trabalhou o entorno. Guardar em cache o usuário atual, desligar a pré-busca de rotas que quase ninguém abre, carregar sob demanda o que não aparece de imediato e usar um marcador de versão nas mídias. A tela de operação saiu de cerca de 1,2 segundo para cerca de 0,1. O quadro de tarefas, em vez de paginado, foi enxugado, de 2,07 MB para 0,85 MB, porque a pessoa que o usa prefere ver tudo de uma vez, e pagar o preço em peso menor.
Também decidi o que não mudar. A tentação seguinte, a de tirar o sistema da hospedagem atual e levar para uma infraestrutura maior, ficou adiada para quando houver quarenta ou cinquenta clientes, ou uma promessa de disponibilidade que a máquina de hoje não cumpra. Sem esse motivo, trocar de servidor seria resolver com dinheiro um problema que se resolveu com uma pergunta.
## O gigante {: #gigante }
Um escultor anônimo entalhou, entre 1510 e 1520, um São Cristóvão em madeira de tília, hoje no museu The Cloisters, em Nova York.[^1] A peça tem cerca de um metro e meio e pesa 32 quilos. Um homem de barba atravessa a água, com a cabeça virada para cima e um cajado de ramos cortados na mão esquerda; veste túnica azul e manto marrom, e leva sobre o ombro uma criança de cabelo encaracolado que levanta o braço e segura uma pequena esfera. A base, pintada de azul acinzentado, imita ondas que chegam à altura do tornozelo.
A lenda diz que o gigante atravessava viajantes pelo rio e que, certa noite, uma criança tão leve na aparência pesou como o mundo. É a história de um carregador que descobre a carga pelo peso. A escultura a conta bem, porque o corpo do homem está todo na tensão de quem sustenta algo: o torso inclinado, a mão firmando a perna do menino, o olhar subindo.
Penso nele diante da minha caixa de entrada antiga. O gigante carregava a travessia inteira, sem pausa, e o meu servidor carregava as 4.321 conversas, inclusive as que a margem do outro lado nem ia usar. A diferença entre os dois é que o carregador de pedra tem uma razão, a de que o peso é a própria missão. A minha tela tinha só um hábito.
O ganho do trabalho todo veio da pergunta que o gigante nunca faz, a de quem precisa de quê, e quando. Do carregamento, o que a margem espera é uma criança por vez.
## O que isso muda {: #muda }
Há uma lição prática que cabe em três linhas. Primeiro, medir antes de culpar: o banco foi absolvido por um número. Segundo, perguntar o que a tela precisa mostrar agora, em vez de otimizar o que ela carregava. Terceiro, recusar o remédio que não tem prova, como o índice sem ganho.
Boa parte da lentidão que se atribui à máquina é a lentidão de quem nunca decidiu quanto carregar.
{: .destaca }
Registro a ressalva que a honestidade pede. As medidas de antes e depois são de condições de teste e de produção que descrevi no relatório, e a medição de um dia útil comum, com muitos usuários, ficou como tarefa pendente. O número de 0,30 segundo vale para o que medi. Se a base dobrar, a conta se refaz, embora o desenho por cursor mantenha o custo da primeira tela quase constante, que é o motivo de tê-lo escolhido.
A madeira de tília nunca vai a lugar nenhum, e o gigante, em cinco séculos, não deu um passo. Meu sistema anda todos os dias, e o que aprendi com a imagem foi menos sobre o peso e mais sobre a escolha do que se põe nos ombros.
{: .fim }
[^1]: Anônimo, *Saint Christopher Carrying Christ* (*São Cristóvão carregando Cristo*), 1510-20. Madeira de tília, 143,5 x 49,5 x 36,8 cm. The Metropolitan Museum of Art, Nova York, The Cloisters Collection, 1973 (1973.135).
