Bling está lento: é a sua internet ou é o sistema?

São quase onze da manhã, o faturamento precisa sair e o Bling trava numa tela em branco. Alguém diz que a internet está péssima. O responsável pela TI abre um teste de velocidade, vê 300 Mbps e responde que a internet está ótima — o problema é o sistema. A discussão morre sem conclusão e todo mundo volta a esperar.

O detalhe é que os dois lados testaram coisas diferentes, e nenhum dos dois provou nada. Este guia mostra como sair do achismo em poucos minutos, com números que qualquer pessoa consegue obter — e o que fazer depois que você souber de quem é a culpa.

Por que o teste de velocidade não resolve essa briga

Um teste de velocidade responde uma pergunta específica: quantos megabits por segundo o seu link consegue transferir quando está sendo usado ao máximo, contra um servidor escolhido por ele. É uma informação útil, mas responde a pergunta errada quando o assunto é sistema de gestão travando.

Sistema web como Bling, Omie, TagPlus, Conta Azul ou Tiny não move volume grande de dados. Uma tela de pedido tem alguns poucos megabytes na primeira visita, e depois quase tudo vem do cache. O que esse tipo de sistema faz o tempo inteiro é trocar muitas mensagens pequenas: buscar um cliente, validar um campo, calcular um imposto, salvar um rascunho. Cada uma dessas mensagens é uma ida e volta até o servidor.

Quando você faz cinquenta idas e voltas para montar uma tela, o que domina o tempo não é a velocidade — é a latência, o tempo de cada ida e volta. Com 15 ms de latência, cinquenta viagens custam 0,75 segundo. Com 300 ms, as mesmas cinquenta viagens custam 15 segundos, mesmo que o teste de velocidade continue exibindo 300 Mbps orgulhosamente.

É por isso que a frase "a internet está ótima, deu 300 Mbps" não encerra nada. Ela mede o cano; o problema costuma estar na distância.

Os três suspeitos de sempre

Quando uma tela demora a aparecer, o tempo foi gasto em um destes três lugares — e a única forma honesta de decidir é medindo cada um:

1. A rede entre você e o servidor

Inclui o seu Wi-Fi, o cabo, o roteador, o link do provedor e todo o caminho até o datacenter onde o sistema roda. Sintomas típicos: tudo fica lento ao mesmo tempo, inclusive sites que não têm relação nenhuma entre si; a lentidão vai e volta ao longo do dia; piora quando mais gente está usando a rede.

2. O servidor do sistema

É o tempo que o backend leva pensando: consultando o banco, aplicando regra de negócio, montando a resposta. Sintomas: só aquele sistema está lento, enquanto o resto da internet vai bem; a lentidão aparece em horários específicos (fechamento, início do mês); acontece igual em todas as máquinas da empresa e também na rede de casa.

3. O seu computador

O navegador precisa interpretar o HTML, executar o JavaScript, calcular o layout e desenhar. Sistemas modernos mandam muito código para o navegador executar. Sintomas: só a sua máquina está lenta enquanto a do colega vai bem na mesma rede; o computador esquenta e a ventoinha acelera; melhora depois de fechar abas ou reiniciar.

O truque que separa rede de servidor

Aqui está o método que resolve a discussão, e ele é mais simples do que parece. Ao pedir uma página, o navegador espera um tempo até o primeiro byte chegar. Esse tempo é a soma de duas coisas: a viagem até o servidor e a volta, mais o tempo que o servidor gastou pensando. Como separar as duas?

Comparando dois pedidos ao mesmo endereço:

Pedido	O que o tempo contém
Um arquivo estático (imagem, CSS, JavaScript)	Praticamente só a ida e volta de rede — o servidor não precisa "pensar" para entregar um arquivo que já está pronto no disco.
A página dinâmica	A mesma ida e volta mais o processamento do backend: consulta ao banco, regra de negócio, montagem da resposta.

A diferença entre os dois é o tempo de processamento do servidor, isolado da rede. Se o arquivo estático volta em 40 ms e a página dinâmica em 1.900 ms, o servidor gastou cerca de 1.860 ms pensando — e nenhuma troca de plano de internet vai consertar isso.

Se os dois voltam em 800 ms, o servidor está tranquilo e o problema é a distância até ele: pode ser a sua rede, pode ser hospedagem longe, pode ser rota ruim do provedor.

O gráfico acima é de uma medição real. O carregamento levou 8,4 segundos, e a tentação seria culpar o sistema. Mas o servidor respondeu em 64 milissegundos — ele fez a parte dele quase instantaneamente. Os 7,9 segundos foram embora na rede, num link com 287 ms de latência e 3,4% de perda de pacotes. Culpar o Bling nesse caso seria injusto e, pior, inútil: o chamado ia rodar semanas sem solução.

Como medir na prática, em 15 segundos

Dá para fazer tudo isso à mão pelo F12 do navegador, na aba Rede, olhando a coluna de tempo e separando o TTFB dos arquivos estáticos e dinâmicos. Funciona, mas exige prática para interpretar e não mede a sua conexão ao mesmo tempo.

A alternativa é usar a extensão Lento Quem?, que foi feita exatamente para isso: com o sistema lento aberto na frente, um clique mede os dois lados na mesma execução e devolve a divisão do tempo em milissegundos, junto de uma frase dizendo de quem é a culpa. O diagnóstico é gratuito e não pede cadastro.

O que ela mede do lado da sua conexão:

• Latência real, obtida do tempo de ida e volta medido pelo próprio kernel do servidor de teste, e não estimada por HTTP;
• Perda de pacotes, pelas retransmissões TCP reais;
• Download e upload em conexões paralelas;
• Latência sob carga, ou seja, quanto a conexão piora quando o link está ocupado — o famoso bufferbloat, que nenhum teste comum mostra.

E do lado do sistema: tempo de processamento do servidor isolado, peso da página, número de requisições, recursos mais lentos um por um e congestionamento da thread principal do navegador.

O que fazer com o resultado

Se a culpa for da sua conexão

Comece pelo mais provável: o Wi-Fi. Testar com cabo por dez minutos elimina metade dos casos. Se os números melhoram no cabo, o problema é o rádio — distância, parede, canal congestionado ou aparelho antigo demais.

Se o cabo não mudar nada, verifique quem mais está usando a rede: backup em nuvem, atualização do sistema operacional, câmera enviando vídeo, streaming. Depois, olhe a latência sob carga: se ela dispara quando alguém baixa algo, o roteador está com o problema de fila conhecido como bufferbloat, e a solução é ativar SQM ou QoS — não trocar de plano.

Só depois disso vale acionar o provedor, e aí leve números: latência, jitter, porcentagem de perda e horários. Reclamação com medição é tratada de forma diferente de reclamação com adjetivo.

Se a culpa for do servidor do sistema

Não há nada que você possa fazer na sua máquina — e essa é justamente a informação valiosa. Limpar cache, trocar de navegador, reiniciar o roteador ou formatar o computador não vão mudar um tempo que é gasto do outro lado, antes do primeiro byte sair de lá.

O que fazer é abrir chamado com o fornecedor informando o tempo de processamento medido, o horário e a tela específica. Fornecedor sério trata esse tipo de relato com prioridade porque ele aponta direto para o gargalo. Guarde também o histórico: mostrar que a mesma tela respondia em 200 ms na semana passada e agora leva 1,9 s é o argumento mais forte que existe.

Se a culpa for do navegador

Teste em uma janela anônima, que roda sem extensões. Se melhorar, alguma extensão está pesando. Se não melhorar, olhe a memória da máquina: sistema de gestão com muitas abas abertas em computador de 4 ou 8 GB vive no limite, e o navegador passa a disputar CPU com ele mesmo.

Quanto tempo é aceitável, afinal?

Sem referência, qualquer número parece ruim. Estas faixas ajudam a calibrar o julgamento antes de abrir chamado:

Medida	Bom	Aceitável	Ruim
Latência até a borda mais próxima	até 30 ms	30 a 80 ms	acima de 150 ms
Perda de pacotes	0%	até 0,5%	acima de 2%
Processamento do servidor	até 200 ms	200 a 600 ms	acima de 1 s
Aumento da latência sob carga	até 40 ms	40 a 120 ms	acima de 400 ms
Tela pronta para uso	até 1,5 s	1,5 a 3 s	acima de 5 s

Repare que a coluna decisiva raramente é a velocidade em megabits. Um link de 20 Mbps com 15 ms de latência e zero perda entrega experiência melhor, em sistema de gestão, que um link de 500 Mbps com 200 ms e 2% de perda. Quem vende internet fala em megabits porque é o número fácil de comparar; quem usa sistema sente latência.

Três padrões que denunciam a origem sem medir nada

Antes mesmo de abrir qualquer ferramenta, o padrão de quando a lentidão aparece já elimina suspeitos:

Lentidão com hora marcada, todo dia

Se começa sempre no mesmo horário — 9h quando todo mundo chega, 14h depois do almoço —, o mais provável é saturação da rede local ou do link. Alguma coisa começa a consumir banda nesse horário: sincronização de nuvem, backup, atualização automática. Vale investigar antes de acusar o sistema, porque o sistema não sabe que horas são.

Lentidão em dia de fechamento

Se o sistema arrasta no dia 30 e no dia 5, mas vai bem no resto do mês, o padrão aponta para carga no servidor: todo mundo faturando ao mesmo tempo. Aqui o chamado com o fornecedor é legítimo e o argumento é forte, porque o comportamento é reproduzível e previsível.

Lentidão só em algumas telas

Se o cadastro abre rápido e só o relatório demora, quase certamente é consulta pesada no banco de dados. Rede lenta não escolhe tela — ela atrasa tudo por igual. Essa observação simples já economiza dias de investigação no lado errado.

Um erro comum: confundir primeira visita com uso diário

A primeira vez que alguém abre o sistema no dia baixa tudo: código, estilos, fontes, imagens. As visitas seguintes reaproveitam o cache. Se você medir só a primeira visita, vai superestimar o peso; se medir só depois, vai subestimar.

Um caso específico merece atenção: servidores que hibernam. Muitos sistemas hospedados em nuvem desligam o processo quando ninguém acessa e precisam subir de novo na próxima visita. O resultado é a primeira pessoa da manhã esperando 3 segundos enquanto todo mundo depois é atendido em 200 ms. Se a sua medição mostra um tempo alto no carregamento vivido e um tempo baixo ao repetir o pedido, é exatamente isso — e a solução está com o fornecedor, não com você.

Perguntas que vale responder antes de abrir chamado

1. Outros sites estão lentos também? Se sim, aponta para a rede. Se só o sistema está lento, aponta para o servidor.
2. Está lento em todas as máquinas? Se só em uma, é o computador ou o Wi-Fi daquele ponto.
3. Está lento na rede de casa também? Se sim, a rede da empresa está inocente.
4. Tem horário? Lentidão que aparece sempre às 14h costuma ser saturação de link; lentidão no fechamento do mês costuma ser carga no servidor.
5. Melhorou depois de reiniciar o roteador? Se sim, foi rede. Se voltou em uma hora, o roteador está no limite.

Vale para qualquer sistema, não só o Bling

O método é o mesmo para qualquer coisa que abra no navegador: Omie, Conta Azul, Tiny, Sankhya, TOTVS, Senior, Nuvemshop, VTEX, RD Station, Pipedrive, SEI, PJe, e-CAC, Compras.gov.br, internet banking ou o sistema interno da sua empresa. Muda o endereço; a lógica de separar rede, servidor e navegador continua idêntica.

A diferença entre discutir e resolver é ter três números na mão: quanto tempo foi de rede, quanto foi de servidor e quanto foi do navegador. Com eles, o chamado vai para o lugar certo na primeira tentativa — e ninguém precisa trocar de plano de internet por causa de um problema que estava no backend.