PageSpeed alto e site lento podem coexistir. A nota resume um teste de carregamento; o visitante também abre menus, preenche campos e espera respostas. Antes de instalar outro plugin ou trocar de hospedagem, descubra quando a lentidão acontece.
O caminho é conferir três coisas: página ou origem, laboratório ou campo, carregamento ou interação. Veja mais sobre essas decisões em Desenvolvimento web e desempenho.
Neste artigo
A nota e os dados reais respondem a perguntas diferentes
A nota de desempenho resume uma execução do Lighthouse. Ajuda a localizar problemas e comparar testes em condições semelhantes. Rede, conteúdo e ambiente fazem o resultado variar; registre as métricas e as condições, além da nota.
A experiência real vem do CrUX, em uma janela dos últimos 28 dias. Confira se o relatório descreve a URL ou a origem. Sem amostras suficientes da página, o PageSpeed pode mostrar a origem; sem dados também ali, não há avaliação. Ausência de dados não significa aprovação nem reprovação.
As Core Web Vitals são LCP, INP e CLS. No percentil 75, os limites bons são até 2,5 segundos, 200 milissegundos e 0,1, respectivamente. Esse percentil não é a média: observe também a distribuição, pois o resultado agregado pode esconder experiências piores.
Para conferir as definições antes de interpretar o relatório, consulte a Documentação do PageSpeed Insights. A fonte explica o escopo da nota e dos dados de campo.
Encontre o momento em que a página fica lenta
Conteúdo principal demora a aparecer? Examine o carregamento. Menu demora após a página aparecer? Reproduza o clique. Busca responde ao toque, mas demora a trazer resultados? Meça a requisição e a conclusão da tarefa. Cada sintoma pede uma investigação diferente.
O INP mede a resposta visual a cliques, toques e teclas. Não cobre sozinho todo o tempo de uma operação assíncrona. Um aviso de carregamento pode aparecer depressa enquanto a resposta do servidor demora; meça também essa espera.
TBT baixo no teste de carregamento não descarta interações lentas depois. Registre a ação, o dispositivo e as condições. Use dados de campo para orientar a reprodução; sem eles, teste os fluxos comuns da página.
Para reproduzir a lentidão depois do carregamento, siga as etapas de Como investigar interações lentas e compare o fluxo observado com os dados de campo disponíveis.
Uma leitura aplicada ao site em produção
Em 1º de novembro de 2026, às 00h48 CET, uma análise online do artigo sobre llms.txt deste blog retornou nota 99 no teste móvel. O relatório usou Lighthouse 13.6.0, Moto G Power emulado e limitação de rede 4G lenta. Foi uma execução de carregamento inicial, não um acompanhamento de visitantes.
O teste registrou LCP de 1,1 segundo, TBT de 0 ms e CLS de 0,053. Na experiência real, apareceu “No hay datos”. Os números de laboratório foram bons naquela execução; faltam dados de campo para avaliar os visitantes.
Esse exemplo não comprova que o site esteja lento. Ele mostra o limite de uma nota alta: o 99 não preenche a informação que falta sobre uso real. Tampouco o TBT de 0 ms demonstra que menus, busca e formulários responderão bem em qualquer situação.
Apesar da nota 99, o relatório aponta recursos que bloqueiam a renderização e estima economia de 840 ms. Não é um ganho obtido. Examine os recursos, proponha uma alteração e compare antes e depois. Aqui registrei o diagnóstico; não alterei o site nem medi melhora.
Eu registraria a medição e testaria os fluxos relevantes antes de perseguir o ponto que falta. Uma reclamação precisa de URL, ação, dispositivo e rede para ser reproduzida. Outra execução pode trazer números diferentes; esta nota não é permanente.
Os números e as condições descritos acima estão no relatório online da demonstração; consulte a execução original antes de extrapolar o resultado para outros visitantes.
Escolha a próxima ação pelo que você encontrou
Nota alta, campo ruim: confira se está comparando o mesmo escopo e tipo de dispositivo. Depois procure reproduzir a métrica problemática nas condições dos visitantes. O contraste pode revelar uma experiência que a execução de laboratório não representou.
Nota baixa, campo bom: examine os diagnósticos e a variação entre testes. Pode haver uma oportunidade importante para aparelhos ou redes mais limitados. Antes de aceitar uma intervenção grande, identifique quem ela beneficia e qual comportamento deve melhorar.
Sem dados de campo: use o laboratório para orientar a investigação e teste as tarefas principais. Se precisar acompanhar visitantes, considere mensuração própria de desempenho, com escopo e tratamento de dados adequados. Até lá, mantenha a conclusão limitada ao que foi observado.
Lentidão depois do clique: grave o fluxo no painel Performance do Chrome DevTools. Identifique se a espera ocorre antes do processamento, no JavaScript, na apresentação do próximo frame ou na resposta da rede. Investigue a etapa observada.
Para interpretar esse contraste, veja a explicação sobre por que laboratório e campo podem divergir. Ela ajuda a separar condições controladas da experiência real.
Transforme a reclamação em uma tarefa verificável
Troque “melhore o PageSpeed” por um sintoma reproduzível: “Nesta URL, ao abrir a busca no celular, há uma pausa antes de o campo aparecer”. Anote dispositivo, rede, estado de login e passos. Não é preciso coletar dados pessoais.
Defina a evidência esperada: gravações do mesmo fluxo antes e depois, em condições comparáveis. Identifique o trecho responsável e preserve busca, navegação por teclado e integrações. Uma nota melhor não compensa uma tarefa quebrada.
No laboratório, repita o teste e registre a variação, sem escolher apenas a melhor nota. No campo, anote a data da alteração: a janela móvel ainda mistura experiências anteriores e posteriores.
Se a demora estiver depois do clique, use o guia do painel Performance do Chrome DevTools para gravar o fluxo e localizar a etapa responsável.
Quando parar de perseguir a pontuação
Priorize uma correção quando conseguir conectar um sintoma a uma causa e a um benefício verificável para o visitante. Se os fluxos importantes estão funcionando bem e a proposta só promete mudar o número, peça uma justificativa proporcional ao custo e ao risco da alteração.
Isso também vale para SEO. O Google informa que usa Core Web Vitals em seus sistemas, mas bons resultados não garantem o topo da busca. A própria documentação observa que buscar uma pontuação perfeita apenas por SEO pode não ser o melhor uso do tempo.
A orientação do Google sobre experiência na página ajuda a interpretar o papel dos Core Web Vitals na busca sem prometer posições.
Nota de método: análise documental e uma execução online no site em produção, com pesquisa, redação e ilustração assistidas por IA. Não foram medidos ganho de conversão, melhora de ranking ou INP de visitantes. A capa é uma ilustração baseada em fotos do autor.