Site lento: como descobrir a causa e melhorar a velocidade
Tutorial para medir um site lento, identificar o gargalo e melhorar LCP, INP, CLS, imagens, JavaScript, cache e servidor.
Erlan Carreira
Engenheiro de Software & Empreendedor
Um site lento deve ser tratado com medição, não com uma lista aleatória de plugins. O caminho mais seguro é separar dados de usuários reais dos testes de laboratório, localizar a etapa que consome tempo e alterar uma variável por vez. Este tutorial mostra como fazer isso sem esconder o problema.
Resposta direta: o que fazer quando o site está lento
Teste a URL no PageSpeed Insights em celular e computador. Anote LCP, INP, CLS e TTFB, abra os diagnósticos do Lighthouse e confira a aba Network do navegador. Depois corrija primeiro o recurso que forma o LCP, reduza JavaScript bloqueante, estabilize dimensões dos elementos e melhore cache ou servidor. Publique, meça novamente e compare nas mesmas condições.
Entenda os números antes de otimizar
O PageSpeed combina dois tipos de informação. Os dados de campo vêm do Chrome UX Report e representam visitas reais dos últimos 28 dias, quando há amostra suficiente. Os dados de laboratório simulam uma visita e ajudam a reproduzir gargalos. Uma nota alta no laboratório não substitui a experiência real.
| Métrica | Bom | O que costuma piorá-la |
|---|---|---|
| LCP | até 2,5 s | imagem principal pesada, fonte, CSS ou servidor lento |
| INP | até 200 ms | JavaScript longo, componente pesado, excesso de terceiros |
| CLS | até 0,1 | imagem sem tamanho, banner tardio, troca de fonte |
Esses limites são avaliados no percentil 75. Corrigir só a página inicial pode não resolver um grupo inteiro de URLs com o mesmo template.
Passo 1: reproduza o problema
Abra uma janela anônima, desative extensões e teste a página em uma rede comparável à do público. No Chrome DevTools, abra Network, marque Disable cache e recarregue. Ordene por duração e tamanho. Observe o documento HTML, a imagem principal, fontes, CSS, JavaScript e chamadas externas.
Use também:
curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s Total: %{time_total}s\n" https://exemplo.com/paginaUm TTFB alto aponta para servidor, consulta ao banco, função remota ou cache. Um HTML rápido seguido de muitos segundos até a imagem principal aponta para o front-end ou a mídia.
Passo 2: corrija o LCP
Descubra qual elemento é o LCP no relatório. Se for uma imagem, entregue AVIF ou WebP no tamanho visual correto, informe width e height, use srcset e não aplique lazy loading à imagem que aparece imediatamente. Um preload só ajuda quando o navegador descobriria o recurso tarde; usado em excesso, disputa banda com itens essenciais.
Se o LCP for texto, verifique fontes e CSS. Hospede apenas os pesos usados, prefira WOFF2 e configure uma estratégia de exibição que não deixe o texto invisível. Remova CSS não utilizado com cuidado e carregue estilos críticos cedo.
Passo 3: reduza o INP
Clique nos controles durante uma gravação na aba Performance. Tarefas longas bloqueiam a thread principal. Divida processamento grande, adie scripts que não participam da primeira interação e evite recalcular toda a interface quando apenas uma parte mudou.
Scripts de chat, mapas, vídeo, testes A/B e publicidade também consomem processamento. Carregue-os quando necessários e meça o custo de cada fornecedor. Para AdSense, reserve previamente o espaço do anúncio e evite inserir blocos que deslocam o conteúdo.
Passo 4: elimine mudanças de layout
Defina dimensões ou aspect-ratio para imagens, vídeos e anúncios. Não injete avisos acima do conteúdo depois que a página apareceu. Em fontes, escolha uma alternativa de sistema com proporções próximas. Reproduza a página lentamente: o elemento que salta costuma revelar a causa do CLS.
Passo 5: trabalhe cache e servidor
Arquivos versionados podem receber cache longo; HTML dinâmico exige uma política coerente com a atualização do conteúdo. Use CDN para conteúdo público, comprima respostas e remova redirecionamentos desnecessários. No back-end, registre tempo de consultas e chamadas externas. Não aumente recursos da máquina sem saber se o gargalo é CPU, banco, rede ou código.
Checklist de validação
- compare antes e depois na mesma URL e dispositivo;
- teste páginas internas, não apenas a home;
- confirme que imagens continuam nítidas;
- verifique login, formulário e menu após reduzir scripts;
- acompanhe dados de campo por pelo menos 28 dias;
- configure alertas para regressões de build e tamanho.
Para uma reconstrução mais ampla, veja site institucional ou landing page. Se o gargalo estiver em integrações, entenda como monitorar APIs.
Perguntas frequentes
Instalar cache resolve qualquer site lento?
Não. Cache pode reduzir servidor e transferência, mas não corrige JavaScript excessivo, mídia desproporcional ou mudança de layout.
A nota 100 é obrigatória para aparecer no Google?
Não. Relevância e qualidade continuam fundamentais. O objetivo é oferecer boa experiência e atingir métricas consistentes, não perseguir uma pontuação isolada.
Fontes primárias
Erlan Carreira
Engenheiro de Software & Empreendedor
Especialista em desenvolvimento de software, automação e SaaS. Escrevo sobre tecnologia, negócios digitais, IA e boas práticas de engenharia para times que buscam excelência na execução.