Como interpretar o resultado de um teste de velocidade (PageSpeed, GTmetrix e cia)
Oi, tudo bem? Aqui é a Sensei da GeHost 🥋 e hoje eu vou te ensinar a ler esses relatórios de velocidade sem se assustar com a quantidade de siglas e números. Ferramentas como Google PageSpeed Insights e GTmetrix são gratuitas, feitas por terceiros (não são da GeHost), e servem pra "fotografar" o desempenho do seu site num determinado momento. Vamos entender juntos o que cada parte da foto quer dizer.
Dica da Sensei: nenhum site tira 100/100 o tempo todo, e isso é absolutamente normal. O objetivo não é a nota perfeita, é a experiência boa pra quem visita.
Passo 1 — Rodando o teste
- Acesse pagespeed.web.dev (Google) ou gtmetrix.com.
- Cole a URL completa do seu site (com https://) e inicie o teste.
- Espere alguns segundos — a ferramenta carrega seu site "escondida" e mede tudo.
Rode o teste em um momento tranquilo (fora de picos de tráfego) e, se puder, repita 2 ou 3 vezes: esses testes variam um pouco de execução pra execução, então é normal ver notas diferentes.
Passo 2 — A nota geral (o número grandão e colorido)
Assim que o teste termina, aparece um número de 0 a 100, geralmente com uma cor:
- Verde (90–100): ótimo desempenho.
- Laranja/Amarelo (50–89): precisa de atenção, mas não é motivo de pânico.
- Vermelho (0–49): algo está pesando bastante o carregamento — vale investigar.
Essa nota é um resumo de várias métricas técnicas somadas. Pra entender de verdade o que está acontecendo, o segredo é olhar as métricas individuais logo abaixo dela — é aí que mora a informação útil.
Passo 3 — As métricas que realmente importam (Core Web Vitals)
Você vai ver algumas siglas em inglês. Calma, vou traduzir cada uma:
- LCP (Largest Contentful Paint): tempo até o maior elemento da tela (geralmente uma imagem ou título grande) aparecer. É a métrica de "senti que a página carregou".
- CLS (Cumulative Layout Shift): mede se os elementos da página "pulam de lugar" enquanto carrega (aquele clique errado porque um banner apareceu de repente). Quanto mais perto de 0, melhor.
- INP / FID (Interaction to Next Paint / First Input Delay): quão rápido o site responde quando alguém clica ou toca em algo.
- TTFB (Time to First Byte): tempo até o servidor começar a responder à requisição — tem relação com hospedagem, mas também com o quão "pesado" é o site (plugins, banco de dados, etc).
- Speed Index / FCP (First Contentful Paint): quão rápido algo começa a aparecer na tela.
Dica da Sensei: se você só tiver tempo pra olhar uma coisa, olhe o LCP. É a métrica que mais reflete a sensação real de "o site demorou" pra quem está navegando.
Mobile x Desktop
Repare que o teste roda separado para celular e computador. É normal (e esperado) que o resultado no mobile seja mais baixo — o teste simula uma conexão mais lenta e um aparelho mais fraco de propósito, porque é assim que boa parte do público real navega. Preste atenção especial no mobile.
Dados de laboratório x dados de campo
Alguns relatórios trazem duas seções: uma com dados simulados (o teste feito na hora) e outra com dados reais de usuários que visitaram seu site nos últimos dias (geralmente chamada de "Field Data" ou "Experiência real do usuário"). Se essa segunda seção existir, ela costuma ser mais confiável, porque reflete pessoas de verdade, com conexões e aparelhos diferentes — não apenas uma simulação.
Passo 4 — O que costuma pesar no resultado
Na prática, a nota de velocidade normalmente é puxada pra baixo por fatores do próprio site (conteúdo, tema, plugins), não da hospedagem em si. Os vilões mais comuns são:
- Imagens muito grandes ou sem compressão.
- Excesso de plugins/scripts de terceiros (chat, pixel de rastreamento, pop-ups).
- Temas muito "pesados" com recursos que o site não usa.
- Falta de cache configurado no site.
- Vídeos incorporados que carregam automaticamente.
Passo 5 — O que dá pra ajustar
Algumas melhorias simples que costumam ajudar bastante:
- Comprimir imagens antes de subir ao site (existem plugins e ferramentas gratuitas de compressão para isso).
- Revisar plugins/scripts e remover os que não são realmente usados.
- Habilitar cache no site (via plugin de cache, se for WordPress, ou configurações no próprio CMS).
- Confirmar que o site está com HTTPS ativo — além de segurança, é um fator observado pelos testes.
Pra conferir o certificado SSL do seu domínio no painel, acesse a seção de SSL/TLS no cPanel:
Se você (ou seu desenvolvedor) precisar revisar arquivos do site, como o .htaccess (usado para configurar cache e compressão), isso é feito pelo Gerenciador de Arquivos:
Dica da Sensei: mudanças de código/tema costumam ser trabalho do desenvolvedor do site. Se o seu site foi feito pela equipe da GeHost e você ainda está dentro do período de suporte gratuito de 30 dias após a entrega, é só chamar a gente pelo painel (painel.gehost.com.br) que a gente te orienta.
Passo 6 — Repita o teste depois das melhorias
Depois de qualquer ajuste, espere alguns minutos e rode o teste de novo — em mais de uma ferramenta, se possível (PageSpeed e GTmetrix às vezes mostram números levemente diferentes, porque medem de formas um pouco distintas). O que importa é a tendência de melhora, não bater 100 de primeira.
Quando pedir ajuda
Se depois de revisar imagens, plugins e cache o resultado continuar muito baixo, ou se você não tem certeza do que está pesando o site, abra um chamado com o suporte GeHost pelo painel (painel.gehost.com.br) contando a URL testada e a ferramenta usada. A gente dá uma olhada com você.
É isso! Espero ter deixado esses relatórios menos assustadores 😊 Qualquer dúvida, a Sensei está por aqui.