Velocidade de site: por que cada segundo custa conversões

Segundo o Think with Google, a chance de abandono da página sobe 32% quando o tempo de carregamento passa de 1 para 3 segundos. Em 5 segundos, esse número passa de 90%. Esse dado reflete o comportamento real de quem chega no seu site pelo Google, por um anúncio ou por um link compartilhado. A decisão de ficar ou sair acontece em menos de cinco segundos, antes mesmo de o visitante ler qualquer palavra da sua oferta.

O problema é que velocidade de site costuma ser tratada como item de checklist técnico, responsabilidade do desenvolvedor, não como decisão que afeta faturamento. Na prática funciona ao contrário: performance ruim reduz conversão, aumenta o custo de aquisição de cliente e ainda derruba posição no Google, porque velocidade é fator direto de ranqueamento desde que o Core Web Vitals entrou no algoritmo.

Este post mostra o que realmente causa lentidão em sites de pequenas e médias empresas, como medir isso com precisão (não com achismo de que o site parece rápido) e qual plano de ação prioriza o que traz mais resultado com menos esforço técnico.

O custo real de cada segundo de carregamento

Cada segundo de atraso reduz conversão porque muda o comportamento de quem está decidindo se confia no seu negócio. Um site lento passa a mesma mensagem de uma loja física com fila enorme e atendente devagar: o cliente pode até querer comprar, mas o atrito supera a vontade.

Esse custo aparece em três lugares ao mesmo tempo:

• Taxa de conversão menor no mesmo volume de tráfego, com mais visitante saindo antes de ver a oferta
• Custo de aquisição mais alto, porque campanhas pagas jogam tráfego pra uma página que converte pior
• Ranqueamento orgânico pior, porque o Google usa performance como sinal direto de qualidade de experiência

Sinais de que a lentidão já está custando dinheiro no seu negócio:

• Taxa de rejeição acima de 60% em páginas de entrada vindas do Google
• Tempo médio na página menor que 30 segundos em conteúdo que exige leitura
• Queda de posição no Google mesmo com conteúdo e backlinks estáveis
• Reclamação recorrente de cliente sobre o site travar no celular

Se dois ou mais desses sinais aparecem no seu relatório de GA4 ou no Search Console, a causa provável está na performance, não no conteúdo da página.

Por que seu site está lento

Lentidão quase nunca tem uma causa única. É acúmulo de decisões técnicas tomadas sem medir impacto em performance. As quatro causas mais comuns aparecem em praticamente todo diagnóstico que fazemos.

Imagens sem otimização

Imagem é o maior vilão de performance em site de pequena e média empresa. Foto de celular direto no CMS, sem compressão, sem redimensionamento, sem formato moderno como WebP ou AVIF, facilmente passa de 3MB por imagem. Numa página com cinco fotos de produto ou uma galeria, isso sozinho já explica um LCP acima de 4 segundos.

Hospedagem e servidor mal dimensionados

Hospedagem compartilhada barata divide recurso de processamento com centenas de outros sites no mesmo servidor. Em horário de pico, o Time to First Byte dispara — o tempo que o servidor demora pra responder antes mesmo de começar a carregar qualquer conteúdo. Nenhuma otimização de frontend resolve um servidor lento na raiz. É comum ver empresa investindo em campanha paga e em conteúdo pra atrair tráfego, enquanto o servidor que recebe esse tráfego custa uma fração do orçamento de marketing mensal.

Scripts de terceiros e código inchado

Pixel do Facebook, chat, pop-up de newsletter, três plugins de SEO diferentes, tag manager mal configurado. Cada script de terceiro adiciona uma requisição, um tempo de execução de JavaScript e, com frequência, bloqueia a renderização da página enquanto carrega. Sites construídos em builders genéricos ou em WordPress com plugin em cima de plugin acumulam esse peso sem que ninguém perceba, porque cada adição isolada parece pequena.

Fontes e recursos que bloqueiam a renderização

Fonte customizada carregada do jeito errado, sem a propriedade font-display: swap, faz o navegador esconder o texto até o arquivo da fonte chegar. CSS e JavaScript carregados de forma bloqueante atrasam o primeiro pixel útil na tela, mesmo que o resto da página já esteja pronto.

Como medir a velocidade do seu site sem achismo

A sensação de que o site parece rápido não é diagnóstico. Performance se mede com ferramenta, com número, comparando antes e depois. O processo correto segue esta ordem:

1. Rode o PageSpeed Insights do Google na URL real da sua página mais importante, home ou página de conversão, não só numa home genérica
2. Anote os três números do Core Web Vitals (LCP, INP e CLS) separadamente para mobile e desktop, porque os resultados costumam ser bem diferentes
3. Cruze com os dados reais de usuário no relatório de Core Web Vitals do Google Search Console, que mostra o que acontece em produção, não em teste isolado
4. Use o GTmetrix ou o WebPageTest pra ver o waterfall de carregamento e identificar qual recurso específico está travando: imagem, script, fonte ou servidor
5. Repita a medição depois de cada mudança, uma de cada vez, pra saber exatamente o que teve impacto

Esse processo transforma performance de opinião em dado. E dado é o que justifica investir tempo e orçamento corrigindo o problema certo, não o que parece mais óbvio.

Core Web Vitals: as métricas que o Google realmente usa

O Google resume performance de experiência em três métricas, reunidas no que chama de Core Web Vitals. Entender o que cada uma mede evita otimizar a coisa errada.

Métrica	O que mede	Meta recomendada	Consequência se ultrapassar
LCP (Largest Contentful Paint)	Tempo até o maior elemento visível carregar	Até 2.5s	Usuário vê tela em branco ou incompleta por mais tempo
INP (Interaction to Next Paint)	Tempo de resposta a cliques e toques	Até 200ms	Site parece travado ou pesado ao interagir
CLS (Cumulative Layout Shift)	Quanto o layout se move enquanto carrega	Até 0.1	Usuário clica no lugar errado porque o conteúdo pulou

Essas três métricas fazem parte oficial dos sinais de ranqueamento do Google, documentado pelo próprio web.dev. Performance vira sinal técnico de SEO com peso mensurável no algoritmo, além de moldar diretamente a experiência de quem usa o site no dia a dia.

Plano de ação: o que resolver primeiro

Nem toda correção tem o mesmo retorno. Corrigir na ordem certa evita gastar semana de desenvolvimento num ajuste que move o ponteiro pouco. Esta é a ordem de prioridade que aplicamos em diagnóstico de performance:

1. Comprimir e redimensionar todas as imagens acima da dobra, convertendo para WebP ou AVIF — normalmente o ganho mais rápido e mais barato
2. Migrar para hospedagem adequada ao volume de tráfego real, ou hospedagem com CDN integrada, resolvendo o Time to First Byte na raiz
3. Auditar e remover scripts de terceiros que não geram retorno mensurável, como pixels duplicados, chats sem uso e plugins esquecidos
4. Configurar carregamento adiado (lazy load) para imagens e vídeos fora da primeira tela
5. Corrigir o carregamento de fontes com font-display: swap e pré-carregamento das fontes críticas
6. Revisar o código-base do site, já que builders genéricos e temas inchados frequentemente exigem reconstrução com stack mais enxuta

Os três primeiros itens resolvem a maior parte dos casos que atendemos. Os últimos três normalmente exigem decisão técnica mais profunda, incluindo repensar a stack por trás do site. Foi exatamente essa lógica que nos levou a reconstruir o próprio site da Korbi Studio em Astro, priorizando performance desde a escolha da tecnologia.

O impacto direto na conversão e no SEO

Performance não é métrica isolada de time técnico. Ela se conecta direto com dois números que o dono do negócio acompanha: quantos visitantes viram cliente e em que posição o site aparece no Google.

• Cada segundo a menos de carregamento historicamente aumenta conversão em faixas de dois dígitos em estudos de e-commerce e captação de lead, segundo dados consolidados pelo Think with Google
• Sites que passam no Core Web Vitals ganham vantagem competitiva de ranqueamento sobre concorrentes que empatam em conteúdo e backlinks, mas perdem em performance
• Anúncio pago direcionado pra landing page lenta paga mais caro pelo mesmo clique, porque o índice de qualidade da campanha cai junto com a experiência da página
• Performance ruim é uma das causas técnicas mais comuns quando um site simplesmente não aparece bem posicionado no Google mesmo com conteúdo relevante

Cada um desses pontos tem impacto direto em receita, não só em experiência. Ignorar performance é decidir, ainda que sem perceber, pagar mais caro por cliente e converter menos gente com o mesmo tráfego. Numa comparação simples, dois sites com o mesmo produto, o mesmo preço e o mesmo volume de visita, mas com performance diferente, terminam o mês com faturamento diferente.

Quando resolver sozinho e quando contratar ajuda especializada

Parte da correção de performance dá pra fazer internamente: compressão de imagem, revisão de plugins, ajuste de configuração de cache. Outra parte exige decisão estrutural que vai além de um ajuste pontual.

Contratar ajuda especializada faz sentido quando:

• O diagnóstico aponta problema na arquitetura do site, como tema pesado, builder genérico ou código legado, não em configuração isolada
• A correção pontual, como compressão, cache e CDN, já foi feita e o ganho de performance estagnou
• O site depende de plataforma que limita controle técnico sobre o que carrega e como carrega
• Trocar de stack técnica é uma opção real e o negócio já sente o custo da lentidão em conversão ou em posição orgânica

Nesses casos, o ganho de performance geralmente vem de reconstruir a base técnica do site com prioridade de velocidade desde a escolha da stack, não de mais um plugin de otimização em cima de uma fundação já comprometida.

Pare de discutir performance por impressão. Rode o PageSpeed Insights agora na página mais importante do seu site e anote os três números do Core Web Vitals. Esse é o ponto de partida real pra qualquer decisão sobre o que corrigir primeiro.

Se o diagnóstico apontar que o problema está na base técnica do site, não em ajuste pontual, vale conversar sobre reconstrução antes de continuar investindo em tráfego pago pra uma página que converte abaixo do potencial.