Velocidade do site: por que 3 segundos a mais custa clientes

Você investe em tráfego, refina o posicionamento, melhora o copy. E mesmo assim a conversão não sobe. Pode ser que o problema aconteça antes de qualquer coisa ser lida: o site demora para carregar e o visitante desiste.

Estudos do Google indicam que quando o tempo de carregamento passa de 1 para 3 segundos, a probabilidade de abandono aumenta em 32%. De 1 para 5 segundos, sobe para 90%. Não é exagero dizer que cada segundo conta.

O problema é que “velocidade” virou um tema técnico demais. Relatórios cheios de siglas, scores em vermelho, recomendações que parecem exigir um time de engenharia. Este artigo traduz isso em linguagem de negócio: o que medir, como interpretar e o que pedir para alguém corrigir.

O que velocidade significa para o visitante

Quando falamos de velocidade, não estamos falando só de “o site abriu”. Estamos falando de percepção. O visitante quer ver conteúdo útil rápido, quer conseguir interagir sem travamentos, quer que a página não “pule” enquanto carrega.

É por isso que o Google criou os Core Web Vitals: três métricas que tentam medir a experiência real do usuário.

LCP (Largest Contentful Paint): quanto tempo até o maior elemento visível da página aparecer. Pode ser uma imagem de destaque, um bloco de texto principal, um banner. Se isso demora, o visitante fica olhando para uma tela vazia ou incompleta.

INP (Interaction to Next Paint): quanto tempo o site leva para responder quando o visitante clica em algo. Se ele clica num botão e nada acontece por 300 milissegundos, parece quebrado.

CLS (Cumulative Layout Shift): quanto a página “pula” durante o carregamento. Sabe quando você vai clicar em um botão e um banner carrega em cima, fazendo você clicar em outra coisa? Isso é CLS alto.

Por que isso afeta conversão diretamente

A relação entre velocidade e conversão não é abstrata. É mecânica.

Quando a página demora, o visitante abandona antes de ver sua proposta de valor. Quando a página trava ao interagir, ele não consegue clicar no CTA. Quando a página pula, ele clica no lugar errado e se frustra.

Dados da Portent mostram que páginas que carregam em 1 segundo têm taxa de conversão 3x maior do que páginas que carregam em 5 segundos. O Walmart reportou que cada segundo de melhoria no tempo de carregamento aumentou conversões em 2%.

Não é só sobre “experiência do usuário” no sentido abstrato. É sobre quantas pessoas conseguem completar a ação que você quer que elas completem.

Site lento

• Visitante desiste antes de ver o conteúdo
• Clique no CTA não responde de imediato
• Página pula e causa cliques errados
• Usuário associa lentidão a falta de confiança

Site rápido

• Visitante vê a proposta de valor em segundos
• Interação fluida, sem travamentos
• Página estável, comportamento previsível
• Percepção de profissionalismo e solidez

Como testar velocidade sem depender de ninguém

Você não precisa ser técnico para fazer um diagnóstico inicial. Duas ferramentas gratuitas resolvem a maior parte:

PageSpeed Insights (pagespeed.web.dev): ferramenta do Google. Cole a URL, espere o relatório. Ele mostra os Core Web Vitals com dados de campo (usuários reais) e dados de laboratório (simulação). Priorize os dados de campo quando disponíveis.

GTmetrix (gtmetrix.com): alternativa útil que mostra cascata de carregamento. Ajuda a identificar qual recurso específico está atrasando tudo.

Ao rodar o teste, foque nestes números:

• LCP abaixo de 2.5 segundos é considerado bom. Acima de 4 segundos é problemático.
• INP abaixo de 200 milissegundos é bom. Acima de 500 precisa de atenção.
• CLS abaixo de 0.1 é bom. Acima de 0.25 está causando frustração.

• Rodou PageSpeed Insights na página principal?
• Rodou nas páginas de produto ou serviço mais importantes?
• Rodou nas landing pages de campanha?
• Comparou versão mobile e desktop?
• Anotou os três Core Web Vitals de cada página?

Como ler o relatório sem se perder

O relatório do PageSpeed Insights pode parecer assustador. Muitas siglas, muitos itens em vermelho. Não entre em pânico.

Primeiro, olhe para o score geral. Ele vai de 0 a 100. Acima de 90 é excelente. Entre 50 e 89 precisa de atenção. Abaixo de 50 é urgente.

Depois, olhe para os Core Web Vitals em “dados de campo” se disponíveis. Esses são dados reais de usuários acessando seu site. Se não houver dados de campo suficientes, o relatório mostra dados de laboratório (simulação controlada). Dados de campo são mais confiáveis para diagnóstico.

Por fim, desça até “Oportunidades” e “Diagnósticos”. Essas seções listam o que pode ser melhorado, com estimativa de impacto em segundos. Não tente resolver tudo. Foque no que aparece primeiro.

O que pedir para o desenvolvedor corrigir

Identificou problemas no relatório. Agora precisa falar com alguém técnico. Aqui está uma tradução das recomendações mais comuns:

“Eliminar recursos que bloqueiam a renderização” O que significa: arquivos CSS e JavaScript estão sendo carregados de um jeito que trava a exibição do conteúdo. O que pedir: “Precisamos revisar como CSS e JS estão sendo carregados. Pode verificar se dá para adiar scripts não essenciais e separar o CSS crítico?”

“Reduzir o tempo de resposta do servidor (TTFB)” O que significa: o servidor demora para começar a responder. Pode ser hospedagem fraca, banco de dados lento ou falta de cache. O que pedir: “O tempo de resposta do servidor está alto. Pode verificar se temos cache configurado e se a hospedagem está adequada para o tráfego atual?”

“Servir imagens em formatos de última geração” O que significa: as imagens estão em JPEG ou PNG quando poderiam estar em WebP ou AVIF, que são menores. O que pedir: “Precisamos converter as imagens para WebP. Pode implementar isso na build ou usar um CDN que faça automaticamente?”

“Adiar imagens fora da tela” O que significa: imagens que só aparecem quando o usuário rola a página estão sendo carregadas junto com todo o resto. O que pedir: “Pode implementar lazy loading nas imagens que não aparecem de cara na tela?”

“Evitar mudanças de layout grandes” O que significa: elementos estão sendo inseridos na página sem espaço reservado, fazendo tudo pular. O que pedir: “Temos CLS alto. Pode verificar se as imagens e iframes têm dimensões definidas no HTML? E se os anúncios ou banners têm espaço reservado?”

“Reduzir JavaScript não utilizado” O que significa: tem código JavaScript sendo carregado que nem está sendo usado na página. O que pedir: “Pode fazer uma auditoria do JavaScript para remover código morto ou adiar o que não é essencial para o carregamento inicial?”

Priorizando correções pelo impacto

Nem todo item vermelho no relatório merece a mesma urgência. A regra prática é: comece pelo que afeta mais gente por mais tempo.

Prioridade alta: problemas que afetam LCP ou que aparecem em páginas de alto tráfego e conversão (home, páginas de produto, landing pages).

Prioridade média: problemas de CLS e INP que estão causando frustração visível. Página pulando, cliques que não respondem.

Prioridade baixa: otimizações incrementais em páginas de menor tráfego ou problemas que afetam marginalmente o score.

Uma forma prática de priorizar: multiplique o tráfego da página pelo tamanho do problema. Uma melhoria de 0.5 segundos na home que recebe 10 mil visitas mensais vale mais do que 2 segundos de melhoria numa página que recebe 100.

O erro de delegar sem acompanhar

Você pode passar essa lista para o desenvolvedor e achar que o trabalho acabou. Não acabou.

Performance não é um problema que se resolve uma vez. Cada novo banner, cada plugin adicionado, cada imagem que alguém sobe sem otimizar pode degradar o que foi corrigido.

Depois das correções iniciais, estabeleça uma rotina mínima: rode o PageSpeed Insights uma vez por mês nas páginas principais. Se os números piorarem, investigue o que mudou.

Ferramentas como o Google Search Console também mostram relatório de Core Web Vitals agregado. Se você usa, olhe periodicamente para ver se há tendência de piora.

Traduzindo para quem aprova orçamento

Se você precisa convencer alguém a investir em performance, a conversa não pode ser técnica. Tem que ser sobre dinheiro.

“A cada segundo de atraso no carregamento, perdemos X% de conversão. Com o tráfego atual, isso representa Y leads ou vendas por mês.”

Faça a conta de trás para frente. Qual é o valor de um lead ou venda? Quantas visitas você tem? Qual é a taxa de conversão atual? Se você reduzir o tempo de carregamento de 5 para 2 segundos e a conversão subir 20% (estimativa conservadora baseada em dados de mercado), quanto isso vale em reais por mês?

Esse tipo de argumento move aprovação. “O score do PageSpeed está vermelho” não move.

Conclusão

Velocidade do site não é detalhe técnico. É infraestrutura de conversão. Quando o site demora, você perde visitantes antes de ter chance de convencê-los.

As ferramentas para diagnosticar são gratuitas. As métricas que importam são três. As conversas com desenvolvedores podem ser traduzidas. O que falta, na maioria das vezes, é tratar performance como prioridade de negócio, não como pendência de TI.

Se você não sabe como está a velocidade das suas páginas principais, esse é o primeiro passo. Rode o teste. Anote os números. Depois decida o que fazer com eles.