Meu site é lento: o que isso custa e o que resolve de verdade

Nota de ferramenta não é velocidade. O que conta é o que o visitante sente no celular dele, e três medidas dizem isso melhor que qualquer pontuação.

Avaliar meu site
75%
dos acessos precisam passar
3
medidas que importam
medir no celular real
2,5s
alvo de carregamento

Antes de contratar otimização: a nota que as ferramentas mostram não é o que o Google usa para ranquear. Ele usa o comportamento real dos seus visitantes, coletado dos navegadores deles. Um site pode ter nota baixa no teste e dados reais bons, e o contrário também acontece. Perseguir a nota é o erro mais caro dessa área.

Teste de laboratório e dado de campo: a distinção que muda tudo

Existem dois tipos de medição de velocidade e eles respondem perguntas diferentes.

Laboratório

Uma máquina simula um celular numa rede lenta e carrega sua página uma vez. É reproduzível, roda em segundos e serve para depurar: mostra o que está pesado e por quê. Mas é uma simulação, e uma só.

Campo

São medições coletadas de visitantes reais, no aparelho e na conexão deles, ao longo de 28 dias. É o que o Google considera, e é a única leitura que representa a experiência de quem realmente acessa seu site.

A diferença aparece de forma prática. Se seus visitantes estão majoritariamente em celular com conexão instável, o dado de campo será pior que o laboratório. Se estão em desktop com boa internet, será melhor. A nota simulada não sabe quem é seu público.

O dado de campo está no relatório de Core Web Vitals do Search Console e também aparece no topo do PageSpeed Insights quando há visitas suficientes. Se aparecer a mensagem de que não há dados suficientes, seu site tem pouco tráfego para a coleta — e aí o laboratório é o que você tem.

As três medidas que importam

O Google reduziu velocidade a três números. Cada um mede uma frustração diferente do visitante.

01
LCP — quanto tempo até aparecer o conteúdo principal
Largest Contentful Paint
Bom até 2,5sRuim acima de 4s

Marca o instante em que o maior elemento visível — normalmente a imagem de topo ou o título principal — termina de aparecer. É a medida mais próxima da percepção humana de "o site abriu".

É também a que mais falha em sites brasileiros, e a causa quase sempre é a mesma: uma imagem grande no topo, sem compressão, carregando antes de tudo.

02
INP — quanto o site demora a responder ao toque
Interaction to Next Paint
Bom até 200msRuim acima de 500ms

Mede o atraso entre a pessoa tocar em algo e a tela reagir. É a sensação de site travado: você clica no menu e nada acontece por meio segundo.

A causa é quase sempre excesso de JavaScript, especialmente scripts de terceiros — chat, pixel, mapa de calor, ferramenta de teste. Cada um consome processamento do celular de quem visita.

03
CLS — quanto a página pula enquanto carrega
Cumulative Layout Shift
Bom até 0,1Ruim acima de 0,25

Você vai clicar num botão e ele se move porque uma imagem terminou de carregar acima. É a medida mais irritante para o usuário e, felizmente, a mais fácil de corrigir.

A causa dominante: imagens e anúncios sem largura e altura declaradas. O navegador não sabe quanto espaço reservar, então reserva zero e empurra tudo quando o arquivo chega.

A regra dos 75%: o Google não olha a média. Ele exige que pelo menos três quartos dos acessos fiquem dentro do limite bom. Uma média boa com um quarto de acessos horríveis não passa — e média é justamente o que esconde esse tipo de problema.

Quanto isso custa de verdade

Aqui vale honestidade, porque a área é cheia de exagero.

Como fator de ranqueamento

Velocidade é um sinal, mas é fraco comparado a relevância e autoridade. Uma página lenta com o melhor conteúdo sobre um assunto continua ranqueando acima de uma página rápida e vazia. Quem promete subir posição só com otimização de velocidade está vendendo o que não entrega.

Onde ela decide é no desempate: entre duas páginas equivalentes, a mais rápida leva vantagem. Em nichos competitivos, isso importa. Em nichos vazios, quase não.

Como fator de conversão

Aqui o efeito é real e maior. Cada segundo a mais derruba uma parte dos visitantes antes que eles vejam qualquer coisa — e essas pessoas não aparecem em nenhum relatório, porque saíram antes de o site registrar a visita.

É por isso que sites lentos parecem ter menos tráfego do que têm: o visitante existiu, a medição não o pegou. Se você desconfia disso, o sintoma clássico é diferença grande entre cliques no Search Console e sessões no Analytics.

Como custo de credibilidade

Este não tem métrica, mas pesa. Um site que demora transmite descuido antes de qualquer palavra ser lida. Para quem vende serviço de alto valor, isso conta.

Onde o tempo se perde

Em quase todo site que eu analiso, o peso está concentrado em quatro lugares, nesta ordem.

Imagens. Costumam ser a maior parte do peso da página. Foto de câmera ou banco de imagens sobe com vários megabytes e é exibida em poucas centenas de pixels. O navegador baixa o arquivo inteiro para depois encolher.
Scripts de terceiros. Chat, pixel de anúncio, mapa de calor, ferramenta de pop-up, player de vídeo. Cada um adiciona requisição e processamento. Sites com cinco ou seis dessas ferramentas gastam mais tempo executando código de fora do que carregando o próprio conteúdo.
CSS e JavaScript bloqueantes. Arquivo carregado no topo do documento impede a página de aparecer até terminar de baixar. Uma folha de estilo de framework completo, quando a página usa cinco por cento dela, custa segundos.
Servidor lento. Antes de qualquer arquivo, o servidor precisa responder. Hospedagem compartilhada barata, banco de dados sem otimização e ausência de cache podem consumir um segundo antes que o navegador receba a primeira letra.

As correções, em ordem de retorno

Nem toda otimização vale o esforço. Esta é a ordem que entrega mais resultado por hora de trabalho.

1. Comprimir e redimensionar imagens

É a correção de maior impacto e menor dificuldade. Reduza cada imagem para o tamanho em que ela realmente aparece e converta para um formato moderno como WebP. Uma foto de 3 MB vira algo entre 100 e 200 KB sem diferença visível.

Se você tem muitas imagens antigas, comece pelas páginas que recebem mais visita. Não precisa converter o site inteiro para sentir efeito.

2. Declarar largura e altura

Adicionar os atributos de dimensão em toda imagem resolve a maior parte dos problemas de layout pulando. É uma alteração de código simples, sem risco, e o efeito no CLS é imediato.

3. Adiar o que não é essencial

Imagens abaixo da primeira dobra devem carregar sob demanda, não junto com o resto. Scripts que não são necessários para a página aparecer devem ser marcados para executar depois. Isso normalmente melhora LCP e INP ao mesmo tempo.

4. Auditar os scripts de terceiros

Liste tudo que carrega de fora e pergunte, item por item: isso está sendo usado? Ferramentas instaladas para um teste, plugins de campanhas antigas, pixels de plataformas abandonadas. Remover o que não serve costuma render mais que otimizar o que fica.

5. Ativar cache e compressão no servidor

Compressão de texto e cabeçalhos de cache para arquivos estáticos são configuração, não desenvolvimento. Fazem o visitante recorrente carregar quase nada e reduzem o peso da primeira visita.

6. Reduzir CSS e JavaScript próprios

É a etapa mais trabalhosa e a de menor retorno relativo. Só vale depois das cinco anteriores, e normalmente exige desenvolvedor. Se alguém propõe começar por aqui, provavelmente a proposta está invertida.

O que não vale perseguir

A nota 100

Chegar de 60 para 90 muda a experiência. De 90 para 100 custa desproporcionalmente e não muda nada que o visitante perceba. É vaidade de relatório.

A nota de desktop

Se a maioria do seu tráfego é celular, a nota de desktop é decoração. Olhe a aba de dispositivos móveis, que costuma ser bem pior e é a que conta.

Trocar de plataforma por velocidade

Migrar site inteiro para ganhar meio segundo raramente compensa. O ganho costuma vir de imagem e script, e esses viajam junto na migração.

Plugin que promete resolver sozinho

Ajudam com cache e compressão, que é configuração. Não resolvem imagem pesada nem excesso de script — as duas maiores causas.

Traduzindo lentidão em dinheiro

"O site está lento" não move ninguém a agir. "O site está deixando R$ X na mesa por mês" move. Dá para estimar isso com números que você já tem, e o cálculo é honesto desde que você trate o resultado como ordem de grandeza, não como precisão.

O que você precisa

Visitas mensais nas páginas que estão fora do limite de LCP. O Search Console agrupa as URLs por conjunto e o Analytics dá o volume de cada uma.
Sua taxa de conversão atual nessas páginas — quantos dos visitantes viram contato.
O valor de um contato, que é a margem que um cliente deixa dividida pelo número de contatos necessários para fechar um.

A conta

Suponha 3.000 visitas por mês em páginas lentas, conversão de 1,5% e cada contato valendo R$ 300 de margem esperada. Isso dá 45 contatos e R$ 13.500 por mês.

Agora, o que muda com a correção. Não use promessas de multiplicar conversão — use uma faixa conservadora. Uma melhora de LCP que sai de quatro segundos para dois costuma recuperar uma parte dos visitantes que abandonavam antes de ver a página. Se isso levar a conversão de 1,5% para 1,8%, são 54 contatos e R$ 16.200. A diferença é de R$ 2.700 por mês, ou cerca de R$ 32 mil no ano.

Compare com o custo da correção. Comprimir imagens e declarar dimensões nas principais páginas costuma ser trabalho de alguns dias. Se o retorno anual estimado é dez ou vinte vezes o custo, a decisão se toma sozinha. Se for equivalente, a prioridade é outra.

Por que a estimativa conservadora é a certa: quem promete dobrar a conversão com velocidade está prometendo o que não controla. O ganho real depende de quanto do seu público estava desistindo por causa do tempo — e isso varia enormemente conforme a conexão e o aparelho de quem visita. Estimar por baixo e ser surpreendido para cima é melhor que o contrário, principalmente quando a conta serve para justificar investimento.

O sinal de que você está perdendo mais do que imagina

Existe um indício de que a lentidão está cobrando caro: diferença grande entre os cliques registrados no Search Console e as sessões registradas no Analytics para as mesmas páginas.

O Search Console conta o clique no resultado de busca. O Analytics só conta quando a página carrega o suficiente para o script disparar. Se muita gente clica e some antes disso, os dois números divergem — e a diferença é uma estimativa de quantas pessoas desistiram durante o carregamento.

Uma diferença de dez ou quinze por cento é normal, por causa de bloqueadores e de configuração. Acima de trinta por cento, vale investigar velocidade a sério.

Quando velocidade não é o seu problema

Vale dizer, porque muita gente investe aqui achando que vai destravar o resultado.

Se seu site carrega em torno de dois segundos no celular e mesmo assim você não gera contato, o problema é outro. Pode ser a origem do tráfego, a clareza da oferta ou o formulário — e nenhum deles melhora com otimização técnica.

Da mesma forma, se você não aparece nas buscas, velocidade não é a causa. Site rápido que ninguém encontra continua invisível. Aí a questão é de indexação, relevância e autoridade, e o caminho começa numa auditoria de SEO, não numa otimização de carregamento.

Velocidade é multiplicador, não motor. Ela melhora o que já funciona e não cria o que não existe.

Como medir do jeito certo

Abra o relatório de Core Web Vitals no Search Console. É o dado real dos seus visitantes, agrupado por conjunto de páginas semelhantes.
Olhe a aba de dispositivos móveis primeiro. É onde está a maioria do tráfego e onde os problemas aparecem.
Identifique qual das três medidas falha. Cada uma tem causa e correção diferentes; tratar as três juntas desperdiça esforço.
Rode o teste de laboratório nas páginas apontadas, para descobrir o que especificamente está pesando.
Teste no seu celular, em rede móvel. Fora do wi-fi da empresa. É a única forma de sentir o que o visitante sente.
Corrija e espere 28 dias. O dado de campo é uma janela móvel desse período. Recarregar o relatório no dia seguinte não mostra nada.

O erro de leitura mais comum: corrigir tudo, rodar o teste de laboratório, ver nota boa e concluir que resolveu. O laboratório reflete a correção na hora; o dado de campo leva quatro semanas para incorporar. Se você julgar pelo laboratório, vai achar que terminou antes de saber se funcionou.

Quando a lentidão é de servidor

Comprimir imagem, declarar dimensão e remover script abandonado não exige consultor. São as correções de maior retorno e cabem em quem cuida do site.

Vale trazer ajuda quando o dado de campo continua ruim depois disso, quando o problema está no servidor ou na estrutura do tema, ou quando a lentidão convive com outros sintomas — queda de posição, páginas não indexadas, conteúdo que não aparece. Nesses casos velocidade é sintoma de algo mais amplo, e tratá-la isolada não resolve. É o tipo de investigação que cabe em SEO técnico avançado, onde carregamento, rastreamento e renderização são olhados juntos. Se a dúvida for mais ampla sobre a qualidade do site, o roteiro está em não sei se meu site está bom ou ruim. E se as visitas não viram contato, o diagnóstico está em tenho visitas e não tenho leads.

Como diagnosticar e corrigir a lentidão de um site

  1. Abrir o relatório de Core Web Vitals No Search Console, que traz o dado real dos visitantes.
  2. Olhar a aba de dispositivos móveis primeiro É onde está a maioria do tráfego e onde os problemas aparecem.
  3. Identificar qual das três medidas falha LCP, INP e CLS têm causas e correções diferentes.
  4. Rodar o teste de laboratório nas páginas apontadas Para descobrir o que especificamente está pesando.
  5. Comparar cliques do Search Console com sessões do Analytics Diferença acima de 30% indica gente desistindo durante o carregamento.
  6. Testar no próprio celular, em rede móvel Fora do wi-fi da empresa, para sentir o que o visitante sente.
  7. Corrigir e esperar 28 dias O dado de campo é uma janela móvel desse período.
Cleber Barbosa, consultor de marketing digital em Ribeirão Preto
Autor
Cleber Barbosa
Consultor de Marketing Digital, SEO e Tráfego Pago — Ribeirão Preto, SP

Vinte anos de marketing digital e 43 cases documentados. Trabalho com SEO técnico, tráfego pago, growth hacking e IA aplicada a negócios. Começo sempre pelo dado de campo e não pela nota: a nota mede uma simulação, o campo mede o cliente do meu cliente.

Sobre o autor
Perguntas frequentes

Dúvidas sobre site lento

Qual nota do PageSpeed é aceitável?

A nota não é o critério. O que vale são as três medidas de campo dentro dos limites em pelo menos 75% dos acessos. Um site com nota 70 e dados de campo bons está melhor que um com nota 95 e campo ruim.

Site lento derruba minha posição no Google?

É um sinal, mas fraco perto de relevância e autoridade. Ele pesa no desempate entre páginas equivalentes. Se você caiu de posição, velocidade dificilmente é a causa principal.

Meu site abre rápido no meu computador. Ainda assim é lento?

Pode ser. Você está numa máquina boa, em rede boa, e provavelmente com o site em cache. Teste no celular, em rede móvel, com o navegador em janela anônima, e a impressão costuma mudar.

Trocar de hospedagem resolve?

Ajuda se o tempo de resposta do servidor for o gargalo, o que dá para verificar no teste. Mas na maioria dos casos o peso está em imagem e script, e esses continuam iguais em qualquer hospedagem.

Quanto tempo até ver o resultado da correção?

No teste de laboratório, imediatamente. No dado de campo, cerca de 28 dias, porque ele é uma janela móvel desse período. Julgar pelo laboratório dá falsa sensação de conclusão.

Vale remover o chat do site para ganhar velocidade?

Depende de quanto ele gera. Se traz contato de verdade, mantenha e configure para carregar depois do conteúdo. Se foi instalado e nunca usado, remover melhora INP sem custo nenhum.

Não sabe se a lentidão está custando resultado?

Leitura do dado de campo, identificação de qual medida falha e ordem de correção pelo retorno — com as suas páginas.

Falar no WhatsApp