Quanto a velocidade pesa de verdade — e o que encontramos auditando o nosso próprio site

Texto de agência sobre velocidade costuma ser sobre o site dos outros. Este é sobre o nosso. Em setembro de 2026 fizemos uma auditoria completa no presencadigital.co, e o que apareceu é razoavelmente constrangedor para quem vende otimização. Está tudo aqui porque um exemplo real vale mais que uma lista de boas práticas.

O que a auditoria encontrou

• 2.191 KB de imagem só na página inicial. Contra 11 KB de HTML, 11 KB de CSS e 8 KB de JavaScript. A página era, em 98% do peso, imagem.
• Um único PNG de 1.071 KB. Uma captura de tela com 1.887 pixels de largura, exibida num cartão de aproximadamente 400 pixels. Mais de um megabyte para mostrar uma miniatura.
• Nenhuma das 25 imagens tinha width e height. É o que provoca o pulo de layout enquanto a página carrega.
• Todos os arquivos eram servidos com no-cache. Cada visita rebaixava tudo de novo, inclusive quem estava só navegando entre páginas.
• O fundo do topo nunca carregava. O CSS crítico é embutido no HTML, e dentro dele havia um caminho relativo. Resultado: o navegador procurava a imagem num endereço que não existia. Em nenhuma página. Desde sempre.
• A classe .container era usada em mais de trinta elementos e não tinha uma linha de CSS. Era por isso que o logo encostava na borda no celular.

O que foi feito e quanto rendeu

A maior parte do ganho veio de uma coisa só: converter para WebP no tamanho real de exibição. A regra que usamos é simples — o arquivo tem, no máximo, o dobro da maior largura em que a imagem aparece na tela. O dobro cobre telas de alta densidade; qualquer coisa além disso é peso jogado fora.

Vale dizer o que não funcionou: reencodar sem reduzir a dimensão. Numa das imagens, o WebP no tamanho original ficou maior que o JPEG. Compressão não resolve imagem grande demais; só redimensionamento resolve.

Agora a parte impopular: velocidade não é o que dizem

Velocidade não é um fator de rankeamento decisivo isoladamente. Um site rápido com conteúdo ruim não passa na frente de um site lento com o melhor conteúdo sobre o assunto. Quem promete primeira posição por causa de nota de desempenho está vendendo a coisa errada.

O que a velocidade realmente faz é outra coisa, e é mais direta: ela decide quem fica. Numa página que demora, parte das pessoas volta antes de ver qualquer coisa — e essas pessoas não aparecem em relatório nenhum, porque nunca chegaram a ser uma visita. É perda invisível, e é por isso que ela é adiada com tanta facilidade.

A hierarquia honesta é: conteúdo certo primeiro, velocidade depois. Mas “depois” não é “nunca”, e as correções acima levaram menos de um dia de trabalho.

A ordem que dá mais resultado por hora de trabalho

1. Imagem. É quase sempre 80% ou mais do peso. Redimensionar e converter resolve a maior parte do problema.
2. Cache. Deixar o navegador reaproveitar CSS, JavaScript e imagem entre páginas é configuração de servidor, não de código.
3. Fonte. Cada família de fonte externa é uma conexão nova e um bloqueio de renderização. Em vários projetos nossos a decisão foi não usar nenhuma.
4. Script de terceiro. Rastreamento, chat, mapa. Adiar o carregamento para depois do primeiro desenho da página costuma render mais do que otimizar o próprio código.

Como medir sem ferramenta paga

O PageSpeed Insights do Google dá o diagnóstico geral. Para saber onde o tempo vai, o curl decompõe a resposta sem instalar nada:

curl -s -o /dev/null -w "dns=%{time_namelookup} tls=%{time_appconnect} servidor=%{time_starttransfer}\n" https://seusite.com.br/

E no navegador, a aba de rede do DevTools ordenada por tamanho responde em cinco segundos a pergunta que mais importa: qual é o arquivo mais pesado da página. Na nossa, era um PNG de um megabyte que ninguém tinha olhado desde 2023.