Um site que leva 5 segundos para abrir no celular perde a visita antes de mostrar preço. O prejuízo não aparece no relatório com esse nome: ele aparece como formulário vazio, carrinho não aberto e telefone que não toca. A velocidade de site virou critério de negócio porque o custo dela é silencioso e se repete todo mês.
A conta fica clara quando alguém mede. O estudo da Deloitte com 37 marcas e mais de 30 milhões de sessões mostrou que 0,1 segundo a menos no carregamento móvel elevou a conversão em 8,4% no varejo, 10,1% em viagens e 21,6% no envio de formulário em sites de geração de lead (estudo publicado no web.dev). Décimos de segundo, não segundos.
Este guia mostra como ler o diagnóstico de velocidade de site do jeito certo, o que corrigir primeiro e onde o ajuste caseiro para de funcionar.
Velocidade de site no vermelho: quanto isso custa por mês
Antes de mexer em qualquer plugin, faça a conta do seu caso: sessões móveis do mês, taxa de conversão atual e ticket médio. Uma queda de 8% na conversão em um site que gera 40 contatos por mês significa 36 contatos perdidos por ano.
Em operação de serviço com ticket de R$ 4 mil, isso é uma receita anual que some sem deixar rastro no painel. Por isso tratar velocidade de site como assunto técnico isolado é um erro de gestão: o número final está no caixa, não no relatório de performance.
Existe ainda o custo de aquisição, que a velocidade de site multiplica. Tráfego pago que cai em página lenta paga o clique e não converte, então você compra a mesma visita duas vezes.
Velocidade de site não é a nota, é o dado de campo
O erro mais comum ao medir velocidade de site é perseguir a nota de 0 a 100 do PageSpeed Insights. Essa nota vem de laboratório: uma simulação feita em um dispositivo padrão, em uma rede padrão, naquele instante. Serve para diagnóstico, não para decisão.
O que o Google usa no ranqueamento é o dado de campo, coletado de usuários reais do Chrome e agregado no Chrome UX Report. Só entram origens públicas com volume suficiente de visitantes para gerar amostra estatística, segundo a documentação oficial do CrUX.
Na prática, um site com nota 62 e dado de campo verde está melhor posicionado que outro com nota 91 e campo vermelho. A velocidade de site que conta é a que o seu cliente sente no celular dele, na operadora dele.
O Google é explícito: Core Web Vitals são usados pelos nossos sistemas de ranqueamento, mas não existe um sinal único, conforme a documentação do Google Search Central. Performance ruim atrapalha, boa performance sozinha não coloca ninguém em primeiro lugar.
Os três números que definem a velocidade de site hoje
A velocidade de site é medida por três indicadores, com limite oficial definido no percentil 75 dos carregamentos, separados entre celular e desktop.
- LCP (Largest Contentful Paint): tempo até o maior elemento visível aparecer. Bom até 2,5 segundos.
- INP (Interaction to Next Paint): tempo entre o clique e a resposta visual da página. Bom até 200 milissegundos.
- CLS (Cumulative Layout Shift): quanto o layout se mexe sozinho durante o carregamento. Bom até 0,1.
Esses limites estão publicados na referência de Web Vitals do web.dev. O INP substituiu o antigo FID em 2024, então material anterior a essa data mede uma coisa que não existe mais.
O dado de mercado calibra a expectativa. Em 2025, 48% dos sites passaram nos três indicadores no celular e 56% no desktop, segundo o Web Almanac do HTTP Archive. Metade da web está no vermelho, e sair dessa metade já é vantagem competitiva concreta.
Checklist de diagnóstico em 20 minutos
Você consegue medir a velocidade de site sozinho, sem contratar ninguém. Siga na ordem.
- Rode a home, uma página de serviço e uma de conteúdo no PageSpeed Insights, sempre nas duas abas.
- Ignore a nota e olhe o bloco de dados de campo no topo. Se ele não aparecer, falta tráfego para o CrUX e a decisão sai só do laboratório.
- Anote qual das três métricas está fora do limite. Na maioria dos casos brasileiros é o LCP no celular.
- No relatório de laboratório, procure o item que identifica o elemento de LCP. Quase sempre é uma imagem grande no topo.
- Verifique o TTFB (tempo de resposta do servidor). Acima de 800 ms, o problema é hospedagem ou banco, não imagem.
- Abra a mesma página no seu celular em 4G real, sem cache. É a medição que ninguém discute em reunião.
Com esse checklist você já sabe onde a velocidade de site quebra: infraestrutura, mídia ou código. São três caminhos diferentes, e confundir os três é o motivo de tanta gente pagar por otimização que não muda o número.
LCP: o ponto onde a maioria dos sites perde
Imagem é o elemento de LCP em 76% das páginas no celular e em 85,3% no desktop, de acordo com o mesmo levantamento do HTTP Archive. Na maior parte dos casos, resolver a imagem do topo resolve metade do problema de velocidade de site.
Três erros aparecem com frequência quase cômica. O primeiro é JPG pesado sem conversão para WebP ou AVIF: o JPG ainda responde por 57% das imagens de LCP e o WebP por apenas 11%. O segundo é servir a imagem de outro domínio, o que adiciona uma nova conexão antes do primeiro byte, situação presente em 44% a 51% das páginas.
O terceiro é o mais irônico: entre 16% e 17% das páginas aplicam lazy loading na imagem principal do topo, adiando justamente o elemento que deveria carregar primeiro. Alguém marcou tudo no plugin de otimização e piorou o número que queria melhorar.
A correção segue esta ordem: comprimir e converter formato, dimensionar a imagem para o tamanho real de exibição, remover lazy loading do elemento de topo, servir do mesmo domínio e só então pensar em CDN. Se o TTFB continuar alto depois disso, o gargalo é o servidor e você precisa revisar a escolha de hospedagem.
INP: quando o clique responde tarde
INP mede o intervalo entre a interação e a resposta visual. É a parte da velocidade de site que expõe excesso de JavaScript. No celular, 77% dos sites passam. No desktop, 97%. A diferença de 20 pontos revela o problema: processador de celular popular executando script pensado para notebook.
As causas mais comuns são scripts de terceiros acumulados ao longo dos anos: pixel de rede social que ninguém usa, mapa de calor esquecido ativo, chat pesado carregado antes do primeiro clique.
Faça auditoria de scripts a cada trimestre e remova o que não tem dono. Cada tag precisa de uma pessoa que responda por ela e de um motivo comercial. Esse é o mesmo raciocínio aplicado aos erros de UX que derrubam venda: acúmulo silencioso vira custo.
CLS: o layout que pula e derruba a confiança
CLS é o único indicador em que o desktop vai pior que o celular: 72% contra 81%. O motivo costuma ser banner, anúncio ou aviso de cookie que entra depois e empurra o conteúdo para baixo.
A correção é estrutural e barata. Declare largura e altura em toda imagem e iframe, carregue fonte com font-display: swap e reserve o espaço do aviso de cookie antes de ele aparecer.
Layout que pula gera clique errado, e clique errado gera desistência. É item de confiança, não só um número de velocidade de site.
Quando o diagnóstico aponta infraestrutura
Compressão de imagem e limpeza de script resolvem boa parte dos problemas de velocidade de site, e essa etapa a equipe de dentro executa. Para entender o retorno financeiro antes de investir, o material sobre Core Web Vitals e receita traz a lógica completa.
Se o TTFB segue acima de 800 ms com cache ativo, se o tema carrega uma dúzia de plugins para renderizar uma página ou se cada atualização derruba um ajuste anterior, o problema deixou de ser otimização e virou arquitetura. O Growtor Store nasce dessa premissa: performance definida no projeto, não remendada depois.
Onde o ajuste manual de velocidade de site para de funcionar
Existe um teto claro em qualquer projeto de velocidade de site. Cache mascara sintoma de servidor lento, mas não muda a resposta do banco. Tema comercial pesado carrega bibliotecas que a sua página não usa, e otimizar por cima de construtor visual é enxugar gelo.
Os sinais de teto são objetivos: a nota melhora e o dado de campo não, cada atualização de plugin reintroduz o problema, e ninguém consegue dizer qual mudança causou qual efeito.
Nesse ponto, insistir em ajuste manual custa mais caro que refazer a base. A velocidade de site deixa de ser tarefa de manutenção e vira decisão de projeto, com impacto direto no custo anual de manutenção que você já paga.
O que fazer nesta semana
Roteiro para melhorar a velocidade de site, em ordem de esforço crescente.
- Hoje: rode o PageSpeed em três páginas, anote o dado de campo e identifique a métrica fora do limite.
- Esta semana: converta as imagens do topo para WebP, remova lazy loading do elemento de LCP e declare dimensões em toda imagem.
- Próximos 15 dias: liste todos os scripts de terceiros, elimine os sem dono e meça de novo.
- Depois de 28 dias: volte ao dado de campo, porque o CrUX trabalha com janela móvel e o efeito real leva semanas para aparecer.
- Se o número não mudar: o gargalo é servidor, tema ou arquitetura, e a decisão passa a ser de projeto.
Quem trata velocidade de site como rotina mantém o ganho. Quem trata como mutirão anual volta ao vermelho no trimestre seguinte. Vale o mesmo princípio de quem trabalha ranqueamento do zero: constância vence pico de esforço.
Já rodou o diagnóstico e quer leitura técnica do que trava o seu caso? Fale com a Growtor pelo WhatsApp e traga o print do seu dado de campo. A conversa começa pelo número, não pela proposta.
Perguntas frequentes sobre velocidade de site
Qual nota de PageSpeed indica boa velocidade de site?
Acima de 90 é desejável, mas a nota não decide sozinha. O que pesa no ranqueamento é o dado de campo verde nas três métricas: LCP até 2,5 segundos, INP até 200 milissegundos e CLS até 0,1, no percentil 75.
Quanto tempo leva para a melhoria aparecer no Google?
O dado de campo do CrUX usa janela móvel, então mudanças feitas hoje só aparecem consolidadas depois de cerca de quatro semanas. Testes de laboratório mostram o efeito na hora, o que confunde bastante gente.
Plugin de cache resolve o problema de velocidade de site?
Resolve parte. Cache acelera páginas repetidas, mas não corrige imagem pesada, excesso de script nem servidor subdimensionado. Se o TTFB continua alto com cache ativo, o gargalo está na infraestrutura.
Site rápido garante primeira posição no Google?
Não. O próprio Google afirma que não existe sinal único e que boa pontuação não garante topo de resultado. Velocidade de site ruim tira oportunidade, boa performance apenas remove um obstáculo. Conteúdo e relevância continuam decidindo.
Vale a pena refazer o site só por causa da velocidade de site?
Vale quando o teto técnico já foi atingido: dado de campo travado no vermelho, cada atualização quebrando ajustes anteriores e nota que sobe sem efeito real. Nesses casos, o custo de manter supera o de refazer com base correta.
