PageSpeed é o termo usado para se referir à velocidade de carregamento de um site — e, mais especificamente, ao Google PageSpeed Insights, a ferramenta gratuita do Google que mede esse desempenho e dá uma nota de 0 a 100. Quanto mais rápido o site, melhor a experiência do usuário e melhores as chances de ranquear bem no Google.
Se você quer entender o que é o PageSpeed, o que significa aquela nota, quais métricas realmente importam atualmente e — o mais importante — como melhorar a pontuação do seu site na prática, este guia cobre tudo, do conceito básico às otimizações técnicas que movem o ponteiro de verdade.
Conteúdo
O que é o PageSpeed?
A palavra “PageSpeed” tem dois sentidos que vale separar.
No sentido amplo, page speed (velocidade de página) é simplesmente o tempo que o seu site leva para carregar e ficar utilizável para o visitante. É um conceito de desempenho.
No sentido mais comum das buscas, “PageSpeed” se refere ao Google PageSpeed Insights (também chamado de PSI), a ferramenta gratuita do Google que analisa qualquer página e devolve uma nota de 0 a 100, além de um relatório detalhado com o que está pesando no carregamento e como corrigir. É nesse segundo sentido que a maioria das pessoas usa o termo — e é nele que este guia foca.
Vale conhecer também o Lighthouse: é o mecanismo open source do Google que roda por trás do PageSpeed Insights. Quando você analisa uma página no PSI, é o Lighthouse que faz a medição em laboratório. O mesmo motor está disponível dentro do Chrome DevTools, então você pode rodar a mesma análise direto no navegador.
Por que o PageSpeed importa (e muito)
A velocidade do site não é vaidade técnica — ela afeta diretamente dois pilares do seu negócio: ranqueamento e conversão.
Do lado do SEO, a velocidade é fator de ranqueamento confirmado pelo Google desde 2010, e desde 2021 as Core Web Vitals (que veremos a seguir) fazem parte oficial dos sinais de Page Experience. Entre duas páginas com conteúdo de qualidade semelhante, a mais rápida tende a ranquear melhor.
Do lado da conversão, o impacto é direto e mensurável. Estudos clássicos do setor mostram que cada segundo a mais de carregamento derruba as conversões, e que a maioria dos usuários abandona uma página que demora mais do que alguns segundos para abrir. Um teste A/B famoso da Vodafone Itália mostrou que uma melhora de 31% no LCP gerou 8% mais vendas. Site lento é, na prática, dinheiro vazando silenciosamente.
Em um teste A/B da Vodafone Itália, uma melhora de 31% no LCP resultou em 8% mais vendas — em páginas idênticas, mudando apenas a velocidade. Velocidade não é detalhe técnico: é variável de receita.
Como o PageSpeed Insights calcula a nota
Aqui está um ponto que quase nenhum artigo brasileiro explica bem, e que é essencial para usar a ferramenta corretamente: o PageSpeed Insights mostra dois tipos de dados, e eles significam coisas diferentes.
Os dados de campo (field data) vêm de usuários reais que visitaram o seu site nos últimos 28 dias, coletados pelo Chrome User Experience Report (CrUX). É a experiência real do seu público — e é isso que o Google usa para ranqueamento.
A limitação: só aparece se o seu site tiver tráfego suficiente para gerar dados. Vale lembrar que esses mesmos dados de campo aparecem também no Google Search Console, no relatório de Core Web Vitals — com uma vantagem: lá você vê o desempenho de todas as páginas do site de uma vez, agrupadas por status, em vez de analisar uma URL por vez como no PageSpeed Insights.
Os dados de laboratório (lab data) vêm de uma simulação que o Lighthouse roda na hora, num ambiente controlado. É o que gera aquela nota de 0 a 100. Serve para diagnosticar e testar melhorias na hora, mas é uma simulação — não a experiência real dos seus visitantes.
A distinção é crucial: a nota de 0 a 100 é dado de laboratório (diagnóstico), enquanto o que de fato conta para o Google são as Core Web Vitals medidas em campo. Um site pode ter nota 100 no laboratório e ainda assim falhar nas Core Web Vitals de campo, ou o contrário. Use a nota para diagnosticar, mas mire nas métricas de campo.
As Core Web Vitals: as métricas que realmente importam em 2026
As Core Web Vitals são o conjunto de três métricas com que o Google mede a experiência real do usuário. São elas que entram no ranqueamento, então são a sua prioridade.
Atenção a um ponto que a maioria dos artigos em português ainda erra: até março de 2024, uma das métricas era o FID (First Input Delay). O Google aposentou o FID e o substituiu pelo INP (Interaction to Next Paint). Se você leu em algum lugar que precisa otimizar o FID, essa informação está desatualizada — hoje a métrica é o INP. As três Core Web Vitals atuais são:
LCP (Largest Contentful Paint) — mede a velocidade de carregamento: quanto tempo leva para o maior elemento visível da tela (normalmente a imagem principal ou um bloco grande de texto) aparecer. Bom: até 2,5 segundos.
INP (Interaction to Next Paint) — mede a responsividade: quão rápido a página responde às interações do usuário (cliques, toques) ao longo de toda a visita. Substituiu o FID em 2024 e é mais rigoroso, porque mede a interação inteira, não só o atraso inicial. Bom: até 200 milissegundos. É hoje a métrica que mais sites falham.
CLS (Cumulative Layout Shift) — mede a estabilidade visual: o quanto os elementos “pulam” na tela enquanto a página carrega (aquele momento em que você vai clicar e o botão se move). Bom: até 0,1.
Um detalhe importante sobre como o Google avalia: para “passar” em uma métrica, pelo menos 75% dos acessos precisam atingir o limite “bom”. E as três precisam passar ao mesmo tempo — um site com INP e CLS ótimos mas LCP ruim falha na avaliação geral.
Além das três Core Web Vitals, você verá no relatório duas métricas de diagnóstico que as influenciam: o FCP (First Contentful Paint), que marca quando o primeiro conteúdo aparece, e o TTFB (Time to First Byte), que mede quanto tempo o servidor leva para começar a responder — e que, como veremos, depende diretamente da sua hospedagem.
Como usar o Google PageSpeed Insights passo a passo
Usar a ferramenta é simples. Acesse pagespeed.web.dev, cole a URL da página que quer analisar e clique em “Analisar”. Em alguns segundos, o relatório aparece.
Ao ler o relatório, observe nesta ordem: primeiro os dados de campo no topo (a experiência real, se houver), depois a nota e as Core Web Vitals de laboratório, e então as duas seções mais úteis para agir — “Oportunidades” (o que pode acelerar a página, com a estimativa de segundos economizados) e “Diagnóstico” (detalhes técnicos do que está pesando). Analise tanto a aba mobile quanto a desktop, porque o Google usa indexação mobile-first — a versão mobile é a que mais importa.
Ferramentas complementares ao PageSpeed
O PageSpeed Insights é o ponto de partida, mas não precisa ser a única ferramenta. Cada uma das opções abaixo cobre um ângulo diferente do desempenho, e usá-las em conjunto dá o quadro completo.
Google PageSpeed Insights é a base: reúne os dados de campo (usuários reais) e os de laboratório (a nota) numa tela só, página por página. Use-o para o diagnóstico inicial de uma URL específica.
Lighthouse / Chrome DevTools é o mesmo motor do PSI, mas rodando localmente no seu navegador (aba “Lighthouse” do DevTools, com F12). É ideal para testar melhorias na hora, sem precisar publicar e reanalisar — você ajusta, roda de novo e vê o efeito imediatamente.
Google Search Console mostra o relatório de Core Web Vitals de todas as páginas do seu site de uma vez, com dados de campo reais, agrupadas por status (boa, a melhorar, ruim). Enquanto o PSI analisa uma URL por vez, o Search Console é a visão panorâmica — essencial para quem tem muitas páginas e quer saber onde focar o esforço.
GTmetrix e WebPageTest detalham o gráfico de cascata (waterfall): a ordem e o tempo em que cada recurso da página carrega. São as melhores ferramentas para diagnóstico técnico profundo, quando você precisa descobrir exatamente qual arquivo está atrasando o carregamento.
Na prática, o fluxo ideal é: diagnostique com o PageSpeed Insights, acompanhe o site inteiro pelo Search Console, itere as correções com o Lighthouse, e investigue os casos difíceis com o GTmetrix ou o WebPageTest.
Como melhorar a pontuação do PageSpeed (na prática)
Aqui está o que de fato move o ponteiro, organizado por métrica e por impacto. A lógica é simples: descubra qual das três Core Web Vitals está ruim e ataque as causas dela.
Para melhorar o LCP (carregamento)
O LCP quase sempre é limitado pela imagem principal ou pela lentidão do servidor. As ações de maior impacto:
Otimize as imagens. Comprima e redimensione as imagens, e use formatos modernos como WebP ou AVIF, que são muito mais leves que JPG/PNG. A imagem principal (o “herói” da página) é a que mais afeta o LCP — sirva-a com prioridade (fetchpriority="high") e nunca com lazy-load.
Para as demais imagens, porém, o lazy-load é seu aliado: ele adia o carregamento das imagens que estão abaixo da dobra (fora da tela inicial) até o momento em que o usuário rola até elas. Isso deixa o carregamento inicial mais leve e rápido, sem desperdiçar banda com imagens que talvez nem sejam vistas. A regra de ouro é simples: lazy-load em tudo, menos na imagem principal. No WordPress, o lazy-load já vem ativado por padrão para imagens — só garanta que ele não esteja sendo aplicado à imagem herói.
Use cache e um CDN. O cache guarda versões prontas das páginas, e um CDN (rede de distribuição de conteúdo) entrega os arquivos a partir de servidores próximos do visitante, reduzindo a distância e o tempo. Outra otimização de base é o protocolo de conexão: o HTTP/3 é mais rápido que as versões anteriores e ajuda a entregar os recursos da página com menos latência.
Reduza o TTFB melhorando a hospedagem. Se o servidor demora a responder, todo o resto atrasa — e o LCP sofre direto. TTFB acima de 200ms já é sinal de problema no servidor ou na hospedagem.
Use resource hints: preconnect e preload. São instruções que dizem ao navegador para se adiantar no carregamento do que é crítico. O preconnect estabelece a conexão com domínios externos importantes (como o do Google Fonts ou de um CDN) antes de ela ser de fato necessária, eliminando o atraso de “apresentação” entre servidores.
Já o preload manda o navegador buscar com prioridade um recurso essencial — tipicamente a fonte principal ou a própria imagem do LCP — para que ele esteja pronto mais cedo. Na prática, pré-carregar a fonte usada no texto principal e o recurso do LCP é uma das formas mais eficazes de baixar o tempo de carregamento. Use com parcimônia, porém: pré-carregar coisas demais tira prioridade do que realmente importa e tem o efeito contrário.
Para melhorar o INP (responsividade)
O INP sofre quando há JavaScript pesado travando a página. As ações principais:
Reduza e otimize o JavaScript. Remova scripts que você não usa, divida o código em pedaços menores (code splitting) e adie o que não é essencial para o carregamento inicial. Tarefas longas de JavaScript (acima de 50ms) são as principais vilãs do INP.
Remova scripts de terceiros desnecessários. Cada plugin de chat, pixel de rastreamento ou widget externo adiciona peso. Audite o que realmente precisa ficar.
Minifique CSS e JavaScript. A minificação remove espaços e caracteres desnecessários do código, deixando os arquivos menores e mais rápidos de processar.
Para melhorar o CLS (estabilidade visual)
O CLS melhora quando você reserva espaço para tudo que carrega. As ações:
Defina dimensões explícitas. Toda imagem, vídeo, iframe e anúncio deve ter largura e altura definidas, para o navegador reservar o espaço antes de o elemento carregar — evitando o “pulo”.
Cuide das fontes. Use font-display: swap e pré-carregue as fontes principais, para o texto não sumir e reaparecer deslocado.
Reserve espaço para conteúdo dinâmico. Banners, avisos de cookie e elementos injetados depois devem ter espaço reservado, para não empurrar o conteúdo que já estava na tela.
O papel da hospedagem no PageSpeed (o que ninguém te conta)
Aqui está o ponto que a maioria dos guias ignora — e que faz enorme diferença. Você pode otimizar imagens, código e cache ao máximo, mas se a sua hospedagem for lenta, há um teto que você não ultrapassa.
O motivo é o TTFB (Time to First Byte): o tempo que o servidor leva para começar a responder a cada requisição. Esse número depende diretamente do hardware do servidor, da carga (quantos sites dividem a mesma máquina), da localização do data center e da tecnologia usada (cache no servidor, versão do PHP, SSD/NVMe). Um TTFB alto atrasa o LCP e derruba a nota inteira, por mais otimizado que o resto esteja.
Por isso, escolher uma hospedagem rápida, com recursos adequados e servidores no Brasil (ou próximos do seu público), é uma das alavancas mais subestimadas de PageSpeed. Não adianta enxugar 200ms no front-end se o servidor está gastando 800ms só para começar a responder.
Seu PageSpeed tem um teto? Pode ser a hospedagem.
Você pode otimizar imagens e código ao máximo, mas se o servidor demora a responder (TTFB alto), o LCP e a nota inteira sofrem. A hospedagem da HomeHost tem servidores rápidos, SSD/NVMe e infraestrutura no Brasil para entregar o melhor TTFB e fazer suas otimizações renderem de verdade.
Conheça a hospedagem HomeHostErros comuns ao perseguir a nota do PageSpeed
Dois enganos frequentes que vale evitar.
Caçar a nota 100 a qualquer custo. A nota de laboratório é um diagnóstico, não um troféu. O que conta para o Google são as Core Web Vitals de campo, medidas em usuários reais. Uma nota 90 com Core Web Vitals “boas” em campo vale mais que uma nota 100 que não reflete a experiência real.
Esperar resultado imediato. Os dados de campo (CrUX) são uma média móvel de 28 dias. Quando você faz uma melhoria, ela leva de 4 a 6 semanas para aparecer plenamente nos dados de campo e no ranqueamento. Não reverta uma boa mudança por impaciência — espere a janela fechar.
Conclusão
PageSpeed não é só uma nota bonita para exibir — é a medida de quão rápido e agradável o seu site é para quem importa: o visitante. Comece entendendo a diferença entre dados de campo e laboratório, foque nas três Core Web Vitals atuais (LCP, INP e CLS — esqueça o FID), e ataque as causas de cada uma com otimização de imagens, código enxuto e estabilidade visual.
E não esqueça da base: por trás de toda otimização de front-end está o servidor. Uma hospedagem rápida, com bom TTFB e recursos adequados, é o alicerce que faz todas as outras melhorias renderem — e é o que separa um site que tenta ser rápido de um site que é rápido de verdade.
Perguntas frequentes sobre PageSpeed
O que é a nota do PageSpeed?
É uma pontuação de 0 a 100 que o Google PageSpeed Insights dá ao desempenho de uma página, calculada pelo Lighthouse a partir de uma simulação em laboratório. Quanto maior, melhor o desempenho. Ela serve para diagnosticar problemas de velocidade, mas o que o Google de fato usa para ranquear são as Core Web Vitals medidas em usuários reais (dados de campo), não a nota em si.
Qual é uma boa pontuação no PageSpeed?
A nota é classificada por cor: de 90 a 100 é boa (verde), de 50 a 89 é média (laranja) e de 0 a 49 é ruim (vermelho). Mirar em 90 ou mais é o ideal, mas mais importante do que a nota é passar nas três Core Web Vitals (LCP, INP e CLS) com dados de usuários reais.
É possível alcançar nota 100 no PageSpeed?
Sim, é possível, mas não é necessário nem sempre vale o esforço. A nota 100 é um resultado de laboratório; o que importa para o Google é ter as Core Web Vitals boas com usuários reais. Um site com nota 90 e Core Web Vitals aprovadas em campo está melhor posicionado do que um com nota 100 que não reflete a experiência real. Persiga as métricas de campo, não o número perfeito.
Por que a nota no mobile é menor que no desktop?
Porque o PageSpeed Insights simula o mobile com um processador mais lento e uma conexão de rede mais limitada, para refletir a realidade de muitos celulares. É normal a nota mobile ser bem menor que a desktop. Como o Google usa indexação mobile-first, é a versão mobile que você deve priorizar ao otimizar.
Qual a diferença entre PageSpeed e a velocidade real do site?
A nota do PageSpeed é uma estimativa de desempenho baseada em vários fatores, não um cronômetro do tempo exato de carregamento. Um site pode carregar rápido e ter nota mediana, ou o contrário. Por isso o ideal é usar o PageSpeed junto com os dados de campo (experiência real dos visitantes) e, se quiser o tempo exato, ferramentas de carregamento como o GTmetrix ou o WebPageTest.
O que são Core Web Vitals?
São as três métricas que o Google usa para medir a experiência real do usuário: LCP (velocidade de carregamento, bom até 2,5s), INP (responsividade às interações, bom até 200ms) e CLS (estabilidade visual, bom até 0,1). As três fazem parte dos sinais de ranqueamento do Google e devem ser a sua prioridade ao otimizar o site.
O FID ainda existe? Qual a diferença para o INP?
O FID (First Input Delay) foi aposentado pelo Google em março de 2024 e substituído pelo INP (Interaction to Next Paint). Se você viu conteúdo recomendando otimizar o FID, está desatualizado. O INP é mais rigoroso porque mede a responsividade da página durante toda a visita, não apenas o atraso da primeira interação. A meta é um INP de até 200 milissegundos.
Como melhorar o PageSpeed no WordPress?
No WordPress, as ações de maior impacto são: instalar um plugin de cache (como WP Rocket ou LiteSpeed Cache), otimizar e converter imagens para WebP, minificar CSS e JavaScript, remover plugins pesados ou que você não usa, e manter a versão do PHP atualizada. Acima de tudo, escolha uma hospedagem rápida — o tempo de resposta do servidor (TTFB) é a base de tudo. Se o seu site é WordPress, vale considerar uma hospedagem WordPress otimizada, já preparada para desempenho.
Por que minha nota do PageSpeed caiu de repente?
As causas mais comuns são a instalação de um novo plugin ou tema pesado, a adição de scripts de terceiros (chat, rastreadores, anúncios), imagens grandes recém-publicadas, ou uma sobrecarga no servidor de hospedagem. A nota também varia um pouco a cada teste, por ser uma simulação. Se a queda foi grande e persistente, revise o que mudou no site recentemente.
Qual a diferença entre PageSpeed Insights e GTmetrix?
Ambos medem desempenho, mas com focos diferentes. O PageSpeed Insights é do Google, usa o Lighthouse e mostra dados reais de usuários (Core Web Vitals), que é o que conta para o ranqueamento. O GTmetrix detalha o tempo de carregamento e a ordem em que os recursos carregam (cascata), útil para diagnóstico técnico. O ideal é usar os dois juntos, mas priorizar o PageSpeed por refletir o que o Google avalia. Se quiser se aprofundar, veja nosso tutorial de como melhorar a performance do WordPress com o GTmetrix.
A hospedagem influencia o PageSpeed?
Muito. O tempo que o servidor leva para começar a responder (TTFB) afeta diretamente o LCP e a nota inteira. Um TTFB acima de 200ms já indica problema no servidor. Por mais que você otimize imagens e código, uma hospedagem lenta cria um teto que você não ultrapassa. Servidores rápidos, com SSD/NVMe, cache, protocolos modernos como o HTTP/3 e localizados perto do seu público melhoram o PageSpeed na base.
Quanto tempo leva para a nota melhorar depois das otimizações?
A nota de laboratório muda na hora, assim que você roda o teste de novo. Já os dados de campo (que o Google usa para ranquear) são uma média móvel de 28 dias, então uma melhoria leva de 4 a 6 semanas para aparecer plenamente nos dados reais e no ranqueamento. Tenha paciência e não reverta uma boa mudança antes de essa janela fechar.
