Tempo de resposta do servidor

O que esta verificação faz

Mede quanto tempo o servidor demora a devolver o primeiro byte do documento HTML — o TTFB. O cronómetro começa quando o crawler do MetricSpot envia o pedido e para quando chega o primeiro byte da resposta. DNS, TCP, TLS e processamento no servidor estão todos incluídos.

A verificação passa abaixo de 800 ms (o limiar “good” da web.dev) e avisa acima de 1,8 s.

Porque é importante

O TTFB é um teto para todos os outros Core Web Vitals. O Largest Contentful Paint (LCP) não pode ser melhor que TTFB + tempo de render — se o servidor demora 2 segundos a responder, o LCP é matematicamente pelo menos 2 segundos, por mais rápido que seja o CSS ou agressiva a otimização de imagens. O limiar “good LCP” do Google é 2,5 s; um TTFB de 2 s deixa-te 500 ms para tudo o resto.

Um TTFB lento aponta normalmente para uma de quatro causas: uma função serverless em cold start, uma query à base de dados no caminho do pedido, ausência de cache na edge, ou um CMS a fazer trabalho que não devia (WordPress sem cache de objetos é o exemplo clássico).

Como corrigir

Primeiro encontra o estrangulamento. Adiciona cabeçalhos Server-Timing para veres onde o tempo se vai:

Server-Timing: db;dur=420, render;dur=180, total;dur=620

Depois ataca a fase maior.

Cache o HTML na edge. Uma resposta estática ou em cache de página devia ser servida em 20-100 ms a partir do POP mais próximo, não em 800 ms a partir da origem.

# nginx — micro-cache de páginas dinâmicas durante 60s
proxy_cache_path /var/cache/nginx levels=1:2 keys_zone=html:50m max_size=1g inactive=10m;

location / {
  proxy_cache html;
  proxy_cache_valid 200 60s;
  proxy_cache_use_stale updating error timeout;
  proxy_cache_lock on;
  proxy_pass http://app;
}

Cloudflare: ativa “Cache Everything” através de uma Cache Rule para HTML e depois define Cache-Control: s-maxage=60, stale-while-revalidate=600 a partir da origem. O stale-while-revalidate é a parte mágica — a Cloudflare serve a cópia desatualizada instantaneamente e atualiza em segundo plano.

Caddy:

example.com {
  reverse_proxy localhost:3000
  header Cache-Control "public, max-age=0, s-maxage=60, stale-while-revalidate=600"
}

Next.js (App Router): prefere geração estática. Se uma página for dinâmica, define a configuração do segmento de rota:

export const revalidate = 60; // ISR
export const dynamic = "force-static"; // quando possível

Para componentes de servidor que acedem à base de dados, envolve o fetch em unstable_cache ou usa fetch(url, { next: { revalidate: 60 } }).

Bun / Node: os ganhos habituais são (a) connection-pool da base de dados (pg.Pool, não um cliente novo por pedido), (b) evitar queries N+1 — um JOIN é melhor que 50 idas e voltas, (c) precomputar tudo o que puderes em tempo de build, (d) gzip/brotli na resposta.

WordPress: instala uma cache de objetos persistente (Redis através do plugin Redis Object Cache) e uma cache de página (WP Super Cache, W3 Total Cache, ou LiteSpeed Cache). Uma instalação vanilla do WP sem cache demora rotineiramente 1-3 s por pedido; com ambas as caches ativas cai abaixo dos 200 ms.

Base de dados: adiciona o índice em falta. Corre EXPLAIN ANALYZE na query mais lenta do caminho do pedido; se disser Seq Scan, precisas de um índice. Um único índice em falta pode ser todo o problema de TTFB.

Latência geográfica: se a tua origem está em Frankfurt e os teus visitantes estão em Singapura, nenhuma quantidade de otimização do servidor resolve os 180 ms de round-trip. Põe uma CDN à frente do HTML (não só das imagens).

Quando o TTFB estiver saudável, trata do Largest Contentful Paint e do Interaction to Next Paint — são a jusante do TTFB e revelam problemas no lado do cliente.

Perguntas frequentes

O TTFB é um Core Web Vital?

Não. O TTFB é uma métrica a montante — o Google não a usa diretamente como sinal de ranking. Mas é o piso para o LCP, esse sim sinal de ranking. Um TTFB mau garante um LCP mau.

Porque é que o MetricSpot mede um TTFB diferente do PageSpeed Insights?

Pontos de medição diferentes. O MetricSpot mede a partir do nosso crawler num único data center. O PSI usa dados de campo (Chrome User Experience Report) quando disponíveis, que são utilizadores reais em todo o mundo em redes reais. Os dados de campo são a verdade; os dados de laboratório são o diagnóstico.

O meu TTFB está bem na homepage mas mau nas páginas de produto — porquê?

A homepage está provavelmente em cache e as páginas de produto não. Ou estendes a cache de página aos URLs de produto (com um TTL curto e invalidação na mudança de stock), ou precomputas as páginas de produto em tempo de build via ISR / revalidação on-demand.