É comum ver frases como "cada segundo a mais custa tantos por cento das vendas". Existem estudos sérios sobre o tema, mas os números valem para o contexto de quem mediu e não se transferem automaticamente para o seu site. O que dá para afirmar com segurança é mais simples: páginas lentas, ou que se mexem enquanto carregam, frustram quem está do outro lado, principalmente no celular. E o Google tem uma forma pública de medir isso, as Core Web Vitals.
Neste post explico as três métricas de um jeito prático e o que costuma estar por trás de um site lento.
Dado de campo e dado de laboratório
Antes das métricas, uma distinção que evita muita confusão. Dado de laboratório é uma simulação: o Lighthouse carrega a página em condições controladas e dá uma nota. Dado de campo é o que usuários reais do Chrome viveram, reunido no relatório CrUX e exibido no PageSpeed Insights e no Search Console.
Uma nota 100 no seu notebook não garante boa experiência para quem abre o site num celular intermediário com sinal fraco. O web.dev recomenda avaliar o percentil 75 das visitas, separando celular e computador. Ou seja: a meta é que a grande maioria das pessoas tenha uma boa experiência, não só a média.
As três métricas em resumo
| Métrica | O que mede | Bom |
|---|---|---|
| LCP (Largest Contentful Paint) | quando o conteúdo principal aparece | até 2,5 s |
| INP (Interaction to Next Paint) | quanto a página demora para responder a um toque ou clique | até 200 ms |
| CLS (Cumulative Layout Shift) | quanto o layout se mexe sozinho | até 0,1 |
LCP: o conteúdo principal apareceu?
O LCP marca o momento em que o maior elemento visível, geralmente a imagem de destaque ou o bloco do título, termina de aparecer. O web.dev divide esse tempo em quatro partes: a resposta do servidor, o atraso até o navegador começar a baixar esse recurso, o download em si e o atraso até ele ser desenhado na tela.
Os culpados mais comuns:
- imagem de destaque enorme, sem versões para cada tamanho de tela e sem formato moderno como WebP ou AVIF;
- lazy loading aplicado justamente na imagem principal, o que atrasa o que deveria vir primeiro;
- imagem descoberta tarde, porque vem de um CSS ou é inserida por JavaScript;
- servidor lento ou sem cache;
- página que só monta o conteúdo depois de baixar e executar muito JavaScript.
INP: a página respondeu?
O INP substituiu o antigo FID como Core Web Vital em 2024. Ele mede o tempo entre uma interação (tocar num botão, abrir um menu, digitar) e o próximo quadro que mostra o resultado na tela. Esse tempo tem três fases: a espera até o navegador conseguir tratar o evento, o processamento em si e a atualização visual.
Quase sempre o problema é JavaScript demais disputando a mesma thread principal: scripts de terceiros (widgets de chat, pixels de anúncio, gerenciadores de tags), tarefas longas que não devolvem o controle ao navegador e páginas com uma quantidade enorme de elementos. A correção começa por uma pergunta pouco técnica: esse script precisa mesmo estar aqui?
CLS: a página parou de se mexer?
O CLS mede mudanças inesperadas de layout. É o botão que desce no exato momento em que você ia tocar nele. As causas mais frequentes, segundo o próprio web.dev, são imagens sem largura e altura definidas, anúncios, embeds e banners inseridos depois do carregamento, troca de fonte que muda o tamanho do texto e animações feitas com propriedades que mexem no layout em vez de transform.
A solução costuma ser reservar espaço: dimensões ou aspect-ratio nas imagens, área fixa para o que carrega depois, uma fonte de fallback com proporções parecidas com a fonte final.
O que deixa um site lento de verdade
Na prática, sites de pequenas e médias empresas raramente ficam lentos por um motivo só. O padrão que eu mais encontro é acúmulo: um tema pronto que carrega os recursos de todas as páginas em todas as páginas, vídeo de fundo no topo, carrossel, fotos enviadas direto do celular, fontes com muitos pesos e vários scripts de marketing instalados ao longo dos anos sem que ninguém lembre por quê.
Um exemplo concreto: um botão de WhatsApp pode ser um simples link, que praticamente não pesa nada, ou um widget de terceiros que baixa JavaScript em toda visita. Falo mais disso em WhatsApp em landing pages.
E a conversão?
A relação é real, mas indireta. Quem chega pelo Google ou pelo Instagram, no celular, quer entender a oferta e encontrar o contato rápido. Cada atrito (conteúdo que demora, botão que não responde, layout que pula) é uma chance a mais de desistência. Performance não substitui uma oferta clara nem uma página bem construída, como expliquei em landing page que converte. Ela tira obstáculos do caminho.
Se quiser saber o efeito no seu caso, meça: registre os contatos antes e depois das melhorias, comparando períodos com o mesmo tipo de tráfego.
Como eu trato performance num projeto
Muita coisa é decidida ainda no design: quantas fontes, se o topo tem vídeo ou imagem, quais scripts são indispensáveis. No desenvolvimento, uso imagens em tamanhos e formatos adequados, fontes hospedadas no próprio site com poucos pesos e o mínimo de JavaScript no carregamento inicial.
Antes da entrega, testo no PageSpeed Insights. Depois do lançamento, acompanho os dados de campo no Search Console quando o site já tem tráfego suficiente para aparecer neles. Explico esse trabalho em mais detalhe na página de websites.
Se o seu site parece lento e você quer entender por onde começar, pode me mandar o endereço pelo contato.