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 no briefing
- A posição da VM2
A relação entre velocidade de carregamento e taxa de conversão não é especulação. É dado. Em pesquisa de 2017 conduzida pela Google em parceria com a SOASTA, a probabilidade de um usuário abandonar uma página aumentou 32% quando o tempo de carregamento passou de 1 para 3 segundos. Aos 5 segundos, o aumento foi de 90%. Aos 10 segundos, 123%.
Um segundo estudo, conduzido pela Deloitte com Google em 2019 (“Milliseconds Make Millions”), mostrou o outro lado da mesma relação: melhorias de apenas 0,1 segundo no tempo de carregamento aumentaram a conversão em e-commerce em 8,4% e o ticket médio em 9,2%.
A consequência prática é que a maioria das otimizações de UX, copy e design tem 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 a gente audita, os culpados recorrentes são três.
Imagens não otimizadas. Segundo o HTTP Archive Web Almanac 2025, imagens representam 36 a 37% do peso total de uma página típica. Uma JPEG de 2MB servida sem redimensionamento ou compressão pode facilmente sozinha responder por boa parte desse total. A conversão para formatos modernos como WebP ou AVIF, com dimensões corretas para o contexto de exibição, 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 vira segundos perdidos antes de o usuário ver qualquer conteúdo. JavaScript é, segundo o mesmo Web Almanac, o segundo maior contribuinte para o peso da página, com média de 690 KB no mobile, boa parte frequentemente não utilizado.
Ausência de cache adequado. Recursos estáticos sem headers de cache corretos são baixados de novo 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. Os três indicadores definidos pela Google em 2020 passaram por uma atualização importante em 12 de março de 2024, quando o Interaction to Next Paint (INP) substituiu o First Input Delay (FID). A combinação atual é:
- LCP (Largest Contentful Paint): mede quando o maior elemento visível terminou de carregar. Bom: abaixo de 2,5 segundos.
- INP (Interaction to Next Paint): mede a responsividade da página a interações do usuário durante toda a visita, não só na primeira. Bom: abaixo de 200 milissegundos.
- CLS (Cumulative Layout Shift): mede a estabilidade visual durante o carregamento. Bom: abaixo de 0,1.
INP é métrica mais rigorosa que o FID que substituiu, porque considera todas as interações do usuário, não apenas a primeira. Sites que passavam bem em FID podem falhar em INP, especialmente os que dependem de muito JavaScript de terceiros ou de handlers de evento pesados.
Os três impactam diretamente o ranking em buscas e a experiência percebida pelo usuário. Qualquer projeto que a gente entrega inclui auditoria dos três antes do deploy.
A conversa que raramente acontece no briefing
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.
A posição da VM2
Em projetos da VM2, performance entra no briefing antes do design. Isso significa decidir cedo qual stack tecnológica suporta os tempos de carregamento esperados, como as imagens vão ser servidas (CDN, formatos modernos, dimensões responsivas), e qual estratégia de carregamento de JavaScript faz sentido pra cada caso.
A gente não tenta acertar tudo no primeiro deploy. O que a gente garante é que cada decisão tomada na arquitetura inicial deixa espaço pra otimização contínua, em vez de criar dívida que vai ser cara de pagar depois. Performance é menos sobre velocidade absoluta e mais sobre não criar gargalos arquiteturais que limitam o futuro.
Fontes consultadas: Google/SOASTA Research (2017), “Mobile Page Speed New Industry Benchmarks”; Deloitte com Google (2019), “Milliseconds Make Millions”; HTTP Archive, Web Almanac 2025 (Page Weight); web.dev, “Interaction to Next Paint becomes a Core Web Vital on March 12” (2024).
