Os sites muitas vezes são acelerados na ordem errada: alguém instala um plugin de otimização, ativa todas as opções e depois tenta descobrir por que o formulário deixou de funcionar. A ordem correta é medição, uma hipótese, uma mudança, verificação das funções e nova medição.
Em uma versão mais antiga, também descrevi abordagens que não recomendo mais, como fazer proxy localmente dos scripts de terceiros ou implementar AMP e PWA de forma generalizada. Elas trouxeram melhorias parciais em laboratório, mas acrescentaram risco de código desatualizado, atualizações quebradas e manutenção mais complicada. Um site moderno deve ser rápido em sua versão principal.
O que medir hoje
Para os Core Web Vitals, o Google usa três métricas estáveis:
- LCP: carregamento do conteúdo principal; um bom valor é de até 2.5 segundos.
- INP: resposta às interações; um bom valor é inferior a 200 milissegundos.
- CLS: mudanças inesperadas de layout; um bom valor é de no máximo 0.1.
Os limites se aplicam ao percentil 75 e estão resumidos na visão geral oficial Core Web Vitals para a Pesquisa Google. Os resultados de visitantes reais no Search Console ou no CrUX têm prioridade sobre um único teste de laboratório no meu notebook.
As ferramentas de laboratório continuam importantes: elas mostram a cascata, a thread principal, o código não utilizado e candidatos concretos para correção. Os dados de campo mostram que existe um problema; o laboratório ajuda a explicar por quê.
Primeiro defina o escopo do problema
- Compare dispositivos móveis e desktop.
- Separe os templates: página inicial, artigo, serviço, listagem, formulário e loja virtual.
- Verifique os países, dispositivos e fontes de tráfego com melhor e pior desempenho.
- Encontre grupos de URLs com dados de campo ruins.
- Capture um rastreamento de laboratório reproduzível para uma página representativa.
Uma página inicial rápida não significa que o site seja rápido. Uma visita lenta em um celular antigo não significa que todo o sistema precise ser reescrito.
Intervenções com maior impacto comum
1. Servidor e HTML
Meça o tempo até o primeiro byte e divida-o em DNS, conexão, espera pelo servidor e redirecionamentos. Esperas longas podem vir da hospedagem, do banco de dados, de uma página sem cache, de uma API lenta ou de cadeias de redirecionamento. Ative um cache de página adequado para conteúdo público e cache de objetos quando fizer sentido. Exclua corretamente do cache usuários conectados, carrinhos e personalização.
2. Imagem principal
O LCP costuma ser a imagem principal. Entregue um tamanho compatível com sua exibição, use srcset, compressão e WebP ou AVIF moderno com um fallback adequado. Não carregue a imagem principal com lazy loading; use lazy loading nas imagens abaixo da primeira viewport. Defina a largura e a altura da imagem para que o navegador reserve espaço e o CLS permaneça baixo.
3. CSS e fontes
Remova estilos não utilizados com cuidado e mantenha o CSS crítico pequeno. Limite as fontes aos pesos e conjuntos de caracteres necessários, mantenha os arquivos locais em cache por bastante tempo e faça preload apenas de uma fonte realmente necessária no início. Fazer preload de dez fontes apenas cria outra fila.
4. JavaScript e interação
Divida bundles grandes, adie o código não crítico e carregue terceiros apenas quando necessário e quando o consentimento permitir. async e defer não são mágicos; teste a ordem e as dependências dos scripts. Divida tarefas longas da thread principal e não faça um clique esperar pela análise de dados.
5. Terceiros
Chats, mapas de calor, pixels de publicidade, vídeos e ferramentas de A/B adicionam requisições de rede e trabalho do processador. Cada script precisa de um responsável e de uma razão de negócio. Não o carregue de forma síncrona no cabeçalho apenas porque o guia de instalação é mais curto. A análise pode ser gerenciada pelo Google Tag Manager, mas o próprio contêiner não consegue recuperar o desempenho.
WordPress: menos camadas, mais controle
A documentação do WordPress recomenda abordar o desempenho por meio da hospedagem, da quantidade e qualidade dos plugins, das imagens, do cache e de uma rede de distribuição. Leia a visão geral de otimização e a explicação separada sobre cache.
- Atualize primeiro o WordPress, o PHP, o tema e os plugins em um ambiente de homologação.
- Remova plugins não utilizados e ferramentas de cache ou minificação sobrepostas.
- Analise as consultas ao banco de dados e as chamadas externas lentas.
- Planeje a manutenção do banco de dados, mas não exclua revisões ou metadados às cegas.
- Após cada otimização, teste formulários, pesquisa, login e o fluxo de compra.
Discuto a seleção sensata de complementos nos melhores plugins para WordPress.
O que não fazer
- Não baixe os scripts de análise ou publicidade de terceiros para o seu servidor apenas por causa de uma pontuação; você pode perder atualizações de segurança e funcionamento.
- Não defina um cache de um ano para um arquivo que muda sem versionar seu nome.
- Não remova CSS ou JavaScript de um relatório automatizado sem testar cada template.
- Não avalie o sucesso apenas pelo Lighthouse. O Google afirma explicitamente que bons Core Web Vitals, por si só, não garantem posições altas nem uma ótima experiência do usuário.
- Não acelere um site escondendo conteúdo ou uma função de que o cliente precisa.
Um plano de quatro semanas
- Semana 1: linha de base dos dados de campo, medições de laboratório e lista de templates.
- Semana 2: servidor, cache, redirecionamentos e os maiores recursos de LCP.
- Semana 3: imagens, fontes, CSS, JavaScript e terceiros.
- Semana 4: teste de regressão, novas medições, monitoramento e documentação.
Para cada mudança, registre a data, a URL, a métrica antes e depois, o impacto funcional e a opção de reversão. Acompanhe também a taxa de conversão, a conclusão dos formulários e os erros; uma página mais rápida que vende menos não é uma otimização concluída.
Comece verificando as bases técnicas e a análise do site em uma auditoria técnica e no GA4. Se precisar priorizar correções por impacto e custo, fale comigo pela página de contato.