PageSpeed Insights na prática: como interpretar e corrigir cada métrica

Você abre o PageSpeed Insights, vê nota 34 no mobile, e agora?

A maioria para no número. Fica nervosa, manda o link pro dev e pede “arruma isso”. Mas nota 34 em qual métrica? Causada por quê? Corrigindo o quê, exatamente?

Esse guia resolve isso: cada seção do PSI, o que cada número significa, qual dado conta de verdade pro SEO, e as correções que destravam performance com maior retorno.

O que é o PageSpeed Insights (e como acessar)

PageSpeed Insights é a ferramenta gratuita do Google que analisa performance de páginas web. Acessa em pagespeed.web.dev, cola a URL, aguarda 30 segundos.

O resultado mistura dois tipos de dados completamente diferentes:

Dados de campo (CrUX): coletados de usuários reais do Chrome nos últimos 28 dias
Dados de laboratório (Lighthouse): simulação num ambiente controlado

Essa distinção é fundamental. Muita gente otimiza pra nota do laboratório e esquece que o que conta pro ranking é o campo. São números diferentes, com usos diferentes.

Campo vs. laboratório: a diferença que define tudo

Dados de campo (CrUX)

Aparecem no topo do PSI, antes da nota principal. São os Core Web Vitals reais do site — métricas coletadas de navegadores Chrome de visitantes reais.

Mostram:

LCP real dos seus visitantes (em que condição de conexão eles estão)
INP real das interações (cliques, taps, digitar)
CLS real durante navegação

Esses dados só aparecem se a página tiver volume suficiente de visitas. Site com pouco tráfego pode não ter dados de campo — nesse caso o PSI mostra só laboratório.

Isso é o que importa pro Google Search. O algoritmo usa dados CrUX pra decidir posição, não a nota simulada do Lighthouse.

Dados de laboratório (Lighthouse)

É a nota de 0-100 que aparece em destaque. Simulação feita no servidor do Google, com:

Conexão emulada de 4G (10 Mbps, 40ms de latência)
CPU throttled (6x mais lenta que desktop normal)
Navegação a partir do cache zerado

Útil pra diagnóstico e benchmark. Tem alta reprodutibilidade — roda de novo e o resultado é parecido. Mas não é exatamente o que seus usuários experienciam.

A regra prática: usa campo pra saber se tem problema real. Usa laboratório pra entender o que está causando.

Entendendo a pontuação de 0-100

Faixa	Cor	O que significa
90–100	Verde	Good — sem ação urgente
50–89	Laranja	Needs Improvement — melhoria recomendada
0–49	Vermelho	Poor — problema real

Contexto crítico: nota de laboratório e Core Web Vitals de campo são coisas separadas.

Um site pode ter nota 72 no laboratório mas CrUX “Good” nos Core Web Vitals. Acontece quando o tráfego real vem de usuários em condições melhores que a simulação do PSI.

O inverso também existe: nota 85 no laboratório, CrUX “Poor” no INP. Significa que há interações pesadas que a simulação não capturou — talvez um chat widget que só abre após scroll, ou uma ação de formulário complexa.

Não otimize pra nota. Otimize pra CrUX.

As 6 métricas do laboratório (e os limites)

O PSI mede 6 indicadores no laboratório. Cada um tem peso diferente na composição da nota de 0-100.

Métrica	Peso na nota	Bom	Precisa melhorar	Ruim
FCP (First Contentful Paint)	10%	< 1.8s	1.8–3.0s	> 3.0s
LCP (Largest Contentful Paint)	25%	< 2.5s	2.5–4.0s	> 4.0s
TBT (Total Blocking Time)	30%	< 200ms	200–600ms	> 600ms
CLS (Cumulative Layout Shift)	25%	< 0.1	0.1–0.25	> 0.25
Speed Index	10%	< 3.4s	3.4–5.8s	> 5.8s
INP (Interaction to Next Paint)	campo	< 200ms	200–500ms	> 500ms

INP não entra diretamente na nota do laboratório — é medido no campo. Mas o PSI exibe separado, acima das métricas de lab.

TBT é o proxy do INP no laboratório. TBT alto = JavaScript pesado bloqueando o main thread = INP alto no campo. São a mesma causa raiz vista de ângulos diferentes.

FCP — Primeira pintura de conteúdo

Quando o primeiro pixel de conteúdo aparece: texto, imagem, qualquer elemento. Antes disso, o usuário vê tela branca.

Peso baixo na nota (10%), mas afeta percepção imediata. Usuário que fica 3s vendo tela em branco abandona antes de qualquer coisa ranquear.

LCP — Conteúdo principal

Quando o maior elemento visível carrega: hero image, H1 grande, vídeo com poster. Pra o Google, é o momento em que a página ficou “utilizável”.

Peso 25% na nota e fator direto de ranqueamento via Core Web Vitals. Detalhe técnico importante: o Google mede o LCP do campo, não do laboratório. Mas os dois são altamente correlacionados.

TBT — Tempo total bloqueado

Soma de milissegundos em que o main thread ficou travado por tarefas JavaScript longas (acima de 50ms cada). Se o browser está executando um script, o usuário não consegue interagir — clique, tap, digitação, nada.

Peso 30% da nota — é o mais pesado de todos. Se a nota do PSI está no vermelho, provavelmente é TBT empurrando pra baixo. Principais culpados: GTM com muitas tags, pixel Meta client-side, chat widgets, plugins WordPress.

CLS — Deslocamento de layout cumulativo

Quanto elementos visuais “pulam” enquanto a página carrega. Imagem sem tamanho declarado aparece e empurra o texto pra baixo. Anúncio carrega depois e desloca o botão que o usuário estava prestes a clicar.

Peso 25% na nota e fator de ranking. É o mais fácil de corrigir tecnicamente — quase sempre é só declarar width e height em imagens.

Speed Index

Mede velocidade geral de carregamento visual — quão rápido o conteúdo vai aparecendo progressivamente. Peso 10%. Melhora automaticamente quando você melhora FCP e LCP; raramente precisa de ação separada.

Oportunidades, diagnósticos e aprovados

Abaixo das métricas, o PSI agrupa as sugestões em 3 categorias. Entender a diferença evita trabalho em itens errados.

Oportunidades

São melhorias com impacto estimado em segundos de ganho. O PSI calcula quanto cada problema está custando. Ordenadas do maior pro menor impacto.

As mais frequentes:

“Eliminar recursos que bloqueiam renderização” Scripts ou CSS na <head> que travam o carregamento antes de qualquer conteúdo aparecer. Correção: defer ou async em scripts não-críticos; inline do CSS above-the-fold.

“Adiar imagens fora da tela” Imagens abaixo da dobra carregando imediatamente, concorrendo com o conteúdo visível. Correção: loading="lazy" em toda <img> que não está above the fold.

“Codificar imagens com eficiência” Imagens JPEG/PNG servidas onde WebP ou AVIF dariam 30-50% a menos de bytes. Correção: converte com Squoosh, Cloudinary com transformação automática, ou Astro Image.

“Servir imagens no tamanho correto” Imagem de 2400px servida num container de 400px. O browser baixa os 2400px e descarta 80%. Correção: srcset com múltiplas resoluções ou ferramenta de CDN com transformação responsiva.

“Reduzir o tempo de resposta inicial do servidor” Servidor respondendo devagar antes de mandar qualquer byte (TTFB alto). Correção: CDN, cache de página, otimização de queries.

Diagnósticos

Itens sem estimativa de ganho em segundos, mas que são problemas técnicos reais:

Muitos scripts de terceiros
Política de cache inadequada nos assets
JavaScript não minificado
DOM com mais de 1.500 elementos
Fontes não pré-carregadas com preload

Diagnósticos não têm número de segundos, mas resolvê-los melhora a nota de forma consistente ao longo do tempo.

Aprovados

O que já está correto. Lê uma vez pra entender o que não precisa tocar, e ignora daqui em diante.

Como corrigir as 5 oportunidades mais comuns

1. Imagens não otimizadas

Regra de ouro: toda imagem serve em WebP ou AVIF, dimensões declaradas no HTML, loading="lazy" abaixo da dobra, loading="eager" fetchpriority="high" na hero.

<!-- Hero image: carrega primeiro, prioridade máxima -->
<img src="hero.webp" width="1200" height="600" loading="eager" fetchpriority="high" alt="Descrição">

<!-- Demais imagens: lazy -->
<img src="produto.webp" width="400" height="300" loading="lazy" alt="Produto X">

Ganho típico: 1–3 segundos no LCP. É a otimização com maior ROI de esforço.

2. JavaScript pesado (TBT alto)

Scripts de terceiros são os maiores vilões do TBT. Cada um adiciona 50–300ms de bloqueio ao main thread.

Ação prática:

Audita o GTM: remove tags inativas, consolida tags duplicadas. Acima de 15 tags começa a pesar sistematicamente
Carrega scripts não-críticos com defer ou via IntersectionObserver (dispara só quando o usuário rola)
Substitui Pixel Meta client-side por Conversions API server-side — reduz ~100ms de TBT e melhora qualidade de dados

3. Recursos bloqueando renderização (FCP alto)

CSS e JS na <head> bloqueiam o browser de renderizar qualquer coisa até terminarem de baixar e executar.

CSS crítico (above the fold): inline direto no <head>
CSS não-crítico: <link rel="preload" as="style" onload="this.rel='stylesheet'">
Scripts de analytics e pixels: defer sempre

4. TTFB alto — servidor lento

Se o servidor demora mais de 800ms pra mandar o primeiro byte, as outras otimizações têm impacto limitado. É como ajustar motor de carro com o cano de combustível entupido.

No PSI, vê “Initial server response time” em Diagnósticos.

Soluções:

CDN: Cloudflare, Vercel, Netlify servem HTML de edge servers próximos do usuário. TTFB cai de 1.5s pra 80–150ms
Cache de página: WordPress com WP Rocket ou LiteSpeed Cache; Next.js com ISR; Astro com assets estáticos no CDN
Banco de dados: queries N+1 sem índice são a causa mais comum de TTFB alto em sites com CMS

5. CLS — layout pulando

O mais simples de resolver. Causas quase sempre são as mesmas:

<!-- Toda imagem precisa de width e height — mesmo as responsivas -->
<img src="foto.webp" width="800" height="600" alt="...">

<!-- Container de embed com aspect-ratio reservado antes de carregar -->
<div style="aspect-ratio: 16/9;">
  <iframe src="..."></iframe>
</div>

Banners de cookie, chat widgets que aparecem depois: dá min-height pro container antes do elemento carregar. O browser já reserva o espaço e o conteúdo não pula.

Desktop vs. mobile: qual nota importa mais

Mobile primeiro, sem discussão.

O Google usa mobile-first indexing desde 2019. O ranking é determinado pela versão mobile do seu site. Não existe “mas meu público é desktop” como justificativa pra ignorar mobile — o Google ranqueia pelo mobile e exibe pra todo mundo.

Padrão que vemos com frequência em clientes novos: nota 87 no desktop, nota 41 no mobile. O negócio só olhava desktop porque “parece rápido no computador”.

Estava ranqueando pela pior versão, sem saber.

Prioridade de atenção:

Mobile — define posição orgânica
Desktop — afeta conversão dos usuários que chegam por desktop (pode ser maioria em B2B)

Como acompanhar evolução ao longo do tempo

O PSI é uma foto do momento. Pra acompanhar tendência:

Search Console → Experiência → Core Web Vitals Gráfico histórico de 90 dias. Mostra proporção de URLs em Good / Needs Improvement / Poor com dados de campo reais. Esse é o painel que reflete o que o Google está vendo.

CrUX History API Pra quem tem dev na equipe, a API do CrUX retorna dados históricos por URL. Integra num dashboard Looker Studio e vira relatório automático.

Configuração mínima recomendada: PSI a cada deploy significativo + Search Console toda semana.

Após correções, espera 14–28 dias pra ver reflexo nos dados de campo do Search Console. CrUX é média móvel de 28 dias — as melhorias não aparecem amanhã.

Plano de ação por faixa de nota

Nota 0–49 (vermelho) — emergência

Problema real afetando ranking agora. Ação em 30 dias.

Otimiza imagens: WebP, lazy loading, dimensões declaradas
Audita e reduz scripts de terceiros no GTM
Verifica TTFB — se acima de 1.5s, muda hospedagem ou ativa CDN
Corrige CLS: width/height em todas as imagens

Nota 50–89 (laranja) — melhoria programada

Não é emergência, mas há ganho real disponível. Ação em 60–90 dias.

Identifica as 3 Oportunidades com maior ganho estimado no PSI
Corrige em ordem decrescente de impacto
Se TBT > 400ms, auditoria de JavaScript é prioridade

Nota 90–100 (verde) — manutenção

Não mexe em nada por causa de performance. Foca em conteúdo, backlinks e estrutura de schema markup. Roda PSI de novo só após mudanças grandes no site.

A regra que simplifica tudo

Olha o PSI como médico olha exame de sangue. Não é o número absoluto que importa — é o que está fora do intervalo e por quê.

Site de mídia carregado de anúncios pode ter nota 42 no laboratório, mas CrUX “Good” porque os usuários reais têm conexão decente. Nota baixa, SEO funcionando.

Site institucional com nota 78 pode ter INP de 450ms no campo porque um script de formulário está travando interação. Nota “aceitável”, SEO sofrendo.

Hierarquia de atenção que usamos:

CrUX de campo (Core Web Vitals) — o que o Google mede de verdade
TBT de laboratório — proxy mais confiável pro INP
LCP de laboratório — altamente correlacionado com LCP real
CLS de laboratório — muito próximo do campo
Nota geral — útil como benchmark, não como meta

Pra se aprofundar nos Core Web Vitals e entender o que cada métrica significa além do PSI, veja o guia completo de Core Web Vitals e INP em 2026. Se quiser checar como performance se encaixa numa estratégia mais ampla, o checklist de SEO técnico em 2026 cobre todos os 12 ajustes que mais retornam. E pra uma visão 360° do estado do site, a auditoria completa de SEO tem os 50 pontos que verificamos antes de tocar em qualquer cliente.

Quer uma análise do PageSpeed Insights do seu site com plano de correção priorizado por impacto? Fala com a gente — diagnóstico em 48 horas.