Site lento é um site que demora a mostrar o conteúdo ou a reagir ao clique, e isso quase sempre tem uma de duas origens: o servidor demora para começar a responder, ou a página chega pesada e trava a exibição no navegador. A solução de uma não resolve a outra, por isso o primeiro passo é descobrir qual das duas está acontecendo. Trocar de hospedagem às cegas, instalar mais um plugin de otimização ou comprimir imagens sem medir antes costuma gastar tempo no lugar errado.
Servidor ou página: descubra onde está o problema
O número que separa os dois casos é o TTFB (Time to First Byte), o tempo até chegar o primeiro pedaço da página. Segundo a web.dev, do Google, até 0,8 segundo é um bom valor e acima de 1,8 segundo é ruim.
| O que você vê | Onde está o problema | Por onde começar |
|---|---|---|
| TTFB alto (acima de 0,8 s) | No servidor: hospedagem fraca, falta de cache de página, banco de dados lento | Cache de página e, se não bastar, hospedagem |
| TTFB bom, mas a página demora a aparecer | Na página: imagens, scripts, CSS, fontes | Imagens e arquivos que travam a exibição |
| A página aparece, mas pula ou demora a responder ao clique | No código da página e nos scripts de terceiros | Medidas das imagens e scripts pesados |
Ferramentas como o PageSpeed Insights mostram o TTFB e os outros tempos da página. A análise gratuita também mede o primeiro byte, o peso e os arquivos que travam a exibição.
Os três números que o Google usa
O Google mede a experiência de velocidade com três métricas, as Core Web Vitals. Os limites abaixo são os da web.dev e valem para 75% das visitas, separando celular e computador:
| Métrica | O que mede | Bom até |
|---|---|---|
| LCP (Largest Contentful Paint) | Quanto tempo o maior elemento visível leva para aparecer | 2,5 segundos |
| INP (Interaction to Next Paint) | Quanto a página demora para reagir a um clique ou toque | 200 milissegundos |
| CLS (Cumulative Layout Shift) | Quanto o conteúdo pula enquanto carrega | 0,1 |
O INP substituiu o antigo FID em 2024. Texto que ainda fala em FID está desatualizado.
Como ler o PageSpeed Insights sem se assustar
O PageSpeed Insights mostra duas coisas diferentes na mesma tela, e confundir as duas é o erro mais comum:
- Os dados de usuários reais, no topo, vêm do Chrome UX Report e resumem as visitas dos últimos 28 dias. É isso que mostra a experiência de quem usa o site. Sites com pouco tráfego não têm esses dados.
- A nota de 0 a 100, mais abaixo, é uma simulação do Lighthouse, feita em um único aparelho com uma rede fixa. Serve para encontrar problemas, não para dizer como está a experiência real.
Uma nota baixa na simulação não significa que os visitantes sofrem. A própria ajuda do Wix diz isso sobre o seu painel de velocidade. Comece pelos dados reais. Se estiverem bons, a nota da simulação vira uma lista de melhorias, não uma emergência.
No Search Console, o relatório Core Web Vitals mostra quais grupos de páginas estão bons e quais precisam de melhoria, também com dados de usuários reais.
Medimos 53 sites brasileiros: o vilão é a página
De 20 a 22/10/2026, o validador mediu a página principal de 53 sites com domínio .br, de grandes varejistas e bancos a pequenas indústrias e lojas, a partir de uma conexão no Brasil. Sem nomes, o retrato é este:
- O servidor raramente é o culpado. 49 de 52 sites responderam o primeiro byte em até 0,8 segundo, com mediana de 74 milissegundos.
- O peso está na página. 31 de 52 carregam scripts ou CSS que travam a primeira exibição, e 19 deles em quantidade alta.
- Em 37 de 47 páginas com imagens, mais de 30% delas estão sem largura e altura no código, a causa clássica do conteúdo que pula.
- Em 15 de 31 sites, mais de um quarto dos arquivos de CSS, JavaScript, fontes e imagens sai sem cache longo, e o visitante baixa tudo de novo a cada visita.
- 12 de 52 páginas passam de 1,5 MB. A mediana ficou em 414 KB.
Em outras palavras: antes de pagar por uma hospedagem mais cara, vale olhar a própria página.
O que corrigir, na ordem
1. Servidor lento: cache de página antes de trocar de hospedagem
Se o TTFB passa de 0,8 segundo, o servidor está montando a página do zero a cada visita. Um cache de página guarda o HTML pronto e entrega direto. No WordPress, a documentação oficial cita W3 Total Cache, WP Super Cache e Cache Enabler como ponto de partida. Só quando o cache não resolve é hora de olhar o plano de hospedagem.
2. Imagens: formato, tamanho e medidas
- Formato moderno (WebP ou AVIF) e no tamanho em que a imagem aparece. Foto de 4.000 pixels exibida em 800 é peso jogado fora.
- Largura e altura no código de cada imagem, para o navegador reservar o espaço e o conteúdo não pular.
- Carregamento tardio só abaixo da dobra. A web.dev orienta não usar
loading="lazy"nas imagens que aparecem logo na abertura, principalmente a maior delas. Nessa imagem, o atraso piora o LCP.
3. Scripts e CSS que travam a exibição
Arquivos de JavaScript no topo da página, sem defer ou async, fazem o navegador parar até baixar e rodar tudo. Chat, pixels de anúncio, mapas e widgets de redes sociais são os suspeitos de sempre. Pergunte de cada um: ele precisa carregar antes do conteúdo? Na maioria das vezes, não.
4. Cache e compressão dos arquivos
CSS, JavaScript, fontes e imagens que não mudam toda hora devem sair do servidor com cache longo, para o navegador reaproveitar na próxima visita. E o texto (HTML, CSS, JS) deve ir comprimido, com gzip ou Brotli. Os dois ajustes são feitos na hospedagem ou na CDN, em geral sem mexer no site.
5. Plugins, tema e construtores de página
A documentação do WordPress é direta: o tema e a quantidade de plugins têm grande impacto no desempenho, e desativar e apagar os desnecessários é uma das melhorias mais significativas. Construtores visuais pesados costumam somar scripts e CSS em todas as páginas.
E no Wix?
O Wix tem um painel próprio de Velocidade do site, com os dados de visitantes reais dos últimos 30 dias, que não se limita a quem usa o Chrome. Como a hospedagem é do Wix, o que você controla é o conteúdo: imagens, quantidade de elementos e aplicativos instalados em cada página.
A velocidade conta para o Google?
Conta, mas não sozinha. Segundo o Google, as Core Web Vitals se alinham ao que os sistemas de classificação recompensam. A mesma documentação afirma que a busca mostra o conteúdo mais relevante "mesmo se a experiência da página for abaixo do ideal" e que não existe um sinal único de experiência. Na prática, velocidade funciona como desempate entre páginas igualmente úteis e pesa muito no visitante que desiste antes de ver a página. Para a parte de conteúdo e indexação, veja como colocar o site no Google.
Como medir antes e depois
- Escolha três páginas: a inicial, a que mais recebe visitas e uma página interna típica.
- Anote os números de hoje no PageSpeed Insights (dados reais e simulação) e na análise gratuita.
- Mude uma coisa por vez, para saber o que funcionou.
- Confira a simulação logo depois da mudança. Os dados de usuários reais levam até 28 dias para refletir tudo, porque cobrem esse período.
