TTFB de utilizadores reais (dados de campo)

O que esta verificação faz

Lê o percentil 75 do Time to First Byte a partir do Chrome User Experience Report — o tempo desde o momento em que o navegador de um utilizador real do Chrome envia o pedido de navegação até ao momento em que chega o primeiro byte da resposta. O CrUX agrega isto numa janela contínua de 28 dias. É uma métrica CWV experimental, não um sinal de ranking por si só, mas limita todas as outras métricas de paint: nada mais pode renderizar até o primeiro byte chegar.

TTFB de campo (p75)	Veredicto
≤ 800 ms	Bom
800–1800 ms	Precisa de melhorias
> 1800 ms	Fraco

O TTFB engloba tudo entre utilizador e origem: lookup de DNS, handshake TLS, cadeias de redirecionamentos, enfileiramento de pedidos no teu servidor, trabalho da aplicação e tempo gasto a renderizar templates no servidor. Tudo o que acontece antes de o primeiro byte sair soma a este número.

Porque é importante

O TTFB não é um Core Web Vital, mas é a restrição a montante sobre cada Core Web Vital. Um TTFB de 2 segundos significa que o LCP não pode estar abaixo de 2,5 s — só sobram 500 ms para tudo o resto. Cortar 500 ms ao TTFB tende a cortar uma quantidade semelhante ao LCP, quase de graça.

Também expõe problemas que as ferramentas de laboratório não veem:

• Utilizadores distantes. Um servidor em us-east-1 parece rápido a partir de uma ferramenta de laboratório baseada nos EUA, terrível para um utilizador brasileiro. O TTFB de campo mostra-te a realidade geográfica.
• Estados frios de servidor. Se a tua origem corre funções serverless, a latência de cold-start só aparece nos dados de utilizadores reais; as ferramentas de laboratório aquecem a cache por ti.
• Cadeias de redirecionamentos. Um 301 de example.com → www.example.com → https://www.example.com/ adiciona uma volta completa por cada salto ao TTFB. As ferramentas de laboratório ou saltam estes ou reportam-nos de outra forma.

Como melhorar

1. Coloca um CDN à frente da tua origem. Mesmo para páginas dinâmicas, um CDN pode fazer cache de sessões TLS e estado de ligação. Cloudflare, Fastly, Bunny e Vercel Edge têm todos planos gratuitos ou quase gratuitos:

# Proxy do Cloudflare ligado (nuvem laranja) — CDN instantâneo
# nslookup ao teu domínio — deves ver IPs do Cloudflare, não da tua origem

2. Faz cache do HTML na edge. Para páginas que não precisam de ser por-utilizador (marketing, blog, docs), define Cache-Control: s-maxage=86400, stale-while-revalidate=604800 para que o CDN devolva HTML em cache em menos de 50 ms:

Cache-Control: public, s-maxage=86400, stale-while-revalidate=604800

A diretiva stale-while-revalidate permite ao CDN servir uma resposta stale instantaneamente enquanto revalida em segundo plano — o melhor dos dois mundos.

3. Elimina cadeias de redirecionamentos. Audita com curl:

curl -sIL https://example.com/ | grep -E "^(HTTP|Location)"

Cada linha Location: é uma volta extra. Infratores comuns: http→https, apex→www (ou www→apex) e diferenças de barra final. Colapsa-os para um único 301 sempre que possível.

4. Faz profile do teu servidor com Server-Timing. Adiciona cabeçalhos de resposta que digam às DevTools onde foi o tempo:

// Exemplo Express/Node
res.setHeader("Server-Timing", "db;dur=120, render;dur=45, total;dur=170");

O separador Network do Chrome vai mostrar uma decomposição por fase para veres se o tempo está em queries de BD, rendering de templates ou overhead da framework.

5. Usa HTTP/2 ou HTTP/3. O slow-start do TCP e o head-of-line blocking em HTTP/1.1 custam TTFB real. Todos os CDN modernos usam HTTP/2 por defeito; muitos já servem HTTP/3 (QUIC) para melhor desempenho em redes móveis.

6. Corta distância à origem. Se tens uma origem numa única região e utilizadores globais, considera replicar ou mudar para uma framework renderizada na edge (Astro, Next.js no Vercel, SvelteKit em Cloudflare Workers).

Perguntas frequentes

O meu TTFB é rápido na minha máquina de desenvolvimento mas lento no CrUX. Porquê?

Estás co-localizado com a tua origem; os teus utilizadores reais não estão. Adiciona um CDN e os teus utilizadores globais verão um TTFB mais próximo da tua experiência em dev. A outra causa comum é a latência de cold-start em deployments serverless — o teu primeiro pedido depois de ocioso paga uma penalidade de 500 a 2000 ms.

Devo preocupar-me com o TTFB se está etiquetado como “experimental” no CrUX?

Sim. É experimental no sentido em que o Google ainda não o tornou um Core Web Vital formal, mas o valor está bem definido e os limiares são estáveis. Trata-o como um indicador avançado para o teu LCP — se o TTFB é fraco, o LCP quase de certeza também será.

O meu TTFB é bom mas o LCP é fraco. O que se passa?

O gargalo está a jusante: rendering, carregamento de imagens ou recursos que bloqueiam o rendering. Vê a regra do LCP a seguir. TTFB de campo + bom LCP significa que o teu servidor é rápido e a lentidão está no cliente; TTFB de campo fraco + LCP fraco significa corrigir primeiro o TTFB porque cada correção lá compõe-se em melhorias gratuitas no LCP.