TTFB: Reduzir Tempo de Servidor (2026)

Q: O que é um bom TTFB em 2026?

O Google considera bom um TTFB abaixo de 800 ms no percentil 75 dos usuários reais. Para LCP < 2,5 s em redes móveis, o ideal é manter TTFB abaixo de 400 ms, e sites de alta performance buscam menos de 200 ms para hits de cache de borda.

Q: TTFB é um Core Web Vital?

Não. TTFB é uma métrica de diagnóstico mantida pelo time do Chrome, mas não entra diretamente no algoritmo de Core Web Vitals. Ainda assim, ele é o teto inferior do LCP, que é Core Web Vital. Então um TTFB ruim derruba seu LCP e indiretamente prejudica SEO.

Q: Como o CDN reduz o TTFB?

Um CDN reduz TTFB de duas formas: serve respostas em cache a partir do ponto de presença mais próximo do usuário (cortando latência de rede de 200 ms para 20 ms) e termina TLS na borda, encurtando o handshake. Em hits de cache, é comum ver TTFB de 30–80 ms em qualquer continente.

Q: Qual a diferença entre TTFB e tempo de resposta do servidor?

Tempo de resposta do servidor (server response time) é apenas o intervalo entre o servidor receber a requisição e enviar o primeiro byte. É uma das componentes do TTFB. O TTFB inclui também DNS, TCP, TLS e qualquer redirect anterior, então é sempre maior que o tempo puro de servidor.

Q: Posso medir TTFB com Lighthouse?

Lighthouse mostra TTFB sob "Server response time" na auditoria, mas é uma medida de laboratório com rede simulada e apenas uma execução. Para decisões de produção, use a API web-vitals no campo, o Chrome UX Report para comparar com concorrentes e Server-Timing para isolar o tempo de servidor.

Atualizado: 16 de junho de 2026

O TTFB (Time to First Byte) é o tempo, em milissegundos, entre o navegador iniciar a requisição e receber o primeiro byte do HTML. Em 2026, o Google considera bom qualquer valor abaixo de 800 ms e ruim acima de 1800 ms. Mas se você quer competir por um LCP abaixo de 2,5 s, seu TTFB precisa ficar idealmente abaixo de 200 ms. Reduzir o TTFB significa atacar três frentes: rede (DNS, TCP, TLS), processamento no servidor (queries, render) e cache (CDN, HTTP, Early Hints). Este guia mostra como diagnosticar e cortar cada uma, com exemplos que eu mesmo usei em consultorias de e-commerce e SaaS.

TTFB < 800 ms é considerado "bom" pelo Google; abaixo de 200 ms é o que sites de alta performance buscam para vencer o LCP.
Cerca de 40% do TTFB típico vem da rede (DNS + TCP + TLS). Um CDN com PoPs próximos do usuário corta isso quase pela metade.
Cache HTTP de página inteira (Cache-Control: s-maxage) na borda transforma TTFB de 600 ms em 30 ms para hits de cache.
O cabeçalho 103 Early Hints permite enviar preload e preconnect antes da resposta final, economizando 200–400 ms no LCP.
HTTP/3 (QUIC) reduz o handshake de 2-RTT para 1-RTT (ou 0-RTT em reconexões), cortando 100–200 ms em redes móveis.
Meça TTFB em produção com a API PerformanceNavigationTiming e o pacote web-vitals, não só com Lighthouse de laboratório.

O que é TTFB e como ele é medido

TTFB (Time to First Byte) é o intervalo entre o momento em que o navegador inicia uma navegação e o instante em que o primeiro byte da resposta HTML chega. Ele engloba toda a cadeia de rede e processamento: redirecionamentos, DNS lookup, conexão TCP, negociação TLS, envio da requisição, processamento no servidor (incluindo banco de dados, renderização e middleware) e o início da resposta. Formalmente, segundo a especificação Navigation Timing Level 2 do W3C, TTFB equivale a responseStart - startTime da entrada PerformanceNavigationTiming.

Vale lembrar que TTFB não é um Core Web Vital oficial, mas é precursor direto de FCP, LCP e até INP. Se o servidor leva 1,2 s para começar a responder, não tem como atingir LCP em 2,5 s sem mágica. Por isso a equipe do Chrome publicou em 2022 um limiar dedicado, e o time do web-vitals.js mantém a métrica desde a versão 3.

Há duas variantes que você verá em ferramentas: o TTFB de navegação (página inteira, contado a partir do clique) e o TTFB de subrecursos (cada CSS, JS e imagem tem o seu). Quando falamos sobre Core Web Vitals e SEO, é sempre o de navegação.

O que é considerado um bom TTFB em 2026?

O Google define três faixas para TTFB de navegação, conforme medidas no campo (RUM) e no Chrome UX Report:

Faixa	TTFB (p75 do usuário)	Significado
Bom	< 800 ms	Não atrapalha LCP nem Core Web Vitals
Precisa melhorar	800 ms – 1800 ms	Provavelmente impede LCP < 2,5 s em 4G
Ruim	> 1800 ms	Falha quase certa em LCP e percepção de lentidão

Estes valores se referem ao percentil 75 dos seus usuários reais, não à média. Na prática, sites de e-commerce competitivo trabalham com metas mais agressivas: TTFB < 200 ms para hits de cache de borda e < 600 ms para misses. Times de mídia, blogs e SaaS B2B costumam aceitar 500–800 ms porque a maioria das visitas é autenticada e personalizada.

Note que o limiar de 800 ms é generoso porque inclui o pior cenário (3G+ em região remota). Se a sua audiência está em centros urbanos com fibra, 400 ms já compromete o LCP em páginas com hero image pesado.

O TTFB afeta SEO e Core Web Vitals?

Sim, o TTFB afeta o SEO de forma indireta, mas significativa. Embora não seja um sinal de ranking direto, ele é o teto inferior do LCP, e LCP é Core Web Vital oficial usado no algoritmo. Se o seu TTFB no percentil 75 está em 1,5 s, simplesmente não há como sua página atingir o limiar verde de 2,5 s para LCP, porque sobrariam apenas 1 s para baixar HTML, descobrir o recurso LCP, baixá-lo e pintá-lo. Em redes móveis típicas isso é matematicamente impossível.

Além disso, TTFB elevado afeta a experiência percebida de duas formas que o Googlebot também mede. Páginas que demoram a responder consomem mais quota de rastreamento e disparam timeouts no rastreador móvel após cerca de 30 segundos. Sites com TTFB acima de 3 s frequentemente têm páginas profundas que nunca chegam a ser indexadas.

Para entender como o TTFB se conecta às outras métricas, recomendo nosso guia completo de LCP, que detalha as quatro subpartes do LCP. A primeira é exatamente o tempo de resposta do servidor.

Como medir o TTFB em produção

Existem três métodos complementares. Use todos os três: laboratório para reproduzir, RUM para validar com usuários reais e CrUX para comparar com concorrentes.

1. Medição via JavaScript com a API web-vitals

A biblioteca oficial web-vitals (versão 4+) já implementa TTFB seguindo a definição do Chrome:

import { onTTFB } from 'web-vitals';

onTTFB((metric) => {
  // metric.value = TTFB em ms
  // metric.rating = 'good' | 'needs-improvement' | 'poor'
  navigator.sendBeacon('/api/rum', JSON.stringify({
    name: 'TTFB',
    value: metric.value,
    rating: metric.rating,
    id: metric.id,
    navType: metric.navigationType,
  }));
});

2. Medição direta com PerformanceNavigationTiming

Se você não quer adicionar uma dependência:

const [entry] = performance.getEntriesByType('navigation');
const ttfb = entry.responseStart - entry.startTime;
console.log(`TTFB: ${ttfb.toFixed(0)} ms`);

// Decomposição completa
console.log({
  redirect: entry.redirectEnd - entry.redirectStart,
  dns: entry.domainLookupEnd - entry.domainLookupStart,
  tcp: entry.connectEnd - entry.connectStart,
  tls: entry.connectEnd - entry.secureConnectionStart,
  request: entry.responseStart - entry.requestStart,
});

3. Server-Timing para isolar tempo de servidor

Adicione no servidor o cabeçalho Server-Timing para enxergar exatamente quanto tempo cada camada consome. Honestamente, foi o que destravou meu último projeto: até instrumentar, eu culpava o Postgres, mas o vilão era um middleware de auth bobo.

// Express.js
app.use((req, res, next) => {
  const start = process.hrtime.bigint();
  res.on('finish', () => {
    const ms = Number(process.hrtime.bigint() - start) / 1e6;
    res.setHeader('Server-Timing', `app;dur=${ms.toFixed(1)}`);
  });
  next();
});

O Chrome DevTools exibe Server-Timing automaticamente na aba Network, e PerformanceNavigationTiming.serverTiming expõe os valores para análise programática.

Anatomia do TTFB: DNS, TCP, TLS e tempo de servidor

Para reduzir TTFB sem perder tempo, você precisa primeiro entender de onde os milissegundos vêm. Em uma navegação típica para um servidor de origem na mesma região, sem CDN, a quebra é mais ou menos esta:

DNS: 20–120 ms (depende do TTL, da localização e se o resolver tem cache)
TCP handshake: 1 RTT (≈ 30–80 ms em fibra; 100–200 ms em 4G)
TLS 1.3 handshake: 1 RTT adicional (≈ 30–80 ms; 0-RTT em sessões reativadas)
Server processing: variável. Pode ser 20 ms (estático em cache) ou 2 s (SSR com banco frio).
Time to first byte da resposta: depende do tamanho do TCP window e do throughput

Em 4G típico, só DNS + TCP + TLS já somam 300–500 ms antes do servidor receber a primeira requisição. É por isso que CDNs e preconnect têm impacto desproporcional.

Como reduzir o TTFB: 10 técnicas comprovadas

1. Sirva HTML cacheado na borda (CDN)

É a alavanca mais poderosa. Configure cache de página em sua CDN com Cache-Control: public, max-age=60, s-maxage=300, stale-while-revalidate=86400. O resultado típico é TTFB de 30–80 ms em qualquer continente, contra 400–1200 ms da origem.

2. Migre para HTTP/3 (QUIC)

HTTP/3 elimina o head-of-line blocking do TCP e reduz o handshake para 1 RTT (0-RTT em reconexões). Cloudflare, Fastly, Vercel Edge e CloudFront já oferecem com um toggle. Ganho médio: 50–150 ms em móvel. Você pode validar o suporte do seu host pelo HTTP/3 Check antes de virar o tráfego.

3. Use TLS 1.3 com session resumption

Garanta que seu servidor (ou CDN) negocia TLS 1.3 e ativa 0-RTT. Verifique com openssl s_client -connect seu-site.com:443 -tls1_3.

4. Reduza o tempo de processamento do servidor

Isole com Server-Timing e ataque o gargalo. Os culpados mais comuns são:

Queries N+1 no ORM. Use include/JOIN ou dataloader.
Chamadas síncronas a APIs externas no caminho do render.
Hidratação de sessão em todas as requisições. Mova para cookie assinado.
Compilação ou parsing de template em cada request. Pré-compile no build.

5. Adote streaming SSR

Frameworks como Next.js 15, Remix e SvelteKit suportam streaming. O servidor envia o <head> e o shell antes de o banco responder, então o TTFB cai bastante porque o primeiro byte vem em ~50 ms enquanto o resto é renderizado e empurrado depois.

6. Cache de banco de dados (Redis / Memcached)

Para conteúdo que muda raramente, cacheie o resultado da query, não da página. Ganho típico: 50–300 ms.

7. Use Edge Functions para personalização leve

Em vez de quebrar o cache para A/B testing, decida na borda com Cloudflare Workers, Vercel Edge Middleware ou Fastly Compute. O HTML continua em cache, e o middleware injeta variantes em tempo de borda.

8. Implemente 103 Early Hints

Veja a próxima seção dedicada. Vale uma seção inteira.

9. Comprima respostas com Brotli

Brotli reduz o tamanho do HTML em ~15% comparado a gzip, o que diminui o tempo entre o primeiro byte e o byte útil (afeta FCP, não TTFB direto, mas a percepção combina).

10. Pre-conecte a origens críticas

Use <link rel="preconnect" href="https://cdn.example.com" crossorigin> no HTML para abrir DNS + TCP + TLS em paralelo com o parsing. Para fontes e APIs principais, isso corta 150–300 ms do tempo de chegada do primeiro byte do recurso.

CDN e cache de borda: a maior alavanca

Se seu TTFB do percentil 75 está acima de 600 ms e você ainda não tem CDN com cache de página, pare de ler este artigo e configure isso primeiro. Sério. Nenhuma otimização de banco, framework ou linguagem chega perto do impacto de mover o HTML para 200+ pontos de presença distribuídos.

O padrão moderno (2026) é o seguinte cabeçalho de resposta:

Cache-Control: public,
  max-age=0,
  s-maxage=300,
  stale-while-revalidate=86400,
  stale-if-error=604800

Explicação rápida: max-age=0 impede o navegador de cachear (você quer atualizações imediatas no usuário); s-maxage=300 permite que a CDN sirva por 5 min; stale-while-revalidate=86400 serve cache velho enquanto revalida em background por até 24 h; stale-if-error mantém o site no ar se a origem cair. A semântica de cada diretiva está formalizada em RFC 9111.

Para conteúdo personalizado, use chave de cache segmentada: a CDN guarda variantes por país, dispositivo ou bucket de A/B. Cloudflare Cache API, Fastly VCL e Akamai EdgeWorkers permitem definir a chave programaticamente.

Se o seu caso de uso exige navegação instantânea entre páginas após o primeiro carregamento, combine cache de borda com a Speculation Rules API e bfcache. Esse trio elimina praticamente o TTFB perceptível em navegações subsequentes.

103 Early Hints: o segredo subutilizado

O status HTTP 103 Early Hints, padronizado em RFC 8297, permite que o servidor envie cabeçalhos antes da resposta final estar pronta. Isso significa que o navegador pode começar a preconectar e pré-carregar recursos críticos enquanto o servidor ainda está consultando o banco.

Exemplo de resposta com Early Hints:

HTTP/2 103 Early Hints
Link: </css/critical.css>; rel=preload; as=style
Link: </fonts/inter-var.woff2>; rel=preload; as=font; crossorigin
Link: <https://api.example.com>; rel=preconnect

HTTP/2 200 OK
Content-Type: text/html; charset=utf-8
...

Implementação em Node.js (Fastify suporta nativamente desde v4):

fastify.get('/', async (request, reply) => {
  reply.writeEarlyHints({
    Link: [
      '</css/critical.css>; rel=preload; as=style',
      '</fonts/inter-var.woff2>; rel=preload; as=font; crossorigin',
    ],
  });

  const data = await db.query('SELECT * FROM posts LIMIT 10');
  return reply.view('home', { posts: data });
});

Cloudflare, Fastly e Vercel já intermediam 103 automaticamente. Em testes da Shopify, Early Hints reduziu LCP em 20–30% em páginas com TTFB alto, porque o tempo "perdido" no servidor passa a ser usado pelo navegador para baixar CSS e fontes.

TTFB vs FCP vs LCP: qual a diferença?

É comum confundir essas três métricas. Esta tabela esclarece:

Métrica	O que mede	Bom (p75)	Quem controla
TTFB	Primeiro byte do HTML recebido	< 800 ms	Servidor + rede
FCP	Primeiro pixel pintado (qualquer conteúdo)	< 1,8 s	HTML + CSS + recursos críticos
LCP	Maior elemento visível pintado	< 2,5 s	Recurso principal (imagem/herói)

Pense em cascata: TTFB precisa terminar antes do FCP começar, e FCP geralmente acontece antes do LCP. Otimizar LCP sem antes verificar TTFB é como tentar reduzir o tempo total de uma viagem só acelerando o último trecho. Você bate em um teto inferior e fica frustrado.

Erros comuns ao otimizar TTFB

Em consultorias de performance, eu vejo os mesmos erros se repetirem (eu mesmo cometi a maioria deles antes de aprender):

Medir TTFB só no Lighthouse. Lighthouse roda em rede simulada de um único ponto. Use CrUX, RUM e web-vitals em produção.
Aplicar max-age agressivo no navegador. Isso quebra atualizações; use s-maxage apenas.
Confundir cache miss com problema de servidor. Sempre cheque cf-cache-status ou equivalente antes de culpar o backend.
Ignorar redirects 30x. Cada redirect adiciona 100–300 ms ao TTFB. Configure HSTS, redirect 301 direto para HTTPS e elimine cadeias.
Não usar preconnect para a origem de fontes. Google Fonts e fontes próprias precisam de preconnect ou perdem 200 ms.
Servir HTML não comprimido. Confira content-encoding: br ou gzip na resposta.
SSR sem timeout no banco. Uma query lenta ocasional vira TTFB de 30 s. Use statement_timeout no Postgres e fallback estático.

Outra otimização frequentemente esquecida é o caminho de imagem do herói. Mesmo com TTFB perfeito, uma LCP image grande estraga tudo. Vale revisar nosso guia de otimização de imagens para AVIF, srcset e fetchpriority.

Perguntas Frequentes

O que é um bom TTFB em 2026?