Velocidade do site: como medir e deixar seu site mais rápido (Guia)

Velocidade do site é o tempo que suas páginas levam para mostrar o conteúdo principal e responder aos cliques do visitante. Para melhorar, meça primeiro no PageSpeed Insights e corrija nesta ordem: imagens, cache, servidor e, por último, JavaScript e CSS.

Este guia mostra como ler as métricas que o Google usa hoje (as Core Web Vitals), onde estão as causas mais comuns de um site lento e o que fazer em cada caso. Se o seu site é WordPress, use também o guia de velocidade do site WordPress, com plugins de cache, banco de dados e Redis em detalhe.

---

Por que a velocidade do site importa

Um site lento perde o visitante antes de mostrar qualquer coisa: a pessoa volta para a busca e clica no próximo resultado. Para quem tem um negócio, isso aparece como menos vendas, menos contatos e anúncios mais caros por conversão.

O Google mede essa experiência com as Core Web Vitals, três métricas coletadas de visitantes reais do Chrome. A documentação do Google Search recomenda alcançar bons valores e diz que eles estão alinhados ao que os sistemas de ranking procuram recompensar. Mesmo assim, velocidade não substitui conteúdo relevante: ela desempata, não ranqueia sozinha.

Métrica	O que mede	Bom	Precisa melhorar	Ruim
LCP (Largest Contentful Paint)	Quando o maior elemento visível (foto, banner, título) aparece	até 2,5 s	de 2,5 s a 4 s	acima de 4 s
INP (Interaction to Next Paint)	Quanto a página demora para reagir a cliques, toques e teclas	até 200 ms	de 200 ms a 500 ms	acima de 500 ms
CLS (Cumulative Layout Shift)	Quanto o layout “pula” enquanto a página carrega	até 0,1	de 0,1 a 0,25	acima de 0,25

Para ser aprovada, a página precisa ficar no “bom” nas três métricas no percentil 75, ou seja, em pelo menos 75% das visitas, avaliando celular e computador separadamente. Os limites estão em web.dev, o portal de referência do Google para desempenho na web.

Atualização: o INP substituiu o FID (First Input Delay) como Core Web Vital em 12 de março de 2024. Se uma ferramenta ou tutorial ainda fala em FID, ele está desatualizado.

---

Como medir a velocidade do site

As ferramentas mostram dois tipos de dado, e confundir um com o outro é o erro mais comum de quem começa a otimizar:

• Dados de campo: vêm do Chrome UX Report (CrUX), com visitas reais dos últimos 28 dias. São eles que contam para as Core Web Vitals. Sites com pouco tráfego podem não ter amostra suficiente.
• Dados de laboratório: o Lighthouse carrega a página uma vez, num ambiente simulado (celular intermediário em rede móvel). Servem para achar a causa do problema, mas variam de um teste para outro (documentação do PageSpeed Insights).

Na prática, faça assim:

1. Abra o PageSpeed Insights, cole a URL de uma página importante (não só a home) e olhe primeiro o bloco de dados de campo, na aba Celular.
2. Anote LCP, INP e CLS. A métrica em amarelo ou vermelho é a sua prioridade.
3. Desça até a nota de desempenho, que é de laboratório: de 90 a 100 é bom, de 50 a 89 precisa melhorar e de 0 a 49 é ruim. As seções de diagnóstico mostram o que mais pesa.
4. Para investigar a fundo, rode o Lighthouse no próprio Chrome. O passo a passo está no nosso guia do Google Lighthouse. Ferramentas como WebPageTest e GTmetrix mostram a cascata de arquivos, útil para ver o que carrega por último.
5. No Google Search Console, o relatório de Core Web Vitals agrupa as URLs com problema no site inteiro.
6. Depois de cada mudança, repita o teste na mesma página e no mesmo tipo de dispositivo. Os dados de campo levam até 28 dias para refletir a melhora.

Dica: teste também numa janela anônima e pelo celular, fora do Wi-Fi. Quem administra o site costuma ter tudo em cache e acha que ele está rápido.

---

Site lento: principais causas e como resolver

Um site pesado quase sempre tem uma ou duas causas dominantes. A tabela liga o sintoma que você vê no PageSpeed Insights à causa provável e à correção.

Sintoma	Causa provável	Como resolver
LCP alto, com foto ou banner no topo	Imagem grande demais, em JPEG ou PNG sem compressão, ou com lazy loading	Redimensionar, converter para WebP ou AVIF e tirar o lazy loading da imagem principal
Servidor demora a responder (TTFB alto)	Sem cache de página, PHP antigo, banco de dados lento ou hospedagem sobrecarregada	Cache de página, PHP atual, revisão de consultas e hospedagem adequada
INP alto (cliques demoram a reagir)	Muito JavaScript e scripts de terceiros: chat, pixels, anúncios, mapas	Adiar scripts com defer, remover o que não usa e carregar widgets só onde precisa
CLS alto (o layout pula)	Imagens sem largura e altura, anúncios e banners que entram depois, troca de fontes	Definir width e height, reservar espaço para anúncios e usar font-display
“Recursos que bloqueiam a renderização”	CSS e JavaScript carregados no <head> sem adiamento	CSS crítico no início, restante assíncrono, scripts com defer
Vários redirecionamentos seguidos	http → https → www → página final	Apontar links e menus direto para a URL final, com um único 301
Rápido para você, lento para quem está longe	Um único servidor atendendo todo mundo	CDN

Widgets e excesso de anúncios merecem atenção especial: cada um faz requisições a servidores de terceiros, e seu site passa a depender da velocidade deles. Se um widget não traz resultado, tire.

Em lojas virtuais o padrão se repete: fotos de produto pesadas, muitos plugins ou apps e scripts de marketing. Comece pelas páginas de categoria e de produto, que concentram o tráfego e as vendas.

---

Imagens: WebP, AVIF e lazy loading

Imagens costumam ser a maior parte do peso da página e, muitas vezes, são o próprio elemento de LCP. É onde está o ganho mais fácil.

• Envie no tamanho em que a imagem aparece. Uma foto de 4.000 px exibida a 800 px é peso desperdiçado. Com srcset, o navegador escolhe a versão certa para cada tela.
• Prefira WebP ou AVIF. Os dois comprimem mais que JPEG e PNG com qualidade parecida e funcionam nos navegadores atuais (veja o guia de formatos da MDN).
• Informe sempre largura e altura. Assim o navegador reserva o espaço antes de a imagem chegar, e o layout não pula (CLS).
• Lazy loading só abaixo da dobra. O atributo nativo loading="lazy" adia imagens que o visitante ainda não vê. Na imagem principal do topo, ele piora o LCP. Ali, use fetchpriority="high".

Exemplo com a imagem principal em AVIF, WebP como alternativa e uma imagem mais abaixo carregada sob demanda:

<!-- Imagem do topo (candidata a LCP): sem lazy, com prioridade alta -->
<picture>
  <source srcset="banner.avif" type="image/avif">
  <source srcset="banner.webp" type="image/webp">
  <img src="banner.jpg" width="1200" height="600" alt="Descrição do banner" fetchpriority="high">
</picture>

<!-- Imagem abaixo da dobra: carregada só quando se aproximar da tela -->
<img src="produto.webp" width="800" height="800" alt="Foto do produto" loading="lazy">

---

Cache: navegador, página, objeto e CDN

Cache é guardar uma cópia pronta para não refazer o mesmo trabalho a cada visita. Existem quatro camadas, e cada uma resolve um problema diferente:

• Cache do navegador: o visitante guarda CSS, JavaScript, imagens e fontes no próprio aparelho. Acelera a segunda página visitada e o retorno ao site. É controlado pelo cabeçalho Cache-Control.
• Cache de página: o servidor guarda o HTML pronto e o entrega sem executar PHP nem consultar o banco. É o que mais reduz o tempo de resposta em sites dinâmicos, como WordPress e lojas virtuais.
• Cache de objeto: guarda em memória (Redis ou Memcached) o resultado de consultas ao banco. Ajuda nas páginas que não podem ir para o cache de página: carrinho, checkout, área logada e painel.
• CDN: espalha cópias dos arquivos por servidores em várias regiões, perto de quem acessa. Entenda como funciona uma CDN e veja como configurar a Cloudflare, a opção gratuita mais conhecida.

Uma configuração comum de cache do navegador (detalhes na MDN):

# CSS, JS e imagens com versão no nome (ex.: app.3f9a1.js): cache longo
Cache-Control: public, max-age=31536000, immutable

# HTML: o navegador confere com o servidor antes de reutilizar
Cache-Control: no-cache

Atenção: com cache longo, mudar o conteúdo de um arquivo não basta. Troque o nome ou a versão na URL (estilo.css?v=2), senão o visitante continua vendo a versão antiga.

---

Servidor e hospedagem: TTFB, PHP, HTTP/2 e HTTP/3

TTFB (Time to First Byte) é o tempo até o servidor começar a responder. Ele não é uma Core Web Vital, mas tudo vem depois dele: com TTFB alto, o LCP dificilmente fica bom. Como referência, o web.dev considera bom até 0,8 s e ruim acima de 1,8 s.

Em sites feitos em PHP (WordPress, WooCommerce, Magento, OpenCart), a versão do PHP pesa no TTFB e na segurança. Situação das versões em outubro de 2026, segundo o php.net:

Versão do PHP	Situação	Correções de segurança até
8.5	Suporte ativo	31/12/2029
8.4	Suporte ativo	31/12/2028
8.3	Só correções de segurança	31/12/2027
8.2	Só correções de segurança, por pouco tempo	31/12/2026
8.1 e anteriores	Sem suporte	Encerrado

Antes de trocar a versão, teste o site numa cópia: plugins e temas antigos podem não funcionar em PHP novo. Além do PHP, confira estes pontos com a sua hospedagem:

• HTTP/2: várias requisições pela mesma conexão. Por isso, juntar todos os arquivos num só deixou de ser regra.
• HTTP/3: roda sobre o protocolo QUIC e lida melhor com perda de pacotes, comum em redes móveis. Pode vir do servidor ou da CDN. Saiba mais sobre o HTTP/3.
• Compressão: gzip ou Brotli ativos para HTML, CSS e JavaScript.
• Recursos isolados: em hospedagem compartilhada, uma conta vizinha que consome demais pode deixar seu site lento. Tecnologias como o CloudLinux limitam e isolam os recursos de cada conta.

Na SAN: a hospedagem de sites roda em cloud, com cPanel, CloudLinux isolando os recursos de cada conta e tráfego ilimitado. A migração do seu site é gratuita e o suporte é em português. Conheça a hospedagem de sites da SAN.

---

JavaScript e CSS

Depois de imagens e servidor, o que mais trava a página é código: JavaScript que ocupa o processador do celular (INP alto) e arquivos que bloqueiam a renderização. O primeiro ajuste é dizer ao navegador quando executar cada script:

<!-- Bloqueia a página até baixar e executar -->
<script src="slider.js"></script>

<!-- Baixa em paralelo e executa depois do HTML, na ordem -->
<script src="slider.js" defer></script>

<!-- Baixa em paralelo e executa assim que chega (ex.: analytics) -->
<script src="analytics.js" async></script>

• Minifique CSS, JavaScript e HTML, removendo espaços e comentários. Plugins de cache e ferramentas de build fazem isso automaticamente.
• Remova o que não usa. O painel Coverage do Chrome DevTools mostra quanto de cada arquivo CSS e JS ficou sem uso na página.
• Corte scripts de terceiros: chat, mapas, pixels de anúncio e vídeos incorporados. Carregue-os só nas páginas que precisam ou depois de uma interação.
• Prefira CSS em arquivos externos, que vão para o cache do navegador, e deixe direto no HTML só o CSS necessário para o topo da página.
• Fontes: use poucas variações (peso e estilo), hospede no próprio site quando possível e aplique font-display: swap para o texto aparecer antes da fonte chegar.

---

Checklist final

Use como roteiro, de cima para baixo. Faça backup antes de mexer em servidor, plugins ou código.

• ☐ Medi LCP, INP e CLS no PageSpeed Insights (dados de campo, celular) e anotei os valores.
• ☐ Imagens no tamanho de exibição, em WebP ou AVIF, com largura e altura definidas.
• ☐ Lazy loading só abaixo da dobra; imagem principal com fetchpriority="high".
• ☐ Cache de página ativo e cabeçalhos de cache do navegador configurados.
• ☐ CDN para arquivos estáticos, se o público estiver espalhado.
• ☐ TTFB abaixo de 0,8 s nas páginas principais.
• ☐ PHP 8.3 ou mais novo, testado antes numa cópia do site.
• ☐ HTTP/2 ou HTTP/3 e compressão gzip ou Brotli ativos.
• ☐ Scripts com defer ou async e scripts de terceiros revisados.
• ☐ No máximo um redirecionamento entre o link e a página final.
• ☐ Novo teste depois de cada mudança e revisão mensal do relatório de Core Web Vitals no Search Console.

---

Perguntas frequentes