Velocidade de página é um problema de resposta direta
Em ofertas com tráfego pago, cada segundo de carregamento custa dinheiro. Os pontos que mais pesam em VSLs e landing pages, e como atacar cada um.
Por Pedro Craveiro · · 4 min de leitura
Em um site institucional, uma página lenta é um incômodo. Em uma oferta com tráfego pago, é prejuízo: você já pagou pelo clique, e cada segundo de espera aumenta a chance de o lead fechar a aba antes de ver a oferta.
Onde as páginas de resposta direta costumam pesar
Player de vídeo carregado cedo demais
O player da VSL costuma ser o item mais pesado da página. Carregar scripts, thumbnails e fontes do player antes do necessário atrasa o que o lead vê primeiro.
O que fazer: priorize a primeira dobra, use uma thumbnail leve como placeholder e carregue o player sem bloquear a renderização.
Imagens sem otimização
Imagens enormes exportadas direto do design são comuns em advertoriais e landing pages longas.
O que fazer: sirva formatos modernos (WebP/AVIF), tamanhos responsivos e lazy loading para tudo abaixo da dobra. No Next.js, o componente Image resolve boa parte disso.
Scripts de terceiros em excesso
Pixels, ferramentas de mapa de calor, chats e testes A/B se acumulam a cada campanha.
O que fazer: revise periodicamente o que ainda é usado, carregue o que não é crítico depois da interação e centralize tags.
Fontes e CSS bloqueantes
Várias famílias de fonte e CSS não utilizado atrasam a primeira pintura.
O que fazer: limite as fontes, faça self-hosting e gere apenas o CSS que a página usa.
Meça antes e depois
Lighthouse e Core Web Vitals ajudam a enxergar o problema, mas a métrica que importa é a da operação: taxa de play, retenção da VSL e conversão. Otimize, publique e compare.
Velocidade não é detalhe técnico. Em resposta direta, é parte da oferta.