PageSpeed: como ler e otimizar no WordPress

PageSpeed é a métrica de performance que o Google usa para avaliar a experiência real de carregamento de uma página, medida pela ferramenta PageSpeed Insights com base em três Core Web Vitals: LCP, INP e CLS. Desde 2024, a antiga pontuação genérica de 0 a 100 deu lugar a um diagnóstico duplo, que combina dados de campo (usuários reais) com dados de laboratório (simulação Lighthouse).

Se você gerencia um site WordPress corporativo, conhece bem a cena: a campanha está pronta, o conteúdo foi publicado por três editores diferentes, mas o site demora para carregar e o relatório do PageSpeed aponta uma lista de problemas que ninguém sabe priorizar. Pior: você roda o teste duas vezes seguidas e recebe notas diferentes. A pergunta que fica é simples. O que realmente impacta o ranqueamento e a experiência do usuário, e o que é ruído?

Neste guia, vamos destravar essa leitura. Você vai entender o que o PageSpeed mede hoje, como interpretar dados de campo e de laboratório e, principalmente, como otimizar cada métrica em um ambiente WordPress de produção sem depender de adivinhação.

O que é o PageSpeed Insights e por que ele mudou?

O PageSpeed Insights é a ferramenta gratuita do Google que mede a performance de uma página combinando dados reais de usuários do Chrome com uma simulação de laboratório. O objetivo dela é responder uma pergunta prática: a experiência de carregamento do seu site é boa o suficiente para quem acessa?

Até 2020, o PageSpeed entregava uma única pontuação de velocidade, de 0 a 100, sem explicar muito de onde ela vinha. Era um número fácil de mostrar em reunião, mas pobre para tomar decisão técnica. Esse modelo acabou.

Hoje a ferramenta roda sobre o Lighthouse v10 ou superior e organiza o diagnóstico em torno dos Core Web Vitals (web.dev), um conjunto de métricas que o Google criou para medir experiência real, não velocidade abstrata. A mudança mais recente aconteceu em março de 2024, quando o Google substituiu a antiga métrica FID pelo INP (Interaction to Next Paint) como métrica oficial de responsividade, segundo a documentação oficial do INP.

Por que isso muda tudo para quem trabalha com WordPress? Porque o WordPress monta páginas dinamicamente, carrega plugins de terceiros e injeta scripts de chat, formulários e sliders. Cada um desses elementos afeta diretamente uma das três métricas. Otimizar o PageSpeed no WordPress deixou de ser só sobre comprimir imagens e passou a ser sobre controlar o que cada plugin faz com a thread principal do navegador.

O Google trata performance como sinal de ranqueamento desde a atualização de experiência de página, e os Core Web Vitals fazem parte desse conjunto de sinais. Não é o único fator, mas é um dos poucos que você controla diretamente com decisões de engenharia e infraestrutura.

Quais métricas o PageSpeed avalia hoje?

O relatório atual gira em torno de cinco métricas principais. Três delas são Core Web Vitals (LCP, INP e CLS) e duas são métricas de suporte que ajudam a explicar a causa (TTFB e FCP). Vamos a cada uma.

LCP (Largest Contentful Paint)

O LCP mede o tempo até o maior elemento visível da página ser renderizado, geralmente uma imagem de destaque ou um bloco de texto grande. É o indicador de quão rápido o usuário percebe que o conteúdo principal carregou. Um LCP bom fica em até 2,5 segundos, segundo o Google. No WordPress, a causa mais comum de LCP alto é uma imagem hero pesada sem prioridade de carregamento, somada a um TTFB elevado por hospedagem compartilhada.

INP (Interaction to Next Paint)

O INP mede o tempo de resposta entre uma interação do usuário (clique, toque, digitação) e a próxima atualização visual da tela. É a métrica que substituiu o FID e a mais sensível ao JavaScript. Um INP bom fica em até 200 milissegundos. Em sites WordPress, o INP costuma sofrer com scripts de plugins que bloqueiam a thread principal: sliders, formulários complexos, widgets de chat e ferramentas de analytics carregadas de forma síncrona.

CLS (Cumulative Layout Shift)

O CLS mede a estabilidade visual da página, ou seja, o quanto os elementos pulam de lugar enquanto o conteúdo carrega. Quem nunca tentou clicar em um botão e ele se moveu no último instante? Um CLS bom fica em até 0,1. As causas clássicas no WordPress são imagens sem atributos de largura e altura definidos, fontes web carregadas sem controle de exibição e anúncios injetados que empurram o conteúdo.

TTFB (Time to First Byte)

O TTFB mede o tempo entre a requisição e o primeiro byte de resposta do servidor. Não é um Core Web Vital, mas é a fundação de tudo: se o TTFB é alto, o LCP nunca será bom. Um TTFB saudável fica em até 800 milissegundos. No WordPress, ele dispara quando não há cache de página, quando existem queries pesadas na tabela wp_options ou quando falta uma camada de cache na borda.

FCP (First Contentful Paint)

O FCP mede quando o primeiro conteúdo (qualquer texto ou imagem) aparece na tela. Um FCP bom fica em até 1,8 segundo. CSS que bloqueia a renderização e fontes carregadas sem preload são os culpados mais frequentes em temas WordPress.

Como ler dados de campo e de laboratório sem se confundir?

Esse é o ponto que quase ninguém explica direito, e é justamente o que faz você rodar o teste duas vezes e receber notas diferentes. O PageSpeed Insights mostra dois conjuntos de dados completamente distintos na mesma tela.

Os dados de campo vêm do Chrome User Experience Report (CrUX), uma base que coleta a experiência real de usuários do Chrome nos últimos 28 dias. É o que aparece no topo do relatório, com os badges de aprovado ou reprovado nos Core Web Vitals. Esse é o dado que importa para o Google, porque reflete pessoas de verdade, em dispositivos e conexões reais.

Os dados de laboratório vêm do Lighthouse, que simula um único carregamento em um ambiente controlado, com um dispositivo móvel intermediário e uma conexão limitada. É de onde sai a famosa nota de 0 a 100 e a lista de oportunidades de melhoria. Esse dado é ótimo para diagnosticar a causa, mas é uma simulação. Por isso ele varia a cada execução.

A regra prática é direta: use os dados de campo (CrUX) para saber se você tem um problema real e use os dados de laboratório (Lighthouse) para descobrir como resolvê-lo. Um erro comum em times de marketing é perseguir a nota verde do laboratório enquanto os dados de campo continuam reprovados. A nota não paga as contas, a experiência real do usuário paga.

Vale uma ressalva. Sites com pouco tráfego podem não ter dados de campo suficientes no CrUX. Nesses casos, o PageSpeed mostra apenas os dados de laboratório, e você precisa monitorar a experiência real por outros caminhos, como o relatório de Core Web Vitals do Google Search Console.

Como otimizar o PageSpeed no WordPress na prática?

Aqui está o que move o ponteiro de verdade. Em vez de uma lista genérica, vamos atacar cada métrica pela causa mais comum no WordPress. Antes de qualquer ação, o passo zero é sempre auditar o site para identificar os problemas reais, e não os imaginados. Vale complementar com a documentação de performance da MDN quando o time precisar aprofundar em conceitos de front-end.

Corrigindo LCP: hero image, preload e TTFB

O maior vilão do LCP costuma ser a imagem principal. Sirva imagens em formato WebP ou AVIF, defina sempre largura e altura no HTML para evitar deslocamento de layout e aplique o atributo fetchpriority="high" na imagem hero acima da dobra. Isso instrui o navegador a baixar essa imagem antes de tudo, reduzindo o LCP. O lazy loading deve ser usado nas imagens abaixo da dobra, nunca na principal. Se o TTFB estiver alto, nenhuma otimização de imagem vai salvar o LCP, então trate o servidor primeiro.

Corrigindo INP: JavaScript e thread principal

Carregue scripts de terceiros (chat, analytics, pixels) de forma assíncrona ou adiada. Remova plugins que injetam JavaScript em todas as páginas mesmo onde não são usados. Cada script bloqueante na thread principal aumenta o INP. Menos é mais aqui. Em sites corporativos, vale mapear quais plugins realmente precisam rodar em cada tipo de página, em vez de deixar tudo carregando globalmente.

Corrigindo CLS: dimensões, fontes e anúncios

Defina width e height em todas as imagens e reserve espaço para banners e anúncios antes de eles carregarem. Para as fontes, use font-display: swap e faça preload das fontes críticas. Isso evita o texto invisível durante o carregamento e reduz tanto o FCP quanto o CLS. Anúncios injetados sem espaço reservado são a causa mais frequente de CLS ruim em portais de conteúdo.

A tabela abaixo resume os thresholds oficiais de cada métrica e a causa mais comum no WordPress, para você priorizar a ação certa.

Os thresholds acima seguem os valores publicados pelo web.dev, referência oficial do Google para Core Web Vitals.

Quais erros comuns matam o pagespeed em sites WordPress corporativos?

Depois de analisar performance de muitos projetos aqui na Apiki, percebemos que os problemas mais graves de pagespeed em sites enterprise raramente estão nas imagens. Eles estão na infraestrutura e na forma como os plugins foram empilhados ao longo do tempo. Alguns padrões se repetem.

• Cache mal configurado ou ausente: muitos sites rodam sem cache de página, reconstruindo o HTML a cada visita. Isso mantém o TTFB alto de forma crônica e sabota o LCP, por mais que o front-end esteja otimizado.
• Plugins de otimização brigando entre si: é comum encontrar dois ou três plugins de performance ativos ao mesmo tempo, cada um tentando minificar e combinar os mesmos arquivos. O resultado é conflito, CSS quebrado e ganho zero de pagespeed.
• Ausência de cache de borda (edge): sem servir o conteúdo a partir do ponto de presença mais próximo do usuário, o TTFB varia muito conforme a localização de quem acessa. Para audiências distribuídas, isso derruba a média dos dados de campo.
• Banco de dados inchado: tabelas grandes, autoloads desnecessários na wp_options e plugins que rodam queries pesadas a cada requisição elevam o TTFB silenciosamente, sem aparecer em nenhuma auditoria de front-end.
• Otimizar só o laboratório: o time persegue a nota verde do Lighthouse, comemora e esquece de olhar os dados de campo, que continuam reprovados no CrUX. É o erro mais caro, porque consome esforço sem melhorar ranqueamento.

O ponto em comum é que a maioria desses problemas nasce na camada de infraestrutura, não no conteúdo. E é aí que a decisão de onde hospedar o site pesa mais do que qualquer plugin instalado depois.

Perguntas frequentes sobre pagespeed

Qual nota do PageSpeed é considerada boa?

Uma nota de laboratório acima de 90 (verde) é considerada boa no PageSpeed Insights, mas o que realmente importa é passar nos Core Web Vitals com dados de campo. Um site pode ter nota 85 no laboratório e ainda assim ser aprovado pelo Google se o LCP, o INP e o CLS reais estiverem dentro dos limites recomendados.

Por que o PageSpeed Insights mostra notas diferentes a cada teste?

Porque a nota de laboratório vem do Lighthouse, que simula um único carregamento em condições controladas de dispositivo e rede. Pequenas variações de servidor, rede e scripts de terceiros mudam o resultado a cada execução. Os dados de campo, ao contrário, são estáveis, porque representam a média de milhares de acessos reais nos últimos 28 dias.

O PageSpeed Insights afeta o ranqueamento no Google?

Sim, de forma indireta. O que ranqueia são os Core Web Vitals medidos com dados de campo reais, que fazem parte dos sinais de experiência de página do Google. O PageSpeed Insights é a ferramenta que mostra esses dados, mas não é a nota do laboratório que influencia o ranqueamento, e sim a experiência real dos usuários.

Plugin de cache resolve o pagespeed no WordPress?

Um plugin de cache ajuda, principalmente no TTFB e no LCP, mas dificilmente resolve tudo sozinho. Ele não corrige JavaScript pesado de plugins de terceiros (que afeta o INP) nem substitui uma camada de cache de borda. O melhor resultado vem da combinação de cache na infraestrutura, otimização de front-end e uma stack limpa de plugins.

Qual a diferença entre PageSpeed Insights e GTmetrix?

O PageSpeed Insights usa dados de campo reais do CrUX, que são exatamente os que o Google considera para ranqueamento. O GTmetrix é uma ferramenta de laboratório que testa a partir de servidores específicos e oferece bom detalhamento de cascata de carregamento. Para saber se você tem um problema real de experiência, priorize os dados de campo do PageSpeed. Para diagnosticar a causa, ambos ajudam.

Site sem dados de campo no CrUX é problema?

Não é um problema, mas exige cuidado. Sites com pouco tráfego não atingem o volume mínimo para o CrUX gerar dados de campo, então o PageSpeed mostra só o laboratório. Nesses casos, use o relatório de Core Web Vitals do Google Search Console e monitore a experiência real conforme o tráfego cresce.

Quanto tempo leva para otimizar Core Web Vitals no WordPress?

Correções de front-end (imagens, fontes, scripts) costumam mostrar efeito no laboratório em dias. Já os dados de campo do CrUX levam de 3 a 4 semanas para refletir as mudanças, porque a base usa uma janela móvel de 28 dias. Ou seja, você otimiza hoje, mas só confirma o ganho no ranqueamento algumas semanas depois.

Conclusão

Ler o PageSpeed Insights corretamente é menos sobre perseguir a nota verde e mais sobre entender o que os dados de campo dizem sobre a experiência real de quem acessa o seu site. Priorize os Core Web Vitals medidos no CrUX, use o laboratório para diagnosticar a causa e ataque cada métrica pelo gargalo mais provável no WordPress: TTFB no servidor, JavaScript nos plugins e estabilidade no front-end.

Na prática, boa parte do que determina o pagespeed acontece antes de qualquer plugin: no servidor, no cache de página e no cache de borda. Um TTFB baixo, uma camada de edge cache bem configurada e monitoramento contínuo são a fundação de qualquer otimização sustentável. Sem isso, cada ajuste de front-end trabalha contra a corrente.

É exatamente esse trabalho de base que a nossa hospedagem WordPress gerenciada resolve para você. Cuidamos da infraestrutura que sustenta os Core Web Vitals, com cache de borda, TTFB otimizado e acompanhamento de performance, para que o seu time foque em publicar conteúdo e rodar campanhas, sem depender de adivinhação a cada relatório de pagespeed. Fale com o nosso time e descubra como escalar performance no WordPress com previsibilidade.