Para corrigir um site lento, identifique primeiro onde o tempo é gasto e qual experiência real está ruim. A nota do PageSpeed é um sinal de laboratório; Core Web Vitals usam métricas centradas no usuário e devem ser avaliadas com dados de campo quando disponíveis.
As três métricas estáveis
- LCP: quando o maior conteúdo visível é renderizado. A referência de boa experiência é até 2,5 segundos no percentil 75.
- INP: responsividade das interações durante a visita. Valor baixo indica resposta consistente.
- CLS: instabilidade visual. A referência de boa experiência é até 0,1 no percentil 75.
Campo e laboratório não são iguais
Dados de campo refletem dispositivos, redes e usuários reais. Laboratório reproduz uma condição controlada e ajuda a depurar. Uma página pode ir bem em um teste e mal para usuários reais; também pode não ter volume suficiente para dados de campo.
Diagnóstico em ordem
1. Servidor e TTFB
Verifique cache, consultas, PHP, banco, CDN e capacidade. Otimizar imagens não corrige uma resposta inicial travada.
2. Elemento LCP
Descubra qual imagem ou bloco é o LCP. Garanta que esteja no HTML, com prioridade adequada, formato eficiente e sem lazy-load indevido.
3. JavaScript e INP
Localize tarefas longas, scripts de terceiros e handlers pesados. Reduza trabalho no thread principal e carregue recursos quando realmente necessários.
4. Dimensões e CLS
Reserve espaço para imagens, anúncios e embeds. Evite inserir banners acima do conteúdo e cuide do carregamento de fontes.
Erros comuns
- instalar vários plugins de cache ao mesmo tempo;
- converter imagens sem tratar o elemento LCP;
- remover CSS crítico e quebrar renderização;
- buscar nota 100 sem medir conversão;
- testar apenas a home;
- ignorar páginas mobile e templates internos.
Plano de correção
- Escolha templates e páginas de maior valor.
- Registre dados antes da mudança.
- Corrija o gargalo dominante.
- Teste funcionalidade e visual.
- Compare laboratório imediatamente.
- Acompanhe campo após acumular dados.
Velocidade é parte de um projeto maior. Veja quanto custa um site profissional e conheça meu trabalho de desenvolvimento orientado a performance.
PageSpeed é um diagnóstico, não um placar
Uma nota baixa indica oportunidades de investigação, mas não revela sozinha a experiência de todos os usuários. O relatório combina dados de laboratório, produzidos em ambiente controlado, e dados de campo, coletados de visitas reais quando existe volume suficiente.
As três métricas centrais
| Métrica | O que representa | Boa experiência |
|---|---|---|
| LCP | Carregamento do principal elemento visível. | Até 2,5 segundos. |
| INP | Resposta visual após interações. | Abaixo de 200 milissegundos. |
| CLS | Movimentos inesperados do layout. | Abaixo de 0,1. |
A avaliação de campo costuma observar o percentil 75 e deve ser segmentada por dispositivo. Uma média boa pode esconder usuários com experiência ruim.
Como diagnosticar LCP
Identifique qual elemento é o LCP em cada modelo de página. Pode ser imagem principal, título ou banner. Separe tempo de resposta do servidor, descoberta do recurso, download e renderização.
- Não carregue a imagem principal de forma preguiçosa.
- Entregue dimensões e formato adequados.
- Reduza redirects e atraso do servidor.
- Priorize o recurso quando ele for realmente crítico.
- Evite esconder o conteúdo atrás de scripts.
Como diagnosticar INP
INP piora quando a thread principal fica ocupada e não consegue responder. Procure tarefas longas, bibliotecas excessivas, listeners custosos e componentes que fazem muito trabalho após cada clique.
Divida tarefas, remova JavaScript sem função, adie recursos secundários e teste interações reais como menu, busca, formulário e filtros.
Como diagnosticar CLS
Reserve espaço para imagens, anúncios, embeds e mensagens. Fontes podem trocar dimensões durante o carregamento. Barras de consentimento e formulários não devem empurrar conteúdo depois que o usuário começou a ler.
Por que laboratório e campo divergem?
O laboratório usa um dispositivo, rede e execução definidos. Campo reúne pessoas, aparelhos, conexões, cache e comportamentos diferentes. Use laboratório para reproduzir e depurar; use campo para avaliar a experiência real ao longo do tempo.
WordPress e excesso de dependências
Plugins não são ruins por definição. O problema é carregar recursos em todas as páginas, duplicar funções e manter extensões abandonadas. Faça inventário por impacto e necessidade antes de remover.
Construtores podem gerar HTML e CSS maiores, mas uma troca completa nem sempre é a primeira solução. Corrija imagens, cache, fontes, scripts externos e servidor conforme evidência.
Scripts de terceiros
Tags de marketing, chats, mapas, vídeos e testes podem consumir rede e processamento. Defina proprietário, finalidade, páginas necessárias e condição de carregamento. Uma tag sem responsável tende a permanecer para sempre.
Ordem de otimização
- Meça modelos importantes, não apenas a home.
- Identifique o elemento ou interação responsável.
- Corrija servidor e recursos críticos.
- Otimize imagens e fontes.
- Reduza JavaScript e terceiros.
- Evite mudanças de layout.
- Valide laboratório e monitore campo.
Performance e conversão
Velocidade reduz atrito, mas não corrige oferta confusa. Acompanhe abandono, conclusão de formulário e vendas junto das métricas técnicas. Uma alteração pode melhorar nota e prejudicar clareza.
Performance e SEO
Core Web Vitals participa da experiência de página, mas nota 100 não garante posição. Conteúdo, relevância, acesso, links e muitos outros sinais continuam importantes. Trate desempenho como qualidade do produto.
Perguntas frequentes
Preciso alcançar 100?
Não. Priorize limites de boa experiência, problemas reais e páginas importantes.
Hospedagem resolve tudo?
Servidor ajuda no tempo inicial, mas não corrige imagens enormes, JavaScript excessivo ou layout instável.
Cache resolve?
Ajuda em recursos repetidos e geração de página. A primeira visita e interações ainda dependem de arquitetura eficiente.
02
03
04
