← Voltar ao blog
performancefrontendprodutocarreira

Quem paga pela lentidão do seu site

2026-10-09

Quem paga pela lentidão do seu site

A cena se repete com uma regularidade quase cômica. Alguém abre o relatório de build, mostra que o bundle passou de algum limite, e propõe uma semana de trabalho para cortar trezentos kilobytes. A sala concorda que é importante. Ninguém discorda. E a tarefa entra no backlog num lugar de onde não volta.

Levei muito tempo para entender que o problema não estava na prioridade da sala. Estava na unidade que eu levava para ela.

Kilobyte não é problema de ninguém. É uma medida sem dono. Quando você diz "o bundle tem 646 KB", a pessoa do outro lado da mesa precisa fazer sozinha a tradução de bytes para consequência, e ela não vai fazer. Não porque seja desatenta, mas porque esse é o seu trabalho, não o dela.

O que "precisamos otimizar o bundle" realmente quer dizer

Quando um dev diz essa frase, ele quase nunca está pedindo uma otimização. Está dizendo outra coisa, geralmente sem as palavras: tem gente tentando usar isso e não conseguindo, e eu não consigo provar quem.

Essa é uma frase bem mais difícil de ignorar. Também é bem mais difícil de sustentar, porque exige saber quem é essa pessoa. E é aí que a maioria das discussões de performance morre: no fato de que a gente mede a pessoa errada.

A página mobile mediana hoje entrega 2.164 KB. O percentil 90 entrega 8.337 KB. São quase quatro vezes mais bytes para o mesmo produto, dependendo de onde você olha. A mediana é confortável. O percentil 90 é onde mora o usuário que você nunca vê, porque ele fecha a aba antes de virar um dado no seu funil.

Medir a média é um jeito educado de medir a si mesmo.

Três vantagens que você tem e seu usuário não

Toda vez que você abre o próprio produto, você faz isso com três privilégios acumulados.

  • A rede. Wifi de escritório ou fibra em casa, com latência baixa e sem concorrência.
    • O aparelho. Provavelmente o melhor celular que você já teve, ou pior, o desktop.
      • O cache. Você já abriu essa página cem vezes. Quase nada é baixado de novo.

      Nenhum desses três existe na primeira visita de alguém que chegou por um link. E dois deles são invisíveis no seu próprio monitoramento, porque o seu monitoramento também roda a partir de lugares bem conectados.

      No Brasil esse descompasso tem número. O país fechou 2025 com 270,2 milhões de acessos móveis, dos quais 58,1 milhões em 5G — pouco mais de 21%. Quase quatro em cada cinco acessos estão em outra rede. A cobertura de 5G chegou a 64,94% da população, o que é um avanço real e ainda assim não é todo mundo, e cobertura disponível não é a mesma coisa que conexão em uso.

      É um detalhe que muda a conversa. "O site está lento" é opinião. "Quase 79% dos acessos móveis do país não estão em 5G, e o nosso cadastro envia 646 KB de JavaScript antes de pintar o primeiro campo" é uma afirmação que alguém precisa responder.

      O custo não é o download

      Essa parte costuma ser mal explicada, inclusive por mim durante um bom tempo.

      Os 646 KB de JavaScript que uma página mobile mediana entrega hoje não são só uma transferência. São código que o aparelho precisa baixar, descompactar, interpretar e executar antes de conseguir desenhar a interface. Numa conexão ruim o download dói. Num processador de celular de três ou quatro anos atrás, a execução dói junto, e essa parte não melhora se você trocar a rede.

      É por isso que o argumento "mas o 5G está chegando" não resolve o problema. Banda larga maior conserta o transporte. Não conserta a conta de interpretar e executar código num aparelho modesto.

      E vale olhar como chegamos aqui. A home mediana em mobile saiu de 845 KB em julho de 2015 para 2.559 KB em julho de 2025, um crescimento de 202,8% em dez anos. Nenhuma reunião aprovou isso. Ninguém escreveu um documento defendendo que a página deveria triplicar. Foi acumulado, uma dependência de cada vez, cada uma justificável sozinha.

      O critério que eu uso agora

      Mudei a forma de levar o assunto para a mesa, e a taxa de aprovação mudou junto.

      Primeiro: troco a unidade antes de entrar na reunião. Não falo em kilobytes. Falo em qual tela, para qual tipo de usuário, em qual condição de rede. "O cadastro não abre em celular antigo no 4G" é uma frase que tem dono e tem urgência. "Reduzir 300 KB" não tem nem uma coisa nem outra.

      Segundo: meço o percentil 90, não a média. Se o seu monitoramento só mostra média, ele está configurado para te tranquilizar. O número que importa é o do pior quartil, porque é ele que descreve a experiência que está te custando gente.

      Terceiro: levo uma pessoa, não um número. Uma sessão gravada, um relato de suporte, um vídeo do fluxo rodando com a rede limitada. A gravação de trinta segundos de uma tela branca convence mais que qualquer gráfico, porque ela é incômoda de assistir.

      E quarto, o mais chato de admitir: se eu não consigo nomear quem paga, talvez ninguém esteja pagando. O que me leva à parte honesta.

      Quando o oposto é a resposta certa

      Nem toda lentidão merece ser corrigida, e tratar performance como valor absoluto é outra forma de errar.

      Se o produto é uma ferramenta interna, usada por quarenta pessoas que estão todas no mesmo escritório, com os mesmos notebooks fornecidos pela empresa, o percentil 90 e a mediana são praticamente a mesma coisa. Não existe usuário escondido na cauda. Nesse caso, cortar bundle é otimizar algo que não tem custo, e o tempo gasto ali é tempo que não foi para uma funcionalidade que alguém pediu.

      O mesmo vale para um painel que uma equipe deixa aberto o dia inteiro. O custo de carregamento é pago uma vez, de manhã, e amortizado em oito horas de uso. Vinte segundos de carga inicial num produto assim é irritante, não é caro.

      E existe o caso em que a lentidão é real, mas não é o gargalo. Um site que carrega devagar e converte mal pode estar convertendo mal porque não diz o preço, não diz o prazo e não diz para quem já trabalhou. Nenhum desses três se resolve com code splitting. Se você otimizar primeiro, vai ganhar meio segundo e nenhuma venda, e ainda vai ter gastado o seu capital político com o assunto errado.

      A pergunta que separa os casos é sempre a mesma: existe alguém, com conexão e aparelho piores que os meus, tentando fazer uma coisa específica neste produto e desistindo? Se você consegue responder quem, performance virou trabalho de produto. Se não consegue, ainda é vaidade técnica, por mais verdadeiro que o número seja.


      Vale perguntar: no seu monitoramento, você consegue ver o percentil 90 — ou só a média que te deixa tranquilo?

      📩 Vamos conversar