De Olho

site muito lento

Site muito lento: mede antes de mexer.

Um site muito lento é o único problema que se instala devagar o suficiente para toda a gente se habituar. Quando alguém finalmente se queixa, já dura há semanas — e há um número que o mostrava desde o início.

"O site está lento" pode significar três coisas completamente diferentes: o servidor demora a começar a responder, a resposta é enorme e demora a descarregar, ou o browser demora a desenhar o que recebeu. As três sentem-se iguais e resolvem-se em sítios opostos.

A primeira mede-se pelo tempo até ao primeiro byte — quanto tempo o servidor demorou a dizer alguma coisa. Se esse número for alto, nada do que fizeres a imagens ou a JavaScript vai ajudar: o problema está no PHP, na base de dados ou na máquina.

É por isso que medir vem antes de mexer. Optimizar imagens num site cujo servidor demora dois segundos a responder é trabalho verdadeiro com efeito nenhum — e é o erro mais comum quando alguém pede para "acelerar o site".

// causas prováveis

Por onde é que isto costuma vir.

Por ordem de frequência e não por ordem de gravidade. A primeira da lista explica mais casos do que as outras todas juntas.

  • A base de dados cresceu e ninguém deu por isso

    Tabelas de revisões, logs de plugins, carrinhos abandonados, transientes que nunca expiram. Uma base de dados que passou de 40 MB para 2 GB torna lenta cada página que a consulta, sem que nada no site tenha mudado.

  • Não há cache de página

    Sem cache, cada visita gera a página de novo: PHP, consultas, tudo. Para conteúdo que não muda de minuto a minuto, é trabalho repetido milhares de vezes por dia, e é a melhoria com melhor relação entre esforço e resultado.

  • Plugins que falam com servidores externos

    Um plugin que consulta uma API a cada carregamento faz o teu site herdar a lentidão de outra pessoa. Se esse serviço estiver mau, o teu site está mau — e não há nada no teu servidor que o mostre.

  • Alojamento partilhado no limite

    Quando a máquina está cheia, tudo demora. Vê-se pela lentidão vir e ir a horas certas, sem relação com o que se faz no site.

  • Imagens e scripts em excesso

    É a causa que toda a gente ataca primeiro e a única que se vê a olho. Conta mesmo — mas só depois de o servidor responder depressa, porque de outra forma estás a optimizar a segunda metade de um problema que está na primeira.

// diagnóstico

Passo a passo, do que custa menos ao que custa mais.

Cada passo elimina hipóteses. Saltar um passo poupa dois minutos e costuma custar uma hora — a ordem é a parte que interessa.

  1. 01

    Mede o tempo de resposta do servidor

    Uma verificação externa devolve quanto tempo o servidor demorou a responder ao pedido, em milissegundos. Abaixo dos 400 ms é bom; entre 400 e 800 é aceitável; acima de 1 500 ms o problema está no servidor e é aí que tens de trabalhar.

  2. 02

    Compara a página inicial com uma página interior

    Se a inicial é rápida e uma listagem de produtos demora cinco segundos, o problema é uma consulta concreta. Se tudo é igualmente lento, é a máquina ou a configuração.

  3. 03

    Vê se a lentidão tem horário

    Lentidão sempre à mesma hora é um cron, um backup ou o vizinho do alojamento. Lentidão constante é código ou base de dados. Distinguir os dois exige medir ao longo de dias — uma medição isolada não distingue nada.

  4. 04

    Desliga os plugins um a um e mede outra vez

    Com um site de staging, se puderes. É moroso e é o que dá a resposta. Costuma haver um culpado e costuma ser o plugin que ninguém suspeitava porque "não faz nada".

  5. 05

    Limpa a base de dados antes de comprar mais servidor

    Apagar revisões antigas, transientes expirados e tabelas de plugins desinstalados devolve desempenho sem custar nada. Faz backup primeiro — e faz um backup que já tenhas restaurado antes.

  6. 06

    Só então é que faz sentido optimizar o que se vê

    Imagens, formatos modernos, adiar scripts. Tudo isto conta, e conta muito mais quando o servidor já responde depressa. Por esta ordem, o resultado é visível; pela ordem inversa, é frustrante.

O primeiro passo é sempre o mesmo — ver de fora o que o servidor responde de facto. Faz isso aqui, a partir de um servidor em Portugal. Sem conta, sem custo, e não guardamos o que verificares.

verificar_site servidor: PT

// que não volte

Como evitar que volte a acontecer sem dares por isso.

Resolver o incidente é metade do trabalho. A outra metade é a parte que ninguém factura e é a que decide se há um terceiro.

  • Guarda o tempo de resposta ao longo do tempo

    Uma medição diz-te como está hoje. Uma série diz-te desde quando é que piorou — e "desde quando" é a pergunta que aponta para a causa, porque quase sempre há uma alteração nessa data.

  • Trata a subida como incidente, não como feitio

    Um site muito lento não está em baixo — um que passou de 200 ms para 1 400 ms, mas está a caminho de estar. É a única avaria que avisa com semanas de antecedência.

  • Limita os plugins que falam para fora

    Cada integração externa é uma dependência da disponibilidade de outra pessoa. Vale a pena saber quantas tens antes de uma delas ter um mau dia.

  • Faz limpeza de base de dados com calendário

    Não quando o site estiver lento — de três em três meses, com backup. É manutenção, e é exactamente o tipo de trabalho que justifica uma avença.

// limites

Onde é que esta página encalha.

Uma página de diagnóstico que não diz onde acaba manda-te dar voltas até desistires. Estes são os casos em que não chega.

  • O tempo de resposta medido de fora não é a experiência de quem visita. Não executa JavaScript, não descarrega imagens e não mede o que o browser faz depois. É o primeiro número, não é o único.
  • Não fazemos análise de desempenho no browser. Para o que o visitante sente ao carregar a página, há ferramentas dedicadas e elas fazem esse trabalho melhor.
  • Uma verificação a partir de Portugal diz como está para quem está cá. Se o teu público é noutro continente, o número que interessa é medido a partir de lá.
  • Não dizemos qual é a consulta lenta. De fora vê-se que o servidor demora; qual é a linha só se vê por dentro, com o log de consultas lentas ou o Query Monitor.

// perguntas

O que nos perguntam a seguir.

Qual é um tempo de resposta aceitável?

Abaixo de 400 ms é bom para um site alojado em Portugal a servir visitantes portugueses. Entre 400 e 800 ms passa. Acima de 1 500 ms nota-se, e acima de 3 segundos as pessoas desistem antes de a página aparecer. Estes números são para o servidor responder — o carregamento completo é outra medida.

Mudar para um alojamento melhor resolve?

Resolve se o problema for a máquina, e não resolve nada se for uma consulta lenta ou um plugin a falar para fora — esses vão com o site. Medir primeiro poupa-te uma migração que não muda nada.

Um site muito lento pode dar erro 504?

Pode, e é frequentemente o passo seguinte. Quando a resposta passa do timeout do proxy, a lentidão deixa de ser incómodo e passa a ser erro. O 504 tem página própria, com o diagnóstico específico.

// erros vizinhos

Se afinal não era este.

Metade do diagnóstico é perceber que se estava a olhar para o erro errado. Estes três são os que mais se confundem com este.

E se acontecer às três da manhã?

A lentidão é a única falha que dá aviso prévio, e quase ninguém o aproveita — porque para o ver é preciso ter o número de ontem, o da semana passada e o do mês passado. A De Olho vai guardar o tempo de resposta de cada verificação desde o primeiro dia, e o histórico não expira. É o que transforma "acho que o site está mais lento" numa data concreta a partir da qual mudou.

A De Olho abre em 2026 e ainda não dá para usar. Quem estiver na lista de espera fica a saber primeiro e mantém o preço de lançamento enquanto a subscrição durar.

Só te escrevemos sobre o lançamento. Sem spam, e não partilhamos o teu email com ninguém. Como tratamos os teus dados.