O Google PageSpeed Insights é a ferramenta de performance mais citada em conversas com clientes — e uma das mais mal interpretadas. Um score de 45 no mobile não significa que o site está "partido". Um score de 98 não significa que está "perfeito". Este guia explica o que o PSI realmente mede e onde focar esforço de optimização em WordPress.
A diferença fundamental: dados de laboratório vs dados de campo
O PageSpeed Insights mostra duas secções distintas que muita gente não distingue:
Dados de Campo (Field Data / CrUX)
Dados reais recolhidos de utilizadores Chrome nos últimos 28 dias. Incluem as métricas Core Web Vitals (LCP, INP, CLS) com distribuição de percentis. Estes são os dados que a Google usa para ranking. Se não houver dados suficientes (sites com pouco tráfego), esta secção pode estar vazia.
Dados de Laboratório (Lab Data)
Simulação em condições controladas usando Lighthouse — CPU throttled (4x), ligação de rede simulada (4G lento), Chrome headless. É aqui que aparece o score numérico (0-100). Este score NÃO é directamente usado pela Google para ranking. É uma simulação útil para diagnóstico, mas pode diferir significativamente da experiência real dos utilizadores.
Um site WordPress com muitos utilizadores em dispositivos recentes e boa ligação pode ter dados de campo excelentes e score de laboratório médio — e isso é completamente normal.
O que significa o score de 0-100
O score Lighthouse é uma média ponderada de várias métricas de laboratório:
- LCP (Largest Contentful Paint): 25% do score
- TBT (Total Blocking Time): 30% do score — proxy para INP em laboratório
- CLS (Cumulative Layout Shift): 15% do score
- FCP (First Contentful Paint): 10% do score
- Speed Index: 10% do score
- TTI (Time to Interactive): 10% do score
O TBT (30% do score) mede JavaScript que bloqueia o thread principal — o que explica porque sites WordPress com muitos plugins JavaScript têm scores baixos no mobile mesmo quando parecem rápidos num browser desktop.
Porque o score mobile é sempre mais baixo em WordPress
O Lighthouse no mobile simula um dispositivo de gama média com CPU 4x mais lenta que desktop. Plugins WordPress com JavaScript pesado (page builders, sliders, chat widgets, scripts de marketing) têm impacto muito maior em condições de CPU lenta.
É comum e normal um site WordPress ter score de 90+ no desktop e 50-70 no mobile. O objectivo não é um score de 100 — é dados de campo verdes nos Core Web Vitals. Um site com score de 65 no Lighthouse mas dados de campo com LCP de 1,8s e INP de 180ms está em boa forma.
Diagnóstico: as oportunidades com maior impacto
O PSI lista oportunidades de melhoria com estimativa de poupança de tempo. Em WordPress, as oportunidades com maior ROI são:
1. Eliminar recursos que bloqueiam a renderização
CSS e JavaScript no <head> que atrasam o primeiro render. Solução: defer JavaScript não crítico, carregar CSS crítico inline. WP Rocket, LiteSpeed Cache e Perfmatters têm opções para isto.
2. Servir imagens em formatos de próxima geração
Imagens em JPEG ou PNG em vez de WebP ou AVIF. O WordPress 5.8+ suporta WebP nativamente. Plugins como ShortPixel ou Imagify convertem automaticamente. Esta optimização pode reduzir o peso das imagens em 30-50%.
3. Adiar JavaScript não utilizado
JavaScript carregado mas não executado na página inicial. Frequentemente causado por plugins com scripts globais (gateways de pagamento, builders, scripts de tracking).
4. Reduzir o tempo de resposta inicial do servidor
TTFB alto. Resolução: page cache (reduz de 500-2000ms para 50-200ms), object cache, hosting adequado. Ver artigo sobre configurar cache WordPress.
5. Dimensionar imagens correctamente
Servir imagens maiores do que o necessário para o tamanho de ecrã. WordPress gera tamanhos de imagem automáticos — garantir que os temas usam os tamanhos correctos via srcset.
Priorização: o que optimizar primeiro
Nem todas as oportunidades têm o mesmo impacto. A sequência recomendada para a maioria dos sites WordPress:
- Page cache — elimina o TTFB alto, que afecta todas as métricas subsequentes
- Optimização de imagens — impacto directo no LCP e no peso total da página
- Preload da imagem LCP — reduz o LCP directamente
- Defer de JavaScript — reduz TBT e melhora INP
- Dimensões nas imagens — elimina CLS
Fazer tudo ao mesmo tempo não é necessário. Actuar nos primeiros 2-3 pontos cobre tipicamente 80% do impacto possível.
Quer que auditemos a performance dos sites dos seus clientes?
O nosso serviço de monitorização 24/7 inclui tracking de performance com alertas quando os scores ou os Core Web Vitals degradam.
Monitorizar performance WordPress