Performance

TTFB e tempo de resposta do servidor: porque o site é lento antes de carregar

A maioria dos diagnósticos de "site lento" foca-se em imagens, JavaScript e fontes. Tudo importante — mas inúteis se o problema é mais à frente na cadeia. Antes do navegador receber um único byte de HTML, o servidor já demorou. Esse atraso chama-se TTFB, e em muitos sites portugueses é o maior pedaço do LCP.

Este guia explica o que afeta o TTFB, como medir, e os passos para baixar dos 800ms típicos do alojamento partilhado para os 100-200ms do alojamento decente.

O que é o TTFB

TTFB — Time To First Byte — é o tempo entre o navegador pedir a página e receber o primeiro byte da resposta. Inclui:

  1. DNS lookup — converter teusite.pt em IP.
  2. TCP handshake — estabelecer ligação.
  3. TLS handshake — negociação HTTPS.
  4. Tempo do servidor — processar o pedido (PHP a correr, queries à base de dados, render).
  5. Latência de rede — bytes a viajar de volta.

Para o Google, os limiares de TTFB são:

  • Bom: < 800 ms.
  • Precisa melhoria: 800-1.800 ms.
  • Mau: > 1.800 ms.

Atenção: estes números são generosos. Sites bem feitos têm TTFB <300ms. Se tens 800ms, estás no limite "aceitável" — não no "bom".

Porque é que TTFB importa tanto para o LCP

LCP (Largest Contentful Paint) tem um limite "bom" de 2.5 segundos. Se o TTFB sozinho consome 1.5s, sobra-te 1s para descarregar HTML, CSS, JS, render, imagem maior. Impossível.

Regra prática: TTFB deve ser ≤ 40% do orçamento LCP. Se LCP alvo é 2.5s, TTFB ≤ 1s. Idealmente <500ms.

Reduzir TTFB é a primeira alavanca para LCP — e é a única que mais nada compensa.

O que afeta o TTFB

1. Alojamento (a maior variável)

Para WordPress, a diferença entre alojamento partilhado low-cost e alojamento decente é dramática:

Tipo de alojamentoTTFB típico (PT, sem cache)
Partilhado low-cost (5-10€/mês)800-2.000 ms
Partilhado decente (15-30€/mês)400-800 ms
Gerido WordPress (30-80€/mês)200-500 ms
VPS bem configurado100-300 ms
Serverless / edge (Vercel, Cloudflare)50-200 ms

O guia como o alojamento afeta a velocidade detalha cada categoria. A escolha aqui define o teto do que podes melhorar com qualquer outra técnica.

2. Localização do servidor

Servidor em Lisboa para visitantes em Portugal: ~10-20ms só de latência. Servidor em US East para visitantes em Portugal: ~120-150ms só de latência — antes do servidor sequer começar a processar.

Para PME portuguesa, prefere servidor em Lisboa, Madrid, ou Frankfurt. Cloudflare ou outro CDN à frente normaliza isto.

3. Cache (faz mais diferença do que comprar alojamento melhor)

Sem cache, cada pedido faz o WordPress correr todo o ciclo (PHP, queries, render). Com cache de página, o servidor devolve HTML pré-gerado em 50-100ms.

Tipos:

  • Page cache (HTML servido como ficheiro estático) — corta TTFB para 50-150ms.
  • Object cache (Redis, Memcached) — cache de queries à BD. Útil para dashboard, checkout, áreas dinâmicas.
  • OPcache (PHP) — cache de bytecode compilado. Quase sempre ativo, confirma.

Plugins WordPress de cache: WP Rocket (60€/ano, simples), W3 Total Cache (grátis, complexo), LiteSpeed Cache (grátis, exige servidor LiteSpeed). Ver cache e CDN WordPress.

4. Queries à base de dados

Plugins mal feitos fazem 50-200 queries por pedido. WordPress core e tema decente: 15-30. Cada query lenta pode adicionar 50-500ms.

Diagnóstico: plugin Query Monitor (grátis). Vê queries lentas, queries duplicadas, e que plugin as causa.

Tratamento:

  • Apagar plugins que disparam queries em todas as páginas mesmo sem usar.
  • Adicionar índices à BD nas colunas mais consultadas (com cuidado — pede a um dev).
  • Limpar BD: revisões antigas, postmeta órfão, transients expirados. Plugin WP-Optimize ajuda.

5. Versão do PHP

PHP 7.4 → PHP 8.3 melhora performance ~15-25% em workloads WordPress típicos. PHP 5.6 (ainda comum em alojamentos antigos) é 2x mais lento que 8.x e inseguro.

Pergunta ao alojamento qual versão estás a usar. Se <8.0, muda já — é o ganho mais barato existe.

6. CDN à frente do servidor

Para utilizadores longe do servidor, um CDN serve conteúdo cached a partir de edge nodes próximos. Cloudflare grátis cobre Portugal com PoPs em Lisboa e Porto.

CDN não reduz TTFB para conteúdo dinâmico — só para o que pode ser cached. Para HTML cached em Cloudflare (com page rule "Cache Everything"), TTFB cai para 30-80ms global.

Como medir TTFB

Field data (visitantes reais)

  • PageSpeed Insights — secção "Real-user experience" mostra TTFB do CrUX.
  • Search Console — Core Web Vitals (LCP). Se LCP está mau, decompõe.
  • web-vitals.js — biblioteca para medir TTFB com clientes reais.

Lab data (teste pontual)

  • PageSpeed Insights Lab — mostra "Server Response Time" estimado.
  • WebPageTest — waterfall detalhado. Vê quanto tempo cada etapa demora.
  • curl simples:
curl -o /dev/null -w 'TTFB: %{time_starttransfer}s\n' https://teusite.pt

Corre 5 vezes (a primeira pode ter cache frio).

Os 8 passos para reduzir TTFB

Ordenado por relação ganho/esforço:

  1. Cache de página agressivo. Maior ganho por menos esforço. -500ms típico.
  2. Atualizar PHP para 8.x. 15 minutos, ganho permanente.
  3. Limpar plugins esquecidos. Cada um custa queries. -50 a -200ms.
  4. Mover alojamento se está em partilhado low-cost. -400 a -1.000ms.
  5. Cloudflare grátis à frente. TLS handshake mais rápido + edge cache para estáticos.
  6. Object cache (Redis) se alojamento suporta. Para sites dinâmicos (loja com utilizadores logados). -100 a -300ms.
  7. Auditar queries lentas com Query Monitor. -50 a -500ms dependendo do site.
  8. Otimizar base de dados (apagar revisões, transients). -50 a -100ms.

Para a maioria das PMEs portuguesas, passos 1-5 reduzem TTFB de 1.500ms para <500ms em meio dia.

Cuidado com falsos diagnósticos

"O site é lento" raramente é TTFB sozinho. Verifica primeiro com PageSpeed onde é o gargalo:

  • LCP mau + TTFB mau → ataque ao TTFB primeiro.
  • LCP mau + TTFB bom → o problema é imagem hero ou render.
  • INP mau + TTFB bom → o problema é JavaScript após carregamento.

Não otimizes TTFB se o problema é outro. Cada otimização tem custo (configuração, monitorização, complexidade).

TTFB em Next.js / sites custom

Sites Next.js modernos têm vantagens de TTFB:

  • SSG (Static Site Generation) — páginas pré-renderizadas em build. TTFB de 50-150ms global via CDN.
  • ISR (Incremental Static Regeneration) — meio-termo entre estático e dinâmico. TTFB próximo de estático.
  • Edge functions — render em PoP próximo do utilizador. <100ms global.

Para Next.js, perguntas relevantes:

  • A página é Server Component ou Client Component? Server é melhor para TTFB.
  • Está em force-static ou dynamic? Static cacheia automaticamente.
  • Tens fetch sem cache (cache: 'no-store')? Estás a forçar dinâmico desnecessariamente?

TTFB em lojas WooCommerce — atenção especial

Lojas online têm um problema específico: carrinho e checkout não podem ser cached. Cada utilizador logado vê dados personalizados (carrinho, conta, descontos aplicáveis). Page cache convencional não funciona.

Tratamento:

  • Object cache (Redis) torna-se obrigatório, não opcional. Reduz queries WooCommerce de 100+ para 20-30 por pedido.
  • Cache fragmentado — partes públicas da página (header, footer, listagem) ficam em cache; partes dinâmicas (mini-carrinho) carregam por AJAX.
  • Edge cache com regras — Cloudflare permite cache de páginas estáticas mas bypass de URLs de carrinho/checkout.

Alojamentos especializados em WooCommerce (Kinsta, WP Engine, Rocket.net) trazem isto out-of-the-box. Custo 30-100€/mês para lojas pequenas, vale a pena quando faturação justifica.

Webfonts não afetam TTFB — mas afetam render

Erro de diagnóstico comum: ver fonte a demorar e chamar TTFB. Fontes carregam depois do HTML — não fazem parte do TTFB. Estão na fase de render. O guia fontes web e velocidade cobre o problema separado.

Confirma sempre na waterfall do WebPageTest qual a fase responsável antes de otimizar.

Reverse proxy e arquitetura — o que pode mudar

Para sites em crescimento, vale considerar arquitetura:

  • Nginx como reverse proxy à frente do Apache — reduz overhead em 20-40%.
  • PHP-FPM bem tunado (max_children, max_requests) — evita esgotamento de processos.
  • HTTP/3 (QUIC) — reduz overhead de TLS handshake. Cloudflare ativa automaticamente.
  • Connection pooling para base de dados — reutiliza ligações em vez de abrir nova por pedido.

Estes ajustes são para sites com mais de ~5.000 visitas/dia. Para PME típica, foca em cache + alojamento decente primeiro.

Em resumo

TTFB é o primeiro pedaço da performance que mais nada compensa. Sites com TTFB >1s não chegam a LCP "bom" mesmo com imagens otimizadas e fontes auto-hospedadas. Para PME portuguesa: cache de página (WP Rocket ou similar), PHP 8.x, alojamento decente (15-30€/mês mínimo, idealmente gerido WordPress), Cloudflare grátis à frente, e auditoria periódica de plugins/queries. Resolves de 1.500ms para <500ms em meio dia. Para projetos novos, considera Next.js + SSG/ISR — TTFB <150ms vem de borla pela arquitetura. Não otimizes o que não dói: diagnostica primeiro com PageSpeed se o problema é mesmo TTFB ou outro.

No sitesfixe.pt construímos sites com TTFB <300ms à partida — alojamento certo, cache configurada, CDN integrado, PHP atualizado. Se o teu site tem TTFB acima de 1s e o LCP foge, fala connosco. Sites desde 1.500€. Manutenção desde 80€/mês.

Lê também:

Fontes

Precisas de um site ou loja online?

Agência digital portuguesa. Sites e lojas online rápidos, otimizados para o Google e feitos para resultado.

Pedir orçamento