Tempo até o primeiro byte (TTFB)

TL;DR — Time to First Byte é quanto tempo o navegador espera, depois de pedir uma página, antes de o primeiro byte da resposta chegar. É uma medida de responsividade do servidor. Um TTFB bom é de 0,8 segundos ou menos. Não é um Core Web Vital — mas um lento arrasta para baixo as métricas que são, porque nada na página pode começar até que esse primeiro byte apareça.

O que é TTFB

Quando você clica em um link, seu navegador envia uma solicitação a um servidor e então espera. Time to First Byte (TTFB) é a duração dessa espera — do momento em que a solicitação começa até o momento em que o primeiro byte da resposta começa a chegar.

Não é apenas “quão rápido o servidor pensa”. Muita coisa acontece antes de seu navegador sequer falar com a máquina certa: ele pode seguir um redirecionamento, consultar o domínio no DNS, abrir uma conexão e negociar o handshake seguro (TLS). O TTFB engloba tudo isso, depois adiciona o tempo de processamento do próprio servidor e para o cronômetro no primeiro byte de volta.

O que conta como bom

A orientação do web.dev do Google é simples: busque um TTFB de 0,8 segundos ou menos. Acima de 1,8 segundos é considerado ruim. A maioria dos sites deveria conseguir atingir a marca boa — e muitos não conseguem, que é exatamente por isso que vale a pena verificar.

Por que isso importa mesmo não sendo uma métrica “core”

Você vai ouvir muito sobre Core Web Vitals — LCP, INP e CLS. TTFB não é um deles. Mas ele fica por baixo dos que são sobre carregamento: tanto o First Contentful Paint quanto o Largest Contentful Paint incluem o TTFB em sua medição. O navegador não consegue pintar nada até que os bytes comecem a chegar. Então, um TTFB lento coloca um teto em quão rápido sua página pode parecer.

A conclusão prática: o TTFB não faz você ranquear sozinho, mas um ruim segura silenciosamente as métricas que fazem.

As correções usuais, em termos simples

• Use um CDN. Ele coloca uma cópia do seu site em servidores fisicamente mais próximos dos seus visitantes, então a ida e volta é mais curta.
• Cacheie suas páginas. Se o servidor puder devolver uma cópia pronta em vez de reconstruir a página toda vez, o primeiro byte chega muito mais cedo.
• Tenha uma hospedagem melhor. Um servidor e banco de dados mais rápidos é a correção mais direta.
• Corte redirecionamentos. Cada redirecionamento é uma ida e volta extra antes de a página real começar a carregar.

Quer a versão completa — os limites exatos, a relação com LCP, a confusão de limites entre Lighthouse e CrUX, Early Hints e como medir? Mude para a aba Avançado.

TL;DR — TTFB é o tempo desde o início da solicitação até quando o primeiro byte da resposta chega — a soma do tempo de redirecionamento, inicialização do service worker, consulta DNS, conexão + negociação TLS e a própria solicitação, até esse primeiro byte. Não é um Core Web Vital; é uma métrica fundamental e diagnóstica que alimenta FCP e LCP. web.dev: bom é ≤0,8 s, ruim é >1,8 s (percentil 75). É tanto uma métrica de campo quanto de laboratório. A auditoria “Reduza os tempos de resposta do servidor” do Lighthouse é mais estreita — ela sinaliza o tempo do servidor acima de ~600 ms, não o TTFB completo, e a partir do Lighthouse 13 ela fica dentro do insight “Latência da solicitação do documento”. Corrija com CDN, cache de borda/HTML, hospedagem mais rápida, menos redirecionamentos, 103 Early Hints e TLS eficiente. E um TTFB alto nem sempre significa um site lento.

O que o TTFB realmente mede

O TTFB mede o tempo entre começar a navegar para uma página e quando o primeiro byte da resposta começa a chegar. O que as pessoas erram é tratar isso como tempo puro de processamento do backend. Não é. É a soma de tudo que precisa terminar antes que esse primeiro byte possa voltar:

1. Tempo de redirecionamento
2. Tempo de inicialização do service worker (se aplicável)
3. Consulta DNS
4. Negociação de conexão e TLS
5. A solicitação — até o ponto em que o primeiro byte da resposta chegou

O processamento do servidor está aí, mas também está todo o custo de configuração da conexão. Essa distinção importa no momento em que você começa a ler as ferramentas, porque elas não medem todas a mesma parte (mais sobre isso abaixo).

Não é um Core Web Vital

Vou dizer isso claramente porque é o equívoco mais comum: TTFB não é um Core Web Vital. Os três Core Web Vitals são LCP (carregamento), INP (interatividade) e CLS (estabilidade visual). O TTFB é uma métrica fundamental e diagnóstica — a própria estrutura do Google é que ele é “uma métrica fundamental para medir o tempo de configuração da conexão e a capacidade de resposta do servidor web tanto no laboratório quanto no campo.”

O Google também é explícito que você não precisa estritamente atingir o bom limite de TTFB: como não é um Core Web Vital, “não é absolutamente necessário que os sites atendam ao limite ‘bom’ de TTFB, desde que isso não impeça sua capacidade de obter uma boa pontuação nas métricas que importam.” Essa última cláusula é o problema — para a maioria dos sites, um TTFB ruim definitivamente impede as métricas que importam.

Como ele limita o FCP e o LCP

O TTFB precede toda métrica de carregamento centrada no usuário. Tanto o First Contentful Paint quanto o Largest Contentful Paint incluem o TTFB em sua medição — o cronômetro para essas métricas já está rodando enquanto você espera pelo primeiro byte. O web.dev divide o LCP em subpartes e o TTFB é a primeira delas, por isso você não pode ter um LCP rápido sobre um TTFB lento.

É também aqui que os dados do mundo real se tornam relevantes. O Web Almanac do HTTP Archive descobriu que em sites com LCP ruim, o TTFB sozinho consumia cerca de 2,27 segundos — quase todo o orçamento de 2,5 segundos para um LCP “bom” — antes mesmo de qualquer imagem ou texto começar a renderizar. Se o seu LCP está ruim e o conteúdo da sua página parece otimizado, o TTFB é o primeiro lugar onde eu olharia.

Portanto, a história do ranqueamento é indireta, mas real: o TTFB não é um sinal de ranqueamento do Google (os sinais de ranqueamento são LCP, INP e CLS — o TTFB não está nomeado nesse conjunto). Mas ele está embutido no LCP, que é um sinal de ranqueamento. O caminho passa pelo LCP, não diretamente pelo TTFB.

Limites: bom, precisa melhorar, ruim

A orientação do web.dev, medida no 75º percentil dos carregamentos de usuários reais:

• Bom: ≤ 0,8 s
• Ruim: > 1,8 s

“A maioria dos sites deve se esforçar para ter um TTFB de 0,8 segundos ou menos.” Vale a pena conhecer a história: o Google moveu a linha “bom” de 500 ms para 800 ms em 2022, e dados mais antigos foram recalculados sob o novo padrão — então não compare números históricos brutos de TTFB sem verificar qual limite eles usaram.

A confusão entre 600 ms e 800 ms

Isso confunde muitas pessoas, então vale a pena ser preciso. Existem dois números diferentes circulando:

• Limite de TTFB do CrUX / web.dev: 800 ms. Este é o limite de campo para o TTFB completo (DNS + conexão + TLS + redirecionamentos + tempo do servidor).
• Auditoria “Reduza os tempos de resposta do servidor” do Lighthouse: ~600 ms. Esta é uma auditoria de laboratório que sinaliza quando o navegador espera mais de cerca de 600 ms para o servidor responder à solicitação do documento principal. Crucialmente, ela mede apenas o tempo de resposta do servidor — não inclui DNS, configuração de conexão ou TLS.

Portanto, o número do Lighthouse parece mais rigoroso, mas está medindo uma parte mais estreita. Como diz a documentação, “o tempo de resposta do servidor é apenas parte do tempo total até o primeiro byte (TTFB).” Não trate uma auditoria do Lighthouse aprovada como prova de um bom TTFB de campo, e não entre em pânico porque 600 < 800 significa que os limites se contradizem — eles medem coisas diferentes.

Uma nota de versão: a partir do Lighthouse 13, esta auditoria não existe mais sozinha — ela foi incorporada ao insight mais amplo de “latência de solicitação de documento”. A verificação subjacente de resposta do servidor de ~600 ms é a mesma; apenas é apresentada de forma diferente dependendo da versão do Lighthouse que gerou seu relatório.

Campo e laboratório — ambos

O TTFB é uma das métricas que você pode ler em ambos os mundos. No campo, ele vem do CrUX (usuários reais do Chrome), exibido no PageSpeed Insights e no Search Console. No laboratório, o Chrome DevTools o rotula como “Waiting (TTFB)” no painel Network waterfall (“o navegador está aguardando o primeiro byte de uma resposta”), e ferramentas como WebPageTest e Lighthouse também o relatam. Uma ressalva de campo: no CrUX, o TTFB é ainda tratado como um tanto experimental — ele exclui alguns tipos avançados de navegação, como navegações pré-renderizadas e de cache de ida e volta, então as médias de campo podem parecer um pouco pessimistas em relação ao que os usuários realmente sentem.

Um TTFB alto nem sempre significa um site lento

Aqui está a nuance que os números de limite escondem. Uma página renderizada no servidor pode apresentar um TTFB maior do que uma página renderizada no cliente e ainda assim entregar melhores FCP e LCP — porque quando esse primeiro byte finalmente chega, é HTML completo que o navegador pode pintar imediatamente, em vez de uma casca fina que depois precisa buscar e executar um bundle de JavaScript antes que qualquer coisa apareça. O Google diz isso diretamente: “a server-rendered site that does not require as much client-side work could have a higher TTFB, but better FCP and LCP values than an entirely client-rendered experience.” (tradução) «um site renderizado no servidor que não exige tanto trabalho no lado do cliente poderia ter um TTFB maior, mas melhores valores de FCP e LCP do que uma experiência totalmente renderizada no cliente.»

O outro lado: para um aplicativo de página única renderizado no cliente, o TTFB determina quando o bundle de JavaScript começa a carregar, então um TTFB baixo importa mais lá, não menos. Não otimize o TTFB isoladamente — otimize toda a cadeia de carregamento e julgue o TTFB pelo que ele faz com o FCP e o LCP.

Como melhorar o TTFB

Aproximadamente em ordem de prioridade:

• Comece pela hospedagem. Um backend lento ou uma consulta de banco de dados é um custo em cada requisição, e nenhuma quantidade de trabalho de front-end o remove. Esta é a primeira coisa a considerar.
• Use uma CDN. Uma CDN resolve o problema de proximidade — uma rede distribuída de servidores de borda armazena recursos em cache fisicamente mais próximos dos seus usuários, reduzindo o custo da velocidade da luz da conexão e do handshake TLS. É a correção de maior ROI para a maioria dos sites, porque a distância geográfica da sua origem é um custo estrutural que nada no backend pode eliminar. A ressalva: para conteúdo totalmente dinâmico e personalizado que não pode ser armazenado em cache, uma CDN adiciona um salto sem o benefício de acerto de cache — nesse caso, a resposta é otimização de backend, computação de borda ou streaming.
• Armazene seu HTML em cache, mesmo que brevemente. Mesmo um tempo curto de cache ajuda um site movimentado notavelmente: apenas o primeiro visitante nessa janela paga a latência total de volta à origem; todos os outros recebem a cópia em cache.
• Elimine redirecionamentos. Redirecionamentos são um contribuinte comum para TTFB alto — cada um é uma ida e volta antes de a resposta real começar. Corte os que estão sob seu controle.
• Transmita a marcação para o navegador. Os navegadores processam a marcação com eficiência quando ela é transmitida em blocos à medida que chega. Muitos frameworks SSR suportam streaming, mas ele fica desligado; ativá-lo pode reduzir o TTFB em páginas dinâmicas sem nenhuma mudança de infraestrutura.
• Use 103 Early Hints. O código de status 103 é uma resposta preliminar que o servidor pode enviar enquanto o backend ainda está preparando a marcação, sinalizando ao navegador para começar a baixar recursos críticos de renderização antecipadamente. Ele não reduz o TTFB em si — na verdade, um 103 pode contar como o “primeiro byte” — mas diminui o impacto de um TTFB alto. Shopify e Cloudflare relataram várias centenas de milissegundos de melhoria no LCP com isso, em alguns casos perto de um segundo.
• Negocie TLS com eficiência e otimize a inicialização do service worker. Um service worker que ainda não foi iniciado adiciona seu tempo de inicialização ao TTFB; uma vez em execução, seu cache (stale-while-revalidate, ou um modelo de app-shell para SPAs) pode reduzir drasticamente o TTFB.

Onde os sites realmente estão

A razão pela qual isso merece sua atenção: é um problema persistente em toda a web. A taxa de TTFB bom para mobile do Web Almanac mal mudou em cinco anos — pairando em torno de 41–42% — o que significa que a maioria dos sites mobile ainda não tem um TTFB “bom”. Essa estagnação é, francamente, uma oportunidade. Para um site com muito servidor que falha no LCP, o TTFB é normalmente a correção de maior alavancagem disponível.

Esta página faz parte do cluster web-performance, que fica sob Core Web Vitals. Para as métricas que o TTFB alimenta, veja Largest Contentful Paint e First Contentful Paint; para medi-lo em usuários reais e em laboratório, veja CrUX, PageSpeed Insights e Lighthouse.

Resumo de IA

Uma visão condensada da versão Avançada:

• TTFB = a espera pelo primeiro byte. Tempo desde o início da solicitação até quando o primeiro byte da resposta chega — a soma do tempo de redirecionamento, inicialização do service worker, consulta DNS, negociação de conexão + TLS e a própria solicitação. Não apenas o processamento do servidor.
• NÃO é um Core Web Vital. Os Core Web Vitals são LCP, INP e CLS. O TTFB é uma métrica fundamental, diagnóstica.
• Ele limita FCP e LCP. Ambos incluem o TTFB, então um TTFB lento define um teto para a velocidade com que uma página pode carregar. Em sites com LCP ruim, apenas o TTFB era ~2,27 s — quase todo o orçamento de 2,5 s para LCP bom.
• Ranqueamento: indireto. O TTFB não é um sinal de ranqueamento do Google, mas está embutido no LCP, que é. O caminho passa pelo LCP.
• Limiares (75º percentil): bom ≤ 0,8 s, ruim > 1,8 s. A linha de “bom” mudou de 500 ms para 800 ms em 2022.
• 600 ms vs 800 ms: a auditoria “Reduzir tempos de resposta do servidor” do Lighthouse sinaliza ~600 ms de tempo de servidor apenas — mais estreito que o limiar de campo de 800 ms para TTFB completo. “O tempo de resposta do servidor é apenas parte do TTFB completo.” A partir do Lighthouse 13, esta auditoria fica dentro do insight “Latência de solicitação de documento”.
• Campo e laboratório: CrUX/PSI/Search Console (campo); DevTools “Waiting (TTFB)”, WebPageTest, Lighthouse (laboratório).
• TTFB alto ≠ site lento: uma página SSR pode ter um TTFB maior, mas melhor FCP/LCP do que uma renderizada no cliente, porque o primeiro byte é HTML completo.
• Correções (prioridade): hospedagem primeiro, depois CDN, cache de HTML, menos redirecionamentos, streaming, 103 Early Hints, TLS eficiente, inicialização do service worker.
• Estado da web: o TTFB bom para mobile está estável em ~41–42% há cinco anos — uma oportunidade real.

Documentação oficial

Documentação de fonte primária das equipes de Chrome e web.dev do Google.

• Time to First Byte (TTFB) — a definição, os cinco componentes, os limiares de 0,8 s / 1,8 s, por que não é um Core Web Vital e sua relação com FCP e LCP.
• Optimize TTFB — o guia de otimização: hospedagem primeiro, depois CDN, cache, redirecionamentos, streaming, 103 Early Hints e service workers.
• Reduce server response times — a auditoria do Lighthouse (~limiar de 600 ms de tempo de servidor) e como ela difere do TTFB completo. A partir do Lighthouse 13, ela está incorporada ao insight “Latência de solicitação de documento”.
• Web Vitals — onde o TTFB se encaixa na taxonomia de métricas: uma métrica suplementar/diagnóstica, com LCP, INP e CLS como Core Web Vitals.
• Largest Contentful Paint (LCP) — confirma que o LCP inclui atrasos de TTFB.
• First Contentful Paint (FCP) — confirma que o FCP inclui o TTFB e lista “reduzir tempos de resposta do servidor (TTFB)” como uma correção.
• Core Web Vitals (Google Search Central) — os documentos de sinal de ranqueamento citam apenas LCP, INP e CLS; o TTFB não está listado.
• 103 Early Hints — o código de resposta antecipado, suporte do navegador/servidor e resultados do mundo real.

Citações da fonte

Declarações oficiais das equipes web.dev e Chrome do Google. Cada link é um link profundo que salta para a passagem citada na página de origem, onde uma foi verificada.

web.dev — o que é TTFB

• “TTFB is a metric that measures the time between starting navigating to a page and when the first byte of a response begins to arrive.” (tradução) «TTFB é uma métrica que mede o tempo entre começar a navegar para uma página e quando o primeiro byte de uma resposta começa a chegar.» Ir para a citação
• “Time to First Byte (TTFB) is a foundational metric for measuring connection setup time and web server responsiveness in both the lab and the field.” (tradução) «Time to First Byte (TTFB) é uma métrica fundamental para medir o tempo de configuração da conexão e a capacidade de resposta do servidor web, tanto em laboratório quanto em campo.» Ir para a citação

web.dev — limites

• “Good TTFB values are 0.8 seconds or less, and poor values are greater than 1.8 seconds.” (tradução) «Valores bons de TTFB são 0,8 segundos ou menos, e valores ruins são maiores que 1,8 segundos.» Ir para a citação

web.dev — não é um Core Web Vital

• “Because TTFB isn’t a Core Web Vitals metric, it’s not absolutely necessary that sites meet the ‘good’ TTFB threshold, provided that it doesn’t impede their ability to score well on the metrics that matter.” (tradução) «Como o TTFB não é uma métrica de Core Web Vitals, não é absolutamente necessário que os sites atendam ao limite ‘bom’ de TTFB, desde que isso não impeça sua capacidade de obter boas pontuações nas métricas que importam.» Ir para a citação

web.dev — relação com FCP e LCP

• “Because TTFB precedes user-centric metrics such as First Contentful Paint (FCP) and Largest Contentful Paint (LCP)…” (tradução) «Como o TTFB precede métricas centradas no usuário, como First Contentful Paint (FCP) e Largest Contentful Paint (LCP)…» Ir para a citação
• Em um site renderizado no servidor: “a server-rendered site that does not require as much client-side work could have a higher TTFB, but better FCP and LCP values than an entirely client-rendered experience.” (tradução) «um site renderizado no servidor que não exige tanto trabalho no lado do cliente poderia ter um TTFB maior, mas melhores valores de FCP e LCP do que uma experiência totalmente renderizada no cliente.» (web.dev, “Time to First Byte”)

Lighthouse — tempo de resposta do servidor vs TTFB completo

• “Server response time is only part of the full Time to First Byte (TTFB).” (tradução) «O tempo de resposta do servidor é apenas parte do Time to First Byte (TTFB) completo.» (Lighthouse, “Reduce server response times.”)

Patrick Stox — sobre o status do TTFB (do meu guia de Core Web Vitals da Ahrefs)

• “There are additional Web Vitals that serve as proxy measures or supplemental metrics but are not used in the ranking calculations. The Web Vitals metrics for visual load include Time to First Byte (TTFB) and First Contentful Paint (FCP).” (tradução) «Existem Web Vitals adicionais que servem como medidas substitutas ou métricas suplementares, mas não são usados nos cálculos de ranqueamento. As métricas de Web Vitals para carga visual incluem Time to First Byte (TTFB) e First Contentful Paint (FCP).» Leia o guia

Lista de verificação de triagem de TTFB

Quando o PageSpeed Insights, o Search Console ou o Lighthouse sinalizam uma resposta lenta do servidor, trabalhe nesta lista:

• Confirme o que você está analisando — TTFB completo de campo (≤0,8 s é bom) ou a auditoria “Reduce server response times” do Lighthouse (~600 ms, apenas tempo de servidor). Eles não são o mesmo número.
• Verifique o campo, não apenas o laboratório — obtenha o TTFB do CrUX via PageSpeed Insights ou do relatório Core Web Vitals do Search Console, no 75º percentil.
• Veja se o TTFB é o que está limitando seu LCP — se o LCP está ruim e o conteúdo da página está otimizado, o TTFB é o primeiro suspeito.
• Conte seus redirecionamentos — elimine quaisquer cadeias de redirecionamento sob seu controle em URLs de entrada principais.
• Confirme se um CDN está atendendo seus usuários (PoPs de borda próximos ao seu público) e se o cache de HTML/edge está realmente funcionando, não apenas ativos estáticos.
• Analise o backend — consultas lentas ao banco de dados ou trabalho pesado no lado do servidor na solicitação do documento principal.
• Verifique se o TLS é eficiente (protocolo moderno, retomada de sessão) e se o DNS é rápido.
• Se a página for SSR dinâmico, verifique se o streaming está habilitado no seu framework — geralmente está desativado por padrão.
• Considere 103 Early Hints para recursos críticos de renderização se seu servidor/CDN suportar.
• Se você usa um service worker, verifique se a inicialização dele não está adicionando ao TTFB no primeiro carregamento e se a estratégia de cache dele ajuda em carregamentos repetidos.

Folha de referência de TTFB

Do que o TTFB é a soma

1. Tempo de redirecionamento
2. Inicialização do service worker (se houver)
3. Consulta DNS
4. Conexão + negociação TLS
5. A solicitação — até o primeiro byte da resposta

Limiares (75º percentil de carregamentos de usuários reais)

Dois limiares, dois escopos

Fatos rápidos

• TTFB não é um Core Web Vital. Os Core Web Vitals são LCP, INP, CLS.
• É uma métrica tanto de campo quanto de laboratório.
• Tanto FCP quanto LCP incluem TTFB — ele define um teto para eles.
• O impacto no ranqueamento é indireto, via LCP — o TTFB em si não é um sinal de ranqueamento.
• O DevTools o rotula como “Waiting (TTFB)” no painel Network.
• A linha de “bom” mudou de 500 ms → 800 ms em 2022.

Prioridade de correção: hospedagem → CDN → cache de HTML/edge → cortar redirecionamentos → transmitir marcação → 103 Early Hints → TLS eficiente → inicialização do service worker.

Ferramentas para medir TTFB

• PageSpeed Insights — a leitura de campo mais fácil: mostra seu TTFB do CrUX (usuários reais do Chrome) junto com uma execução de laboratório, para uma URL ou origem.
• Search Console — relatório Core Web Vitals — dados de campo agrupados por padrão de URL; o lugar para identificar problemas de TTFB em escala.
• CrUX (Chrome User Experience Report) — o conjunto de dados de campo subjacente; consultável diretamente via API do CrUX ou BigQuery para tendências históricas.
• Chrome DevTools — painel Network — passe o mouse sobre a solicitação do documento principal e leia o tempo “Waiting (TTFB)” para uma análise precisa de laboratório de conexão vs. tempo de servidor.
• Lighthouse — executa a auditoria “Reduce server response times” (~600 ms de sinalizador de tempo de servidor); integrado ao DevTools e ao PageSpeed Insights. A partir do Lighthouse 13, essa verificação aparece dentro do insight “Document request latency”.
• WebPageTest — waterfalls detalhados com TTFB dividido por fase de conexão e testes de múltiplas localizações/conexões para isolar a latência geográfica.
• Biblioteca JS web-vitals — colete TTFB (e o restante) de seus próprios usuários reais em campo e envie para sua análise.

Erros de TTFB que levam à correção errada

Chamando todo atraso de problema de servidor

O TTFB inclui redirecionamentos, DNS, configuração de conexão, TLS, inicialização do service worker e processamento do servidor. Divida a solicitação em fases antes de alterar o código do aplicativo ou a hospedagem.

Comparando a auditoria de 600 ms do Lighthouse com o limiar de campo de 800 ms

A auditoria do Lighthouse é um diagnóstico laboratorial mais restrito, enquanto a orientação de 0,8 segundo descreve o TTFB completo. Rotule a fonte e o escopo ao relatar qualquer um dos números.

Testar apenas a partir de um local próximo à origem

Um laboratório próximo pode ocultar a latência geográfica. Compare regiões ou use dados de usuários reais antes de presumir que a mesma experiência se aplica a todo o público.

Perseguir o TTFB enquanto a página já está rápida

Um TTFB alto pode ser compatível com uma experiência rápida em streaming ou em cache. Verifique se ele realmente limita o FCP ou o LCP antes de priorizá-lo em relação a um gargalo maior.

Diagnosticar um TTFB lento por sintoma

A primeira solicitação é lenta, mas as solicitações repetidas são rápidas

Causa provável: caches frios, configuração de conexão ou aquecimento do aplicativo. Correção: inspecione os cabeçalhos de cache e separe os testes frios dos quentes. Confirmação: o waterfall mostra qual fase de conexão ou servidor desaparece na solicitação repetida.

O TTFB é lento apenas em regiões distantes

Causa provável: distância física até a origem ou uma falha de cache do CDN. Correção: sirva HTML armazenável em cache mais perto dos usuários e verifique o comportamento do cache de borda. Confirmação: os testes regionais mostram uma espera menor sem alterar o corpo da resposta.

Uma URL tem um TTFB muito pior do que seus pares de modelo

Causa provável: redirecionamentos, uma rota sem cache ou trabalho de backend caro específico da página. Correção: compare a cadeia de redirecionamento, o status do cache e o tempo do servidor com um par saudável. Confirmação: a solicitação de documento do outlier volta à linha de base do modelo.

DevTools e CrUX discordam

Causa provável: uma única solicitação de laboratório não pode representar os dispositivos, locais, estados de cache e o 75º percentil do campo. Correção: use a solicitação de laboratório para diagnosticar e os dados de campo para julgar a prevalência. Confirmação: sua distribuição de RUM explica qual segmento produz o agregado mais lento.

Medir o TTFB pela linha de comando

Use as variáveis de tempo do curl para separar o primeiro byte do DNS, da conexão e da configuração do TLS.

curl -sS -o /dev/null \
  -w 'dns=%{time_namelookup}s connect=%{time_connect}s tls=%{time_appconnect}s starttransfer=%{time_starttransfer}s total=%{time_total}s\n' \
  https://example.com/

time_starttransfer é a medição estilo TTFB do comando. Execute várias solicitações frias e quentes de mais de uma região relevante; uma única amostra local não é um benchmark de campo.

Ler o Navigation Timing no navegador

const nav = performance.getEntriesByType('navigation')[0];
console.table({
  ttfb: Math.round(nav.responseStart - nav.requestStart),
  dns: Math.round(nav.domainLookupEnd - nav.domainLookupStart),
  connect: Math.round(nav.connectEnd - nav.connectStart),
});

Comprovar que uma alteração no TTFB teve efeito

Teste de cache de borda

Teste a executar: solicite o mesmo documento duas vezes com curl -sS -D - -o /dev/null e inspecione os cabeçalhos de status de cache e idade do CDN. Resultado esperado: a solicitação repetida é servida do cache de acordo com o cabeçalho documentado do CDN. Interpretação de falha: a rota está ignorando ou expirando imediatamente o cache. Janela de monitoramento: imediata. Gatilho de reversão: HTML personalizado, autenticado ou desatualizado é servido à solicitação errada.

Teste de remoção de redirecionamento

Teste a executar: use curl -sS -I na URL pública final e inspecione a cadeia de redirecionamento separadamente. Resultado esperado: a URL de entrada pretendida chega ao documento sem um salto evitável. Interpretação de falha: as regras de roteamento ou de host canônico ainda adicionam uma ida e volta. Janela de monitoramento: imediata. Gatilho de reversão: a alteração quebra a normalização necessária de HTTP para HTTPS ou de nome de host.

Teste de TTFB de campo

Teste a executar: compare o Navigation Timing pós-lançamento ou o TTFB de web-vitals por região e modelo com a linha de base pré-lançamento. Resultado esperado: o p75 melhora nos segmentos afetados sem mais erros. Interpretação de falha: o ganho de laboratório não alcançou usuários reais ou transferiu o trabalho para outro lugar. Janela de monitoramento: conforme o tráfego de RUM chega; CrUX ao longo de sua janela contínua. Gatilho de reversão: a taxa de erro, a correção do cache ou a latência visível ao usuário pioram.

Métricas de TTFB que valem a pena acompanhar

TTFB de usuários reais no p75

Métrica: TTFB no percentil 75 por modelo, região e classe de dispositivo. O que ela indica: quanto tempo a solicitação do documento atrasa a maioria das visitas reais antes que a renderização possa começar. Como obtê-la: Navigation Timing, a biblioteca web-vitals, CrUX ou PageSpeed Insights. Referência / faixa realista: 0,8 segundo ou menos é a boa meta descrita neste artigo; interprete os segmentos separadamente. Cadência: semanalmente no RUM e mensalmente para a tendência contínua de campo público.

TTFB com cache acionado versus TTFB sem cache

Métrica: TTFB no p75 dividido pelo resultado de cache do CDN. O que ela indica: se o trabalho na origem ou a entrega na borda é o responsável pelo atraso. Como obtê-la: junte os cabeçalhos de status de cache da resposta com RUM ou logs do CDN. Referência / faixa realista: use a linha de base regional do próprio site, pois provedor, rota e personalização diferem. Cadência: semanalmente e após mudanças nas regras de cache.

Participação do TTFB no LCP

Métrica: TTFB dividido pela duração do LCP na mesma visita. O que ela indica: se o tempo de servidor e de conexão é a parte limitante da experiência de carregamento. Como obtê-la: colete TTFB e LCP juntos no RUM. Referência / faixa realista: não há porcentagem universal honesta; priorize o TTFB quando ele consumir consistentemente uma grande parte do LCP. Cadência: mensalmente por modelo.

Recursos que valem seu tempo

Meus artigos relacionados

• Core Web Vitals: um guia para iniciantes — onde o TTFB se encaixa entre as métricas de carregamento e por que é uma métrica complementar em vez de um sinal de ranqueamento.
• O guia para iniciantes em SEO técnico — o panorama geral em que o desempenho do site se insere.

Oficial

• O TTFB e o Otimize o TTFB do web.dev — as duas páginas definitivas.
• O artigo da equipe do Chrome sobre 103 Early Hints, com os resultados da Shopify/Cloudflare.

Dados

• O Web Almanac — capítulo de desempenho do HTTP Archive — os dados de campo de longo prazo de TTFB e LCP para toda a web.

Da indústria

• Blog da Cloudflare: Early Hints — o artigo da própria Cloudflare sobre o envio de 103 Early Hints, incluindo resultados do mundo real e detalhes de implementação no CDN.
• Biblioteca JS web-vitals (GitHub) — a biblioteca canônica para coletar TTFB (e todas as Web Vitals) de usuários reais; use-a para enviar TTFB de campo para sua própria análise.
• Web Almanac 2022 do HTTP Archive — Desempenho — linha de base histórica mostrando 40% de bom TTFB móvel sob o então novo limite de 800 ms; útil para contexto de tendência plurianual.
• Fastly — HTTP/2 Server Push vs Early Hints — perspectiva de CDN sobre por que o Early Hints está substituindo o Server Push para reduzir o impacto do TTFB.

Estatísticas que valem ser citadas

• ~42% dos sites móveis têm um TTFB “bom” — e isso quase não mudou em cinco anos. A taxa de TTFB bom para mobile do Web Almanac ficou em torno de 41–42% ao longo de cinco anos de dados: uma estagnação teimosa e generalizada na web. Fonte
• Em sites com LCP ruim, o TTFB sozinho consumiu ~2,27 segundos — quase todo o limite de 2,5 segundos para “LCP bom”, antes de qualquer conteúdo ser renderizado. O TTFB é a maior subparte do LCP para sites que falham nele. Fonte
• 103 Early Hints proporcionaram várias centenas de milissegundos de melhoria no LCP em testes da Shopify e da Cloudflare — em alguns casos, quase um segundo mais rápido. Fonte
• A linha de TTFB “bom” mudou de 500 ms para 800 ms em 2022, e os dados históricos foram recalculados sob o novo padrão — vale a pena saber antes de comparar números antigos de TTFB. Fonte

Teste-se: Time to First Byte

Cinco perguntas rápidas sobre o que o TTFB mede e como melhorá-lo. Escolha uma resposta para cada uma e depois confira.

Registro de alterações