Cada segundo a mais de carregamento custa conversão. Os dados são consistentes — e as causas quase sempre estão nos mesmos lugares.
- Onde o problema quase sempre está
- O que medir
- A conversa que raramente acontece
A relação entre velocidade de carregamento e taxa de conversão não é especulação. É dado. O Google publicou que a probabilidade de um usuário abandonar uma página aumenta 32% quando o tempo de carregamento passa de 1 para 3 segundos. Aos 5 segundos, o aumento é de 90%.
Isso significa que a maioria das otimizações de UX, copy e design têm seu impacto limitado por um número que aparece antes de qualquer interação: o tempo até o primeiro conteúdo visível.
Onde o problema quase sempre está
Em plataformas que auditamos, os culpados recorrentes são três.
Imagens não otimizadas. Uma imagem JPEG de 2MB servida sem redimensionamento ou compressão pode ser responsável por 40% do peso total da página. A conversão para WebP com dimensões corretas elimina esse custo sem perda visual perceptível.
JavaScript bloqueante. Scripts carregados no <head> sem defer ou async pausam a renderização completa da página até serem baixados e executados. Em conexões móveis lentas, isso é segundos perdidos antes de o usuário ver qualquer conteúdo.
Ausência de cache adequado. Recursos estáticos sem headers de cache corretos são baixados novamente a cada visita, mesmo que não tenham mudado. Uma configuração simples de Cache-Control com tempo longo para assets com hash no nome elimina esse custo nas visitas subsequentes.
O que medir
Core Web Vitals são o ponto de partida. LCP (Largest Contentful Paint) mede quando o maior elemento visível carregou. FID (First Input Delay) mede quanto tempo leva até a página responder ao primeiro clique. CLS (Cumulative Layout Shift) mede a estabilidade visual durante o carregamento.
Os três impactam diretamente o ranking em buscas e a experiência percebida pelo usuário. Qualquer projeto que entregamos inclui auditoria dos três antes do deploy.
A conversa que raramente acontece
Performance raramente está no briefing inicial. O cliente pede design, funcionalidades e prazo. Velocidade aparece como preocupação só depois que o site está no ar e o Google Analytics mostra bounce rate acima do esperado.
Esse ciclo tem custo. Otimizar uma plataforma depois de construída é mais caro do que construir com performance como requisito desde o início. Decisões de arquitetura tomadas no começo — como qual framework usar, como servir imagens, como estruturar o carregamento de scripts — têm impacto que não é trivial reverter depois.
