| Métrica | O que mede | Meta de campo |
|---|---|---|
| LCP | Tempo até o maior elemento visível carregar | Abaixo de 2,5 s |
| INP | Resposta da página à interação do usuário | Abaixo de 200 ms |
| CLS | Estabilidade visual durante o carregamento | Abaixo de 0,1 |
| TTFB | Tempo de resposta do servidor de hospedagem | Abaixo de 600 ms |
Legenda: o painel de campo no topo é o que o Google usa para ranquear; o score colorido abaixo vem do laboratório.
--- ## Por que o score muda entre mobile e desktop no mesmo site O PageSpeed Insights testa o mobile com uma conexão 4G lenta simulada e uma CPU 4x mais devagar que o desktop, o que derruba o score em 30 a 50 pontos no mesmo site. O Google ranqueia pelo dado móvel desde a indexação mobile-first, então o número que importa é quase sempre o pior dos dois. Um tema que carrega fontes web bloqueantes e imagens sem lazy-loading sofre muito mais no móvel, onde cada requisição extra custa centenas de milissegundos em conexões reais. Nos tickets de suporte da FULL (150 mil sites), o erro mais comum é otimizar olhando só o desktop verde e ignorar o móvel vermelho, que é exatamente o que o Google mede para posicionamento. A regra prática é simples: se o mobile reprova, o desktop verde não salva o ranqueamento. --- ## Dado de campo versus laboratório: A confusão central do PageSpeed insights A diferença entre dado de campo e dado de laboratório explica 80% das dúvidas sobre o PageSpeed Insights. O laboratório (Lighthouse) roda uma simulação isolada e gera o score de 0 a 100; o campo (Chrome UX Report) coleta a experiência de visitantes reais e decide o "Aprovado nas Core Web Vitals". Quando o painel de campo mostra "Não há dados suficientes", o site tem tráfego baixo demais e o veredicto depende só do laboratório, que tende a inflar o resultado em até 20 pontos versus o usuário real em 4G. De acordo com o HTTP Archive (2024), que rastreia milhões de páginas reais por mês, a mediana de LCP móvel ainda fica acima de 2,5 s na maioria dos sites WordPress. Isso prova que score de laboratório alto não garante campo aprovado. --- ## Passo a passo: Como rodar e ler o PageSpeed insights Rodar o PageSpeed Insights leva menos de um minuto, mas a leitura correta evita semanas otimizando a métrica errada. Em média, sites na base FULL que seguem esta ordem de leitura corrigem o LCP móvel em 3 a 5 ajustes. Siga os passos abaixo na sequência, começando sempre pelo painel de campo móvel antes de tocar em qualquer plugin. ### Passo 1: Acesse a ferramenta e insira a URL Abra o PageSpeed Insights em PageSpeed.web.dev e cole a URL exata da página que você quer testar, não só o domínio raiz. Teste a home, uma página de produto e um post de blog separadamente, porque cada template tem peso e gargalos diferentes. O teste roda em cerca de 15 segundos e retorna mobile e desktop em abas distintas. ### Passo 2: Leia o painel de campo antes do score Olhe primeiro o bloco "Descubra o que seus usuários reais estão sentindo", que traz LCP, INP e CLS de campo. Esse é o dado que o Google usa para ranquear. Se aparecer "Não há dados suficientes", o site tem tráfego baixo e você vai depender do laboratório, que é menos confiável para decisão. ### Passo 3: Identifique a métrica reprovada na aba mobile Na aba mobile, localize qual das três Core Web Vitals está em vermelho ou amarelo. O LCP costuma ser o vilão em WordPress por TTFB alto e imagens grandes. Anote o valor exato, porque a diferença entre 2,8 s e 4,1 s muda completamente a prioridade de correção do LCP. ### Passo 4: Cruze os diagnósticos com causas reais Role até "Diagnóstico" e "Oportunidades". O Lighthouse aponta sintomas como "Reduza o JavaScript não usado", mas a causa raiz costuma estar no TTFB da hospedagem ou na falta de cache de página. Priorize a oportunidade com maior economia de tempo estimada em milissegundos. ### Passo 5: Reteste após cada mudança isolada Aplique uma correção por vez e reteste o PageSpeed Insights antes da próxima. Mudar cache, imagens e JavaScript juntos esconde qual ajuste funcionou. Aguarde 28 dias para o dado de campo refletir a mudança, já que o Chrome UX Report usa uma janela móvel desse período. --- ## As 4 ferramentas que completam o diagnóstico do PageSpeed insights O PageSpeed Insights mostra o quê está lento, mas não o porquê detalhado, e quatro ferramentas reais preenchem essa lacuna. O GTmetrix entrega o waterfall de requisições que revela exatamente qual dos 30 a 80 recursos da página bloqueia a renderização, algo que o PSI resume mas não detalha. O WebPageTest permite testar a partir de servidores em São Paulo com perfis de rede específicos, útil para o público brasileiro real. O Lighthouse rodado direto no Chrome DevTools dá o mesmo motor do PSI com mais controle de throttling de CPU e rede. Já o WP Rocket atua na correção, ativando cache de página, minificação e otimização de assets sem edição de código. Cada ferramenta cobre uma etapa que o PageSpeed Insights sozinho diagnostica mas não resolve, e o uso combinado encurta o ciclo de teste e correção das Core Web Vitals. --- ## Otimização premium gerenciada no bundle da FULL Corrigir as Core Web Vitals do WordPress exige plugins pagos que, comprados avulsos, somam licenças anuais caras: WP Rocket, Perfmatters e otimizadores de imagem facilmente passam de US$150 por ano só em performance. No plano PRO da FULL, por R$849,90, esse bundle premium gerenciado fica ativo em até 10 sites. Isso dá R$85 por site, com cache e otimização já configurados em qualquer hospedagem, sem migrar de servidor. A gente vê no suporte da FULL que a maioria dos sites com score baixo no PageSpeed Insights melhora o LCP só ativando cache de página e lazy-loading corretos. Conheça os planos da FULL e ative a otimização premium sem configurar cada plugin manualmente, página por página, em todos os sites que você gerencia. --- --- ---O mobile é testado com conexão 4G simulada e CPU 4x mais lenta que o desktop, o que derruba o score em 30 a 50 pontos no mesmo site. O Google ranqueia pelo dado móvel desde a indexação mobile-first, então o número que vale para SEO é quase sempre o do mobile. Otimizar olhando só o desktop verde é o erro mais comum nos tickets da FULL.
Sim, mas raramente vale o esforço. Chegar a 100 costuma exigir cortar fontes, scripts e funcionalidades que melhoram a experiência humana. O objetivo correto é o "Aprovado nas Core Web Vitals" de campo, com LCP abaixo de 2,5 s, não o número redondo. Um site com score 85 e campo aprovado ranqueia melhor que um 100 de laboratório sem dado real.
O dado de laboratório vem do Lighthouse, uma simulação isolada que gera o score de 0 a 100. O dado de campo vem do Chrome UX Report, com a experiência de visitantes reais dos últimos 28 dias, e decide o veredicto das Core Web Vitals. O campo é o que o Google usa para ranquear; o laboratório serve para diagnosticar.
No plano PRO da FULL, por R$849,90, o bundle premium de performance fica disponível em até 10 sites, o que dá R$85 por site. Esse valor inclui WP Rocket e outros otimizadores já gerenciados, contra mais de US$150 por ano se comprados avulsos. A ativação funciona em qualquer hospedagem, sem migrar de servidor.
O PageSpeed Insights mede três métricas de campo: LCP (carregamento do maior elemento, meta abaixo de 2,5 s), INP (resposta à interação, meta abaixo de 200 ms) e CLS (estabilidade visual, meta abaixo de 0,1). Ele também mostra o TTFB do servidor, que é a base de tudo. Essas métricas vêm de usuários reais, não da simulação de laboratório.