Comece pelo sintoma, não por um plugin
Uma página pode responder rápido e ainda assim parecer lenta. O Time to First Byte (TTFB) mede quanto tempo uma navegação espera pelo primeiro byte da resposta; o Largest Contentful Paint (LCP) trata do maior conteúdo visível; o Interaction to Next Paint (INP), da resposta a cliques, toques e teclado. Melhorar um não corrige automaticamente os outros.
Este é um guia de diagnóstico, não o relato de um trabalho medido com um cliente. Use suas próprias evidências de antes e depois para decidir se uma mudança funcionou.
Crie uma linha de base comparável
- Escolha templates representativos: um artigo, uma categoria, um produto e um checkout. Inclua sessões logadas e anônimas.
- Registre o dispositivo, a rede, a localização, a URL, o estado do cache e a versão implantada. Repita os testes de laboratório nas mesmas condições em vez de ficar com a melhor pontuação.
- Confira os dados de campo no PageSpeed Insights ou no Search Console. Uma URL com pouco tráfego pode não ter dados próprios; os dados da origem são mais amplos e devem ser identificados como tal.
- Separe os acertos de cache das falhas. Uma resposta rápida com o cache quente pode esconder uma origem lenta durante uma invalidação ou um pico de tráfego.
Reduza o trabalho do servidor com segurança
Analise a requisição do documento no painel Rede do navegador e, em seguida, o PHP, as consultas ao banco de dados e as chamadas a APIs externas. Consultas lentas, chamadas remotas repetidas, saturação de processos e uma origem distante exigem soluções diferentes. O cache de objetos persistente pode reduzir o trabalho repetido no banco, mas não é o mesmo que colocar em cache uma resposta HTML completa.
O cache de página completa pode ajudar em páginas editoriais anônimas. Não coloque em cache público páginas de conta, carrinhos, checkouts, respostas autenticadas nem respostas com informações pessoais. Revise com o seu provedor de hospedagem os cookies, os métodos de requisição, os parâmetros de consulta e as chaves de cache. Teste com duas sessões independentes antes do deploy e confirme que as edições de conteúdo invalidam o cache correspondente.
Melhore o que o navegador desenha
Identifique o elemento LCP real em um trace de desempenho. Se for uma imagem, exponha a URL no HTML inicial, ofereça variantes do tamanho certo e não use carregamento lento nela. Se for texto, analise os estilos que bloqueiam a renderização e o carregamento das fontes. Reserve espaço para imagens e conteúdos incorporados para reduzir as mudanças de layout.
Para o INP, reproduza a interação lenta e analise a thread principal. Reduza o trabalho desnecessário, divida as tarefas longas e agrupe as leituras de layout antes das escritas. Mover trabalho para uma tarefa posterior só ajuda se essa tarefa não virar outro bloco grande.
// Yield between bounded chunks; feature-detect the scheduling API.
async function yieldToBrowser() {
if (globalThis.scheduler?.yield) {
await globalThis.scheduler.yield();
} else {
await new Promise(resolve => setTimeout(resolve, 0));
}
}
// Process a small, measured batch, yield, then process the next batch.Verifique a experiência depois do deploy
Os limites considerados bons para as Core Web Vitals são LCP de até 2,5 segundos, INP de até 200 milissegundos e CLS de até 0,1, avaliados no 75º percentil das visitas. O TTFB ajuda no diagnóstico, mas não é uma Core Web Vital. Um teste de carregamento do Lighthouse não mede o INP de sessões reais.
Teste novamente o checkout, a navegação, as ferramentas de consentimento e os widgets de terceiros. Acompanhe as medições de campo ao longo do tempo; a janela de coleta móvel não vai refletir um release imediatamente. Registre a mudança e qualquer regressão junto com as medições.
Perguntas frequentes
Passar nas Core Web Vitals garante um ranqueamento melhor?
Não. Uma experiência mais rápida ajuda os leitores e pode favorecer o desempenho na busca, mas relevância, conteúdo útil e outros sinais continuam importando. Trate a velocidade como uma melhoria de produto mensurável, não como uma promessa de ranqueamento.
O TTFB é uma das Core Web Vitals?
Não. O TTFB mede o tempo até o primeiro byte da resposta e ajuda a diagnosticar o caminho do servidor e da rede. As Core Web Vitals são LCP, INP e CLS. Use o TTFB para investigar uma resposta lenta e depois verifique separadamente quando o conteúdo útil aparece e como as interações se comportam.
Por que minha página inicial em cache é rápida, mas o checkout é lento?
Uma página inicial pública pode reutilizar HTML em cache, enquanto o checkout precisa de trabalho novo e específico de cada sessão. Meça a requisição sem cache e analise as consultas ao banco, as extensões e os serviços externos. Não torne o checkout cacheável publicamente só para melhorar um teste; verifique a privacidade e a correção das transações.
Como comparo o desempenho antes e depois de uma mudança?
Mantenha comparáveis a URL, o dispositivo, o perfil de rede e o estado do cache, e repita o teste. Registre a faixa de resultados e teste a mesma ação do cliente. Use os dados de campo à medida que ficarem disponíveis; um único teste rápido de laboratório não descreve todos os visitantes. O checklist de desempenho traz uma sequência de verificação mais ampla.
Fontes e leituras recomendadas
Continue explorando
Use o checklist de velocidade para WordPress com 47 itens para ampliar a auditoria, ou conheça o serviço de desempenho web.
Leave a Reply