Site lento perde venda de um jeito silencioso. Ninguém reclama: a pessoa simplesmente volta para o resultado de busca, fecha a aba ou desiste no meio do checkout. O relatório de mídia mostra o clique pago, mas não mostra quem foi embora antes de a página aparecer.
Este guia é para quem precisa decidir o que corrigir no site, com qual prioridade e como saber se deu certo. Ele serve para quem cuida do site e para quem contrata quem cuida. Os capítulos técnicos explicam o suficiente para você conversar com o desenvolvedor e cobrar o resultado certo.
Capítulo 1O que são os Core Web Vitals
São três medidas que o Google usa para avaliar a experiência de quem visita uma página. Cada uma responde a uma pergunta simples:
| Métrica | Pergunta | Bom | Precisa melhorar | Ruim |
|---|---|---|---|---|
| LCP (Largest Contentful Paint) | Em quanto tempo o conteúdo principal aparece? | Até 2,5 s | Até 4 s | Acima de 4 s |
| INP (Interaction to Next Paint) | A página responde rápido quando eu toco ou clico? | Até 200 ms | Até 500 ms | Acima de 500 ms |
| CLS (Cumulative Layout Shift) | As coisas ficam paradas no lugar enquanto carrega? | Até 0,1 | Até 0,25 | Acima de 0,25 |
Dois detalhes mudam a forma de ler esses números:
- Vale o percentil 75. Uma página passa quando pelo menos 75% das visitas ficam dentro do limite "bom". Não adianta a página carregar rápido no seu computador se um quarto dos visitantes tem uma experiência ruim.
- Celular e computador são avaliados separadamente. Na maioria dos sites, o celular é onde está o problema e também a maior parte do tráfego.
O INP substituiu, em 2024, a métrica antiga de interatividade (FID). Se você ainda vê relatórios falando em FID, eles estão desatualizados.
Por que o negócio deve se importar
Os Core Web Vitals fazem parte dos sinais de experiência que o Google considera, mas não passam na frente da relevância: um conteúdo ótimo e lento ainda pode ranquear bem. O motivo mais forte para cuidar deles é outro: velocidade e estabilidade afetam diretamente a taxa de conversão e o custo da mídia paga, porque cada clique pago que desiste antes de ver a página é verba perdida.
Quer estimar quanto a lentidão custa no seu caso? A Manáry tem uma ferramenta gratuita para isso: quanto custa um site lento.
Como medir do jeito certo
Existem dois tipos de dado, e confundir os dois é a origem de muita decisão errada.
| Dados de campo | Dados de laboratório | |
|---|---|---|
| O que são | Medições de visitantes reais, com aparelhos e conexões reais | Um teste simulado, em condições controladas |
| Onde ver | Search Console, PageSpeed Insights (parte de cima), relatório CrUX, medição própria no GA4 | Lighthouse, PageSpeed Insights (parte de baixo), DevTools do Chrome |
| Serve para | Saber se o problema existe e se a correção funcionou | Descobrir a causa e testar uma correção antes de publicar |
| Cuidado | Demora cerca de 28 dias para refletir uma mudança | Varia de um teste para o outro; não é o que o Google usa para avaliar |
As ferramentas, em ordem de uso
Search Console, relatório de Core Web Vitals
Mostra grupos de páginas com problema, separados por celular e computador. É o mapa geral: diz quais modelos de página (produto, artigo, landing) precisam de atenção.
PageSpeed Insights
Para uma página específica, mostra em cima os dados de campo (quando há tráfego suficiente) e embaixo um teste de laboratório com as oportunidades de melhoria.
DevTools do Chrome
Na aba de desempenho, mostra qual é o elemento do LCP, quais tarefas longas travam as interações e o que se mexe na tela. É onde o desenvolvedor encontra a causa.
Medição própria (opcional, recomendada)
A biblioteca web-vitals do Google pode enviar LCP, INP e CLS de cada visita para o GA4. Assim você vê os números por página, por dispositivo e por campanha, sem esperar o relatório público.
O que ignorar
Muito tempo e dinheiro se perde perseguindo o número errado. Estes são os que a gente recomenda deixar em segundo plano:
- A nota de 0 a 100 do Lighthouse como meta. Ela é um resumo de um teste de laboratório. Ajuda a diagnosticar, mas um site pode ter nota 70 e passar em todos os Core Web Vitals de campo, ou ter nota 95 e falhar no celular real.
- Testar só no computador. A conexão e o processador de um notebook de trabalho escondem os problemas do celular médio do seu cliente.
- Um teste só. Resultados de laboratório variam. Rode três a cinco vezes e olhe a mediana.
- Páginas sem tráfego. Corrigir uma página que recebe dez visitas por mês não muda o negócio. Comece pelas que recebem mídia paga e pelas que vendem.
- Notas de outras ferramentas (letras, graus, pontuações próprias). Úteis para comparar antes e depois, mas não são o que o Google avalia.
A meta não é nota 100. A meta é que três em cada quatro visitas reais, no celular, tenham uma boa experiência nas páginas que vendem.
Capítulo 4Em que ordem corrigir
A ordem certa economiza semanas de trabalho. É esta que a gente segue nos projetos da Manáry:
Liste as páginas que vendem
Landing pages de mídia paga, páginas de produto e de serviço, carrinho e checkout, formulários. Cruze com o tráfego do GA4 e fique com as que mais recebem visita.
Olhe o celular primeiro
Na maioria dos sites, é onde estão os piores números e a maior parte do público.
Corrija o modelo, não a página
Se todas as páginas de produto têm o mesmo problema, a causa está no modelo. Uma correção resolve centenas de páginas.
Comece pelo LCP
É a métrica mais ligada à primeira impressão e à desistência. As correções costumam ter efeito rápido.
Depois o CLS
Quase sempre tem causas simples (imagens sem tamanho, banners que empurram o conteúdo) e correção barata.
Por último o INP
Exige mais investigação, porque depende do JavaScript do site e das ferramentas de terceiros. É também onde estão os ganhos mais difíceis de copiar pela concorrência.
Corrigindo o LCP
O LCP mede quando o maior elemento visível aparece, quase sempre a imagem principal ou o título do topo. O tempo dele se divide em quatro partes, e cada uma tem um tipo de correção:
| Parte do tempo | O que acontece | Correção típica |
|---|---|---|
| Resposta do servidor | O navegador espera o servidor começar a enviar a página | Cache de página, hospedagem melhor, CDN |
| Atraso para começar a baixar | O navegador demora a descobrir a imagem principal | Imagem no HTML, pré-carregamento e prioridade alta |
| Download do recurso | A imagem é pesada | WebP ou AVIF, tamanho certo para cada tela |
| Atraso para desenhar | CSS, JavaScript ou fontes travam a pintura | Menos CSS e JS bloqueando, fontes otimizadas |
Nunca adie o carregamento da imagem principal
O carregamento tardio (lazy load) é ótimo para imagens do meio e do fim da página, mas aplicado na imagem do topo atrasa justamente o LCP. A imagem principal deve carregar imediatamente e com prioridade alta (atributo fetchpriority="high").
Use o formato e o tamanho certos
WebP ou AVIF costumam ter uma fração do peso de um JPEG ou PNG equivalente. E a imagem deve ter o tamanho em que é exibida: uma foto de 4000 pixels mostrada em um celular de 400 pixels é desperdício. O atributo srcset entrega a versão certa para cada tela.
Evite carrossel e vídeo pesado no topo
Carrosséis carregam várias imagens e scripts antes de mostrar a primeira. Vídeos de fundo pesam muito no celular. Uma imagem bem escolhida converte igual ou melhor e carrega muito mais rápido.
Ative cache de página e CDN
Uma página servida pronta do cache, de um servidor perto do visitante, começa a chegar em uma fração do tempo de uma página montada a cada visita.
Cuide das fontes
Use poucas famílias e pesos, hospede as fontes no próprio site quando possível, pré-carregue a principal e use font-display: swap para o texto aparecer mesmo antes de a fonte chegar.
Corrigindo o INP
O INP mede o tempo entre um toque ou clique e a próxima atualização da tela. Quando ele é ruim, a pessoa toca no botão e nada acontece por um instante, e toca de novo, ou desiste. A causa quase sempre é JavaScript demais rodando ao mesmo tempo.
Corte e adie scripts de terceiros
Chat, mapas de calor, pixels de várias plataformas, widgets de avaliação. Cada um parece leve sozinho; juntos, ocupam o processador do celular. Revise o Tag Manager, remova o que ninguém usa e carregue o restante depois da interação ou só nas páginas que precisam.
Quebre tarefas longas
Qualquer tarefa de JavaScript acima de 50 milissegundos trava a página. O desenvolvedor pode dividir o trabalho em partes menores e devolver o controle ao navegador entre elas, para que a resposta ao toque venha primeiro.
Dê resposta visual imediata
Ao clicar em um botão que dispara algo demorado (enviar formulário, filtrar produtos), mostre na hora um estado de carregamento. A tela muda rápido e o trabalho pesado acontece em seguida.
Reduza o tamanho da página
Páginas com milhares de elementos (comum em construtores visuais e em menus enormes) deixam cada atualização de tela mais lenta. Simplificar a estrutura melhora o INP e o LCP ao mesmo tempo.
O seu site está perdendo venda por lentidão?
A Manáry audita os Core Web Vitals das páginas que vendem e entrega as correções em ordem de impacto.
Corrigindo o CLS
O CLS mede o quanto o conteúdo pula enquanto a página carrega. É aquele momento em que você vai tocar em um link e o texto desce porque um banner apareceu em cima. Além de irritar, causa clique errado, inclusive em botão de compra.
- Dê tamanho a imagens, vídeos e iframes. Com largura e altura (ou proporção) definidas, o navegador reserva o espaço antes de a mídia chegar.
- Reserve espaço para o que entra depois. Banners, avisos, anúncios e widgets que carregam depois devem ter uma área reservada, ou aparecer sobre o conteúdo, sem empurrá-lo.
- Banner de cookies flutuando, não empurrando. Um aviso que entra no topo e empurra a página é uma das causas mais comuns de CLS ruim.
- Fontes com medidas parecidas. Quando a fonte do site chega e substitui a fonte provisória, o texto pode mudar de tamanho. Ajustar a fonte provisória para ter medidas parecidas evita o salto.
- Animações com transformação. Animar posição e tamanho com transform não empurra os elementos vizinhos.
Capítulo extra: WordPress
Boa parte dos sites de empresas no Brasil roda em WordPress. A plataforma pode ser muito rápida, mas alguns hábitos comuns deixam ela lenta.
| Hábito | Efeito | O que fazer |
|---|---|---|
| Um plugin para cada coisa | Dezenas de scripts e estilos em todas as páginas | Revisar a lista de plugins e remover os que não são essenciais |
| Imagem enviada do jeito que veio | LCP alto e páginas pesadas | Plugin de otimização com conversão para WebP ou AVIF |
| Sem cache de página | Servidor monta a página a cada visita | Cache de página e, se possível, cache no servidor da hospedagem |
| Hospedagem mais barata possível | Resposta lenta do servidor em todo acesso | Hospedagem com PHP atualizado e recursos compatíveis com o tráfego |
| Construtor visual com estrutura pesada | Muitos elementos e CSS por página | Seções enxutas, componentes reaproveitados, nada escondido que carregue sem aparecer |
| Otimização no automático | Recursos que quebram o site ou pioram uma métrica para melhorar outra | Ligar uma opção por vez e medir antes e depois |
Atenção às opções de "atrasar todo o JavaScript" dos plugins de cache. Elas podem melhorar o teste de laboratório e, ao mesmo tempo, atrasar a resposta dos primeiros cliques. Meça o INP de campo depois de ligar.
Plano de correção em quatro semanas
Semana 1: diagnóstico
Search Console e PageSpeed Insights nas páginas que vendem, no celular. Liste a métrica que falha em cada modelo de página e a causa provável.
Semana 2: correções de LCP
Imagem principal, cache, fontes. Publique e confira no laboratório que a mudança surtiu efeito.
Semana 3: CLS e limpeza
Tamanhos de mídia, banners, plugins e scripts de terceiros que não fazem falta.
Semana 4: INP e monitoramento
Tarefas longas e scripts pesados nas páginas com mais interação. Ligue a medição de campo e marque a revisão do Search Console para quatro semanas depois.
Perguntas frequentes
Corrigi o site, mas o Search Console ainda mostra problema. Por quê?
Os dados de campo usam as últimas quatro semanas de visitas. A melhora aparece aos poucos. Use o laboratório para confirmar a correção e espere o ciclo do relatório.
A página não tem dados de campo no PageSpeed Insights. E agora?
Páginas com pouco tráfego não aparecem no relatório público. Use os dados do domínio inteiro, o teste de laboratório e, de preferência, a sua própria medição com a biblioteca web-vitals.
Trocar de plataforma resolve?
Raramente é necessário. Na maior parte dos casos, imagens, cache, scripts de terceiros e estrutura de página resolvem dentro da plataforma atual, com custo bem menor.
Core Web Vitals bons garantem primeira posição no Google?
Não. Eles são um dos sinais de experiência, e a relevância do conteúdo continua pesando mais. O ganho mais certo é em conversão: mais gente vê a página, interage e compra.
Quer um site rápido de verdade?
A Manáry desenvolve e otimiza sites com metas de Core Web Vitals no contrato, medidas com dados reais.
Continue a leitura
Libere o material completo com um cadastro rápido. Vale para todos os materiais da Manáry.
Leva menos de um minuto. Sem sequência de e-mail que você não pediu.Quer que a gente aplique isso no seu negócio?
Este material é o que a Manáry faz todos os dias com os clientes. Se fizer sentido, um especialista olha os seus números e devolve as prioridades, sem apresentação comercial.
Continue estudando
- E-book · 16 min de leituraO funil que ninguém mede
- E-book · 15 min de leituraChecklist de rastreamento
- Planilha · Excel e Google SheetsCalculadora de CAC e LTV
- Guia · 8 min de leituraBriefing de projeto digital
- Planilha · Excel e Google SheetsMapa de canais por segmento
Libere a leitura completa
Cinco campos rápidos e você lê agora, na página. O cadastro vale para todos os materiais da Manáry.