O site abre rápido no computador da equipe, mas parece travar no celular de um cliente. A primeira reação costuma ser trocar a hospedagem ou instalar mais um plugin. Antes disso, é melhor descobrir qual parte da experiência está lenta e em quais páginas o problema acontece.
Um site pode demorar para mostrar o conteúdo principal, responder tarde a um toque ou deslocar um botão enquanto carrega. Cada situação pede uma investigação diferente. Este guia organiza o diagnóstico para conversar com a equipe técnica e priorizar melhorias.
Comece pela jornada que importa para o negócio
Escolha páginas representativas: a home, uma página de serviço ou produto e o caminho até o formulário ou checkout. Testar somente a home deixa de fora problemas que aparecem mais perto da conversão.
Em um celular, faça o percurso completo e anote o sintoma:
- O título aparece, mas a imagem principal demora?
- O menu abre com atraso depois do toque?
- O botão muda de posição quando surge um banner?
- O formulário parece enviado, mas não confirma o resultado?
Registre também a página, o aparelho, a conexão e o momento do teste. Esses detalhes ajudam a reproduzir o problema. São observações da experiência, não uma medição representativa de todos os visitantes.
Como usar o PageSpeed Insights sem se prender à nota
O PageSpeed Insights reúne dados de campo, quando disponíveis, e um diagnóstico de laboratório. Os dados de campo refletem uma janela móvel de 28 dias; o laboratório executa um teste em condições simuladas.
Confira se os dados exibidos são da URL analisada ou da origem inteira. Se não houver amostra suficiente, a ausência de dados não significa aprovação nem reprovação. E uma alteração feita hoje não renova imediatamente o histórico de visitas.
Use o teste de laboratório para levantar hipóteses e comparar intervenções em condições semelhantes. Guarde a data e o relatório de referência. Uma variação isolada na nota não basta para concluir que uma mudança resolveu o problema.
Entenda as três Core Web Vitals
As Core Web Vitals cobrem carregamento, resposta a interações e estabilidade visual. Os limites considerados bons são avaliados no 75º percentil das visitas, com análise separada para celular e computador:
| Métrica | O que ajuda a observar | Limite bom |
|---|---|---|
| LCP | Quando o maior elemento de conteúdo fica visível | Até 2,5 segundos |
| INP | Resposta visual às interações | Até 200 milissegundos |
| CLS | Mudanças inesperadas de posição no layout | Até 0,1 |
Essas métricas orientam a análise, mas não substituem testar a tarefa do visitante. Um formulário pode estar rápido e ainda falhar ao registrar um contato.
Se o conteúdo principal demora: investigue o LCP
Primeiro, identifique qual elemento o relatório aponta como LCP. Pode ser uma imagem ou um bloco de texto. Depois, peça que a equipe verifique onde o tempo é gasto: resposta inicial do servidor, descoberta do recurso, transferência ou renderização.
Na orientação para otimizar LCP, o diagnóstico considera essas etapas separadamente. Para uma imagem principal, avaliar dimensões, compressão e descoberta pelo navegador costuma ser um bom começo. Evite aplicar carregamento preguiçoso à imagem responsável pelo LCP.
Exemplo ilustrativo: uma foto enorme de capa pode merecer uma versão adequada ao celular. Porém, se a espera acontece antes de qualquer resposta do servidor, reduzir somente essa foto não trata toda a causa.
Se os toques demoram: investigue o INP
Reproduza a interação específica: abrir o menu, filtrar produtos ou avançar uma etapa do formulário. Um relatório de carregamento, sozinho, não conta toda essa história.
A documentação sobre otimização de INP orienta investigar o atraso antes do processamento, o trabalho executado pela interação e a apresentação da resposta. JavaScript que ocupa a tarefa principal por muito tempo pode impedir que o navegador responda prontamente.
Peça um inventário dos scripts ativos. Para cada chat, rastreador ou componente, identifique finalidade, responsável e páginas em que é necessário. Remoções e adiamentos devem ser testados: um recurso pouco visível pode ser importante para o atendimento.
Se a página fica pulando: investigue a estabilidade
Observe o momento em que o conteúdo se desloca. Uma imagem sem espaço reservado, um aviso inserido acima do texto ou uma mudança na fonte são pistas para a investigação.
Como revisão prática, confira se imagens e componentes têm dimensões previstas e se banners convivem com o conteúdo sem empurrar controles durante a interação. Teste também depois de aceitar ou recusar opções de consentimento, quando esse mecanismo existir.
Esse cuidado importa especialmente perto de botões: o usuário precisa conseguir tocar no elemento que escolheu.
Defina prioridades e valide o resultado
Organize uma lista curta com problema, evidência, página afetada, responsável e critério de conclusão. Comece pelo que impede uma tarefa importante ou se repete em várias páginas.
Depois de cada conjunto de ajustes:
- Repita o percurso real no celular.
- Compare os testes de laboratório sob condições semelhantes.
- Verifique formulários, menus e integrações.
- Acompanhe os dados de campo conforme a janela se atualiza.
- Registre o que mudou para facilitar futuras investigações.
Não prometa um ganho comercial apenas com base na nota de performance. Compare também resultados reais do site, respeitando o contexto e a qualidade da medição.
Quando vale pedir uma revisão técnica?
Se ninguém consegue explicar o gargalo, as correções se acumulam sem comparação ou cada atualização traz um problema novo, vale organizar uma revisão. Ela deve entregar evidências e uma ordem de trabalho.
A Suddenly trabalha com desenvolvimento web, SEO técnico e performance. Para avaliar seu cenário, conte à equipe quais páginas e tarefas estão apresentando lentidão. Se a solução envolver refazer o site, confira também nosso checklist de SEO para migração.
