Kastavo

Como melhorar a performance do seu site: o que aprendi indo de 44 a 98

Um número baixo de performance pode ter mais de uma causa — e às vezes a correção certa só aparece quando você mede do jeito certo.

5 min de leitura

  • kastavo
  • desempenho
Uma curva luminosa subindo em um gráfico escuro, como o ganho de velocidade de um site

Semana passada resolvi medir a performance do Kastavo de verdade, não só confiar na sensação de "parece rápido". Usei uma ferramenta de scan de performance que encontrei por aí, e o resultado inicial foi pior do que eu esperava: nota 44, numa escala de 0 a 100. LCP (tempo até o maior elemento visível aparecer) de 7,2 segundos, TBT (tempo de bloqueio total) de 3,6 segundos — os dois na faixa "ruim".

Comecei a investigar com calma, uma causa de cada vez.

Achado 1: toda página carregava tudo

O primeiro problema era estrutural: a Home — e, na verdade, qualquer página do site — estava carregando as bibliotecas de todas as 100+ ferramentas, não só da que a pessoa estava usando. Isso significava baixar código de processamento de PDF, vídeo e OCR mesmo pra quem só queria usar o contador de palavras.

A correção foi separar o catálogo de ferramentas (metadados, leve) do carregamento de cada ferramenta em si (pesado, só quando necessário). O resultado: a Home caiu de 2,3 MB de JavaScript pra menos de 900 KB.

Achado 2: um redirecionamento escondido

O segundo problema era mais sutil: toda visita à raiz do site (kastavo.com/) passava por um redirecionamento pro idioma certo (/en, /pt ou /es), e esse passo extra custava mais de meio segundo nas medições simuladas. A correção foi fazer a raiz já responder com o conteúdo, sem o salto, pra quem usa o idioma padrão (inglês). Quem prefere português ou espanhol continua sendo levado pra versão certa, com o idioma detectado do mesmo jeito de antes.

Achado 3: o aviso de cookies era o "maior elemento" da tela

Esse foi o mais inesperado. A métrica mais importante de performance (LCP) estava sendo "travada" pelo aviso de cookies, que só desenhava depois que o JavaScript terminava de carregar. A solução foi fazer esse aviso já vir pronto no HTML desde o primeiro momento, sem esperar nada.

O plot twist: os números variavam dependendo de onde eu media

Depois dessas correções, rodei o teste de novo esperando ver tudo resolvido — e o resultado continuava estranho: às vezes 65, às vezes 68, sem bater com o que eu media no meu próprio navegador. Rodei de novo várias vezes e percebi que os números simplesmente não eram consistentes entre si.

Decidi parar de confiar nesse número isolado e ir cruzar com uma fonte de referência: o PageSpeed Insights, do próprio Google. Ele usa o mesmo motor de medição que roda no navegador (o Lighthouse), mas nos servidores do Google, e ainda mostra dados de usuários reais quando o site tem tráfego suficiente (o Kastavo ainda não tem, e o painel mostra "No Data").

Resultado do PageSpeed Insights para a Home do Kastavo no celular: 98 em performance e 100 em acessibilidade, boas práticas e SEO
Resultado do PageSpeed Insights para a Home do Kastavo no celular: 98 em performance e 100 nas outras três categorias.

O resultado foi bem diferente: 98 de performance, 100 em acessibilidade, boas práticas e SEO; LCP de 2,3 segundos e TBT de 80 milissegundos. Era exatamente o que as correções deveriam ter entregado — só que a primeira ferramenta que usei pra medir, por algum motivo, não estava refletindo isso de forma confiável.

A lição que fica

Isso me ensinou algo que vale além de performance: uma ferramenta de medição não é neutra — cada uma simula condições diferentes (tipo de conexão, velocidade de processador, localização do servidor de teste), e um número isolado pode enganar. Quando o resultado não bate com o que você observa na prática, vale a pena cruzar com mais de uma fonte antes de assumir que o problema é seu.

Hoje o Kastavo carrega rápido de verdade, não só "parece" rápido — e agora eu confio nisso porque medi do jeito certo, não só uma vez.

Perguntas frequentes

O que é LCP, TBT e score de performance?

O LCP (Largest Contentful Paint) é o tempo até o maior elemento visível da tela aparecer, como uma imagem grande ou um bloco de texto; até 2,5 segundos é considerado bom, e acima de 4 segundos, ruim. O TBT (Total Blocking Time) soma os períodos em que a página ficou travada, sem responder ao usuário, enquanto carregava; é uma métrica de laboratório, e até 200 milissegundos é bom. O score de performance é a nota de 0 a 100 do Lighthouse, que combina várias métricas com pesos diferentes: de 90 a 100 é verde, de 50 a 89 é laranja e abaixo de 50 é vermelho.

Por que ferramentas diferentes de teste dão notas diferentes pro mesmo site?

Porque cada uma mede em condições diferentes: velocidade da conexão simulada, potência do processador da máquina de teste, localização do servidor, versão da ferramenta e até o jeito de aplicar a lentidão simulada. Além disso, o mesmo teste repetido varia um pouco de uma execução pra outra. Por isso vale rodar mais de uma vez, comparar sempre na mesma ferramenta ao longo do tempo e cruzar com uma fonte de referência.

Performance de site realmente afeta posição no Google?

Em parte. O Google usa os Core Web Vitals (LCP, INP e CLS), medidos com usuários reais, como um dos sinais de ranking, mas é um sinal entre muitos, e a relevância do conteúdo pesa mais. A nota do Lighthouse em si não é um fator de ranking. Um site rápido com conteúdo fraco não vai subir só por isso, mas um site lento prejudica quem usa, e isso vale por si só.

Continue lendo

Este site utiliza cookies para melhorar sua experiência e analisar o tráfego. Ao continuar navegando, você concorda com nossa Política de Privacidade.