Skip to content

Tudo para WordPress, desenvolvimento web — e não só

⏱ Time to first byte: o que é o TTFB e como melhorá-lo no WordPress

⏱ Time to first byte: o que é o TTFB e como melhorá-lo no WordPress

Clicou num link e o browser fica ali parado. Sem carregamento de página, sem indicador de progresso, apenas um ecrã branco e à espera. Isto não é a velocidade da sua internet nem JavaScript lento. Isto é o TTFB: o tempo que o servidor demora a responder ao primeiro pedido.

O TTFB determina quando é que os utilizadores verão alguma coisa no ecrã. Com um TTFB lento, os visitantes vão embora antes de o seu site sequer começar a ser renderizado. E a partir de 2025, a Google inclui a capacidade de resposta do servidor nos seus sinais de classificação Core Web Vitals.

A seguir vai descobrir o que é realmente o TTFB, os quatro componentes que o constituem e como reduzi-lo para um nível em que o seu site entrega o primeiro byte mais rápido do que um pestanejar.

💡 Visão geral rápida:

  • Compreenda o que é o TTFB e porque é que cada segundo deste atraso se multiplica em cada ação do visitante.
  • Percorra a cadeia de quatro fatores: DNS, servidor, plugins do WordPress e caching de HTML.
  • Compare quatro cenários com medições reais do Pingdom, desde 150 ms até uns catastróficos 4,2 segundos.
  • Ative o caching de HTML e veja como um único plugin reduz drasticamente o TTFB sem mudar de alojamento.

O que é o TTFB e porque afeta tudo

A definição formal da Wikipedia: TTFB é o tempo desde o envio de um pedido HTTP até à receção do primeiro byte da resposta no browser do cliente. Inclui a latência da ligação de socket, o tempo de transmissão do pedido e o tempo de processamento do servidor.

Em termos mais simples: o TTFB é a pausa entre «clicar num link» e «algo começar a acontecer no site». Em termos de jogo, é a latência, o ping, o atraso antes da primeira resposta. Os utilizadores não veem cabeçalho, nem menu, nem indicador de carregamento, apenas um separador vazio. Quanto maior for esta pausa, maior a probabilidade de fecharem o separador.

Uma nuance importante: o TTFB afeta mais do que apenas o carregamento inicial da página. Cada navegação interna, cada clique num link de menu, cada clique numa imagem dentro de um artigo, cada um é um pedido HTTP separado com o seu próprio TTFB. Uma pontuação fraca multiplica-se em cada ação do leitor.

Quatro fatores que compõem o TTFB

O TTFB não é uma métrica única, mas sim a soma dos atrasos em cada etapa da cadeia «utilizador → site». Todos os quatro elos funcionam sequencialmente: se um abrandar, o resultado final também abranda. Vamos examinar cada um.

DNS: o primeiro ponto de controlo

O browser não sabe onde o seu servidor está fisicamente localizado até que o DNS converta o domínio num endereço IP. Bons servidores DNS com uma rede distribuída de nós fazem isto em milissegundos, enquanto os maus acrescentam dezenas ou centenas de milissegundos a cada carregamento de página.

Mínimo prático: utilize a Cloudflare ou um serviço semelhante com caching global de DNS. Após o primeiro pedido, o endereço permanece em cache e a latência do DNS desaparece completamente nos pedidos subsequentes.

Servidor e PHP: o que acontece no alojamento

Cada pedido a uma página WordPress não armazenada em cache inicia o interpretador de PHP. O servidor carrega o núcleo, o tema e os plugins ativos, executa o seu código e só depois entrega o HTML. As versões modernas de PHP lidam com este ciclo muito mais rapidamente do que as versões de há uma década, para não falar de ramos completamente desatualizados.

Dois parâmetros de alojamento determinam a velocidade: a versão do PHP e o tempo de CPU atribuído ao seu plano. Alojamento partilhado barato com dezenas de sites num servidor e PHP desatualizado é um caminho garantido para um TTFB > 1 segundo. O alojamento WordPress especializado com PHP 8.2+ e caching integrado ao nível do servidor apresenta números fundamentalmente diferentes.

Plugins e tema do WordPress

O WordPress monta páginas a partir de dezenas de ficheiros PHP e cada plugin ativo adiciona o seu código a este processo. Dez plugins de qualidade de programadores reputados podem mal afetar o TTFB. Um plugin mal escrito que faça três consultas extra à base de dados em cada pedido pode arruinar a velocidade de todo o seu site.

Eis um exemplo de um conjunto de plugins sensato, tudo o necessário, nada a mais:

Lista de plugins do WordPress no painel de administração com número ideal

E esta já é uma configuração potencialmente problemática. Várias dezenas de plugins ativos, e o servidor tem de processar cada um ao gerar a página:

Lista longa de plugins do WordPress a atrasar a resposta do servidor

Na prática, mais de 30 plugins ativos quase garantem um TTFB elevado, mesmo num bom alojamento. A regra é simples: cada plugin deve desempenhar uma tarefa específica que não possa ser resolvida de outra forma. Tudo o que está lá «por precaução» deve ser removido.

Caching de HTML: a principal alavanca

O fator mais poderoso de todos. Um plugin de cache como o Cache Enabler guarda cópias HTML prontas das páginas no disco do servidor. Quando chega um pedido, o servidor web entrega um ficheiro estático, ignorando toda a pilha de PHP e WordPress.

O resultado: o servidor deixa de precisar de carregar o núcleo, o tema e os plugins para cada visitante. Apenas o próprio servidor web (nginx ou Apache) serve o conteúdo diretamente. É por isto que a cache proporciona a redução mais significativa do TTFB, por fatores e não por percentagens. Abordámos por que razão o nginx é mais eficiente do que o Apache para esta tarefa num artigo separado.

TTFB na prática: quatro cenários

Passemos a medições reais. Abaixo estão os resultados de testes para diferentes combinações de sites e servidores, obtidos através do Pingdom Tools. Cada cenário mostra o TTFB para as versões sem cache e com cache.

Site lento num servidor lento

A pior combinação possível: um site com dezenas de plugins e sem cache num alojamento partilhado antigo com PHP 5.4.

Resultado do teste Pingdom para site lento em servidor lento

Vamos expandir os detalhes do primeiro pedido, onde se pode ver o servidor a pensar durante uma eternidade:

Análise de TTFB a mostrar 4,2 segundos no Pingdom para site não otimizado

O TTFB é de 4,2 segundos. Quatro segundos do utilizador a olhar para um ecrã em branco antes de o navegador receber quaisquer dados. Some o tempo de renderização da página a isto, e o tempo total de espera até o site estar pronto atinge facilmente os sete segundos. Ter a Cloudflare à frente não ajuda aqui: o problema é mais profundo, ao nível do alojamento e do código do site.

Site rápido num servidor médio

Mudança de condições: um site com o mínimo de plugins, servidor em Apache com uma versão de PHP padrão, sem cache.

Medição de TTFB de site rápido em alojamento médio sem cache

Resultado: 521 ms. Já é 8 vezes melhor do que o primeiro cenário. Meio segundo até ao primeiro byte, aceitável para a maioria dos sites. Agora vamos ativar a cache:

TTFB de 152 ms após ativar cache em servidor médio

O TTFB desce para 152 ms. Até um alojamento médio com cache devidamente configurada oferece resultados excelentes.

Site lento num servidor rápido

A situação inversa: um servidor otimizado em Plesk com nginx e uma versão de PHP padrão, mas um site sobrecarregado de plugins.

Servidor rápido não salva site lento sem cache

Sem cache, o servidor rápido ainda gasta 1,29 segundos a processar o site pesado. Um bom alojamento atenua, mas não resolve, o problema de um WordPress mal otimizado.

O mesmo site lento com cache mostrou TTFB de 400 ms

Ative a cache e o TTFB desce para 400 ms. Uma diferença de mais de três vezes.

Site rápido num servidor rápido

O cenário ideal: um site leve num bom alojamento.

Site rápido em servidor rápido sem cache

Sem cache, o servidor entrega o primeiro byte em menos de 500 ms. Adicione a cache:

Melhor resultado de TTFB abaixo de 150 ms em servidor rápido com cache

Resultado: menos de 150 ms. Resposta praticamente instantânea.

Resumo dos resultados

Os quatro cenários num único gráfico:

Gráfico comparativo de TTFB para quatro combinações de site e alojamento

A conclusão destas medições é clara: o alojamento é importante, mas o que faz com o site em si afeta mais o TTFB. Um servidor rápido com cache consegue puxar até um site problemático para uns aceitáveis 400 ms, enquanto um servidor lento sem cache afunda até um WordPress leve.

Como melhorar o TTFB: plano passo a passo

A otimização avança do simples para o complexo, do que demora cinco minutos e produz o máximo impacto, para os ajustes mais finos.

Passo 1: ativar a cache HTML. Instale o Cache Enabler gratuito ou um plugin de cache semelhante. Esta única ação reduz drasticamente o TTFB em qualquer alojamento. Sem exagero, é o maior retorno por minuto de esforço em toda a otimização WordPress.

Passo 2: verifique a sua versão do PHP. No painel de administração do seu alojamento ou no cPanel, localize a definição da versão do PHP. Se estiver disponível uma versão atual (8.2 ou mais recente), mude para ela. A transição de um ramo desatualizado para um moderno acelera notoriamente o processamento de cada pedido. Antes de mudar, certifique-se de que o seu tema e todos os plugins são compatíveis com a versão escolhida.

Passo 3: faça uma auditoria aos seus plugins. Desative tudo o que não estiver em uso ativo neste momento. Mantenha apenas os plugins que resolvem uma tarefa específica. Todo o resto deve ser eliminado, e não apenas desativado. Os plugins mantidos «para uso futuro» ou «que podem dar jeito» adicionam código a cada pedido, quer os use ou não.

Passo 4: escolha um tema rápido. O tema determina a quantidade de código PHP executado em cada carregamento de página. Temas pesados com construtores de páginas visuais geram significativamente mais trabalho no servidor do que soluções minimalistas. Se um teste de TTFB numa instalação limpa do WordPress (sem plugins, tema padrão) mostrar um bom resultado, mas a pontuação cair drasticamente após ativar o seu tema, o problema está no próprio tema.

Passo 5: avalie o seu alojamento. Se o TTFB ainda exceder 500-800 ms após os primeiros quatro passos, a limitação está do lado do alojamento. Um alojamento WordPress especializado, com nginx, PHP 8.2+ e cache do lado do servidor, oferece um nível de resposta fundamentalmente diferente. Ao escolher, procure por cache de objetos integrada (Redis ou Memcached), que é o nível seguinte após a cache HTML.

Vídeo: TTFB da teoria aos resultados

Veja uma análise visual do TTFB com medições ao vivo antes e depois da otimização:

⁉️🤔 Perguntas frequentes

Que TTFB é considerado bom para WordPress?

Use os valores-alvo do Google Core Web Vitals como guia: até 800 ms é aceitável, até 500 ms é bom, até 200 ms é excelente. Na prática, para um site WordPress com cache, o intervalo alcançável é de 100-400 ms. Sem cache, mesmo um site rápido raramente desce abaixo dos 400-500 ms.

É obrigatório mudar de alojamento para melhorar o TTFB?

Nem sempre. A cache HTML reduz drasticamente o TTFB, mesmo num alojamento mediano. Antes de migrar, ative a cache, atualize o PHP para uma versão atual e limpe os plugins. Se o TTFB ainda estiver acima de 800 ms depois disso, então está realmente na hora de mudar de alojamento.

Porque é que o TTFB varia de medição para medição?

O TTFB é afetado pela carga do CPU do servidor no momento da medição, pela latência da rede e pela geografia do servidor de teste. Faça uma série de 5-7 medições e use a mediana, não o primeiro valor aleatório. Teste a partir de vários locais: um servidor na Europa pode mostrar um TTFB excelente a partir de Frankfurt, mas fraco a partir de Tóquio.

O TTFB afeta os rankings do Google?

Sim, a partir de 2025, a capacidade de resposta do servidor faz parte dos Core Web Vitals como um sinal de ranking. O impacto direto é moderado, mas o impacto indireto é significativo: um TTFB elevado aumenta a taxa de rejeição, e uma taxa de rejeição elevada prejudica diretamente os rankings.

Posso medir o TTFB gratuitamente?

Sim. Use o Pingdom Tools, GTmetrix, PageSpeed Insights ou WebPageTest. Nuance importante: meça especificamente o TTFB (tempo até ao primeiro byte), e não o tempo total de carregamento da página. No Pingdom, precisa de expandir os detalhes do primeiro pedido ao site para isso.

O que fazer em relação ao TTFB agora mesmo

A principal conclusão das medições acima: a cache HTML é a alavanca mais poderosa e simples. Um único plugin reduz drasticamente o TTFB em qualquer alojamento, e demora exatamente cinco minutos.

A ordem das ações é a seguinte:

  • Se o TTFB for superior a 1 segundo, comece com a cache e a atualização do PHP. Estes dois passos proporcionam a maior parte da melhoria possível.
  • Se o TTFB estiver entre 400 e 800 ms, uma auditoria de plugins e do tema geralmente elimina o atraso restante.
  • Se o TTFB estiver consistentemente abaixo de 200 ms, está na zona ideal; mantenha o nível atual.

Comece com um plugin de cache gratuito: instale, ative e execute um teste através do Pingdom Tools. Verá a diferença imediatamente. Qual é o seu TTFB atual? Partilhe os seus números nos comentários.