Time to first byte (TTFB): o que é bom e como reduzir

O time to first byte (TTFB) é o tempo desde o início da navegação até o primeiro byte da resposta HTML. O web.dev, do Google, considera bom um valor de 0,8 segundo ou menos e ruim um valor acima de 1,8 segundo, medidos no 75º percentil das visitas reais (web.dev, última atualização em novembro de 2025). O TTFB não é uma Core Web Vital, mas todas as métricas seguintes, incluindo First Contentful Paint e Largest Contentful Paint, começam depois dele. No celular, é também onde se acumulam redirecionamentos, DNS, TLS e um servidor lento, porque cada uma dessas etapas custa pelo menos uma ida e volta pela rede móvel.

O que é o time to first byte?

O TTFB é a soma de todas as etapas antes da chegada do primeiro byte do documento, incluindo redirecionamentos, DNS e TLS. Segundo o web.dev, ele inclui:

• o tempo de redirecionamento;
• a inicialização do service worker, se o site tiver um;
• a busca de DNS;
• a conexão e a negociação TLS;
• a própria requisição, até o primeiro byte da resposta.

Por isso um servidor rápido pode mostrar um TTFB lento. Uma visita que começa em http://example.com, redireciona para https://example.com e depois para https://www.example.com já pagou dois redirecionamentos e três conexões antes de o servidor da página final fazer qualquer coisa.

O TTFB também não é o mesmo que o «tempo de resposta do servidor» dos relatórios antigos do Lighthouse. Essa auditoria media apenas a espera pelo documento principal e excluía as buscas de DNS e os redirecionamentos, então é uma parte do TTFB (Chrome for Developers).

Qual é um bom TTFB?

Um bom TTFB é de 0,8 segundo ou menos, e o web.dev chama seus limites de «um guia aproximado», não uma exigência. Estas são as faixas de novembro de 2025, junto com o número mais rigoroso do Lighthouse:

Os dois números medem coisas diferentes. Os 600 ms do Lighthouse cobrem o tempo de resposta do próprio servidor, enquanto o guia de 0,8 s cobre o TTFB completo, então a mesma página pode passar em um e reprovar no outro. Os dois são limites de design definidos pelo Google.

Com que frequência se obtém uma boa pontuação no celular? No Web Almanac 2025 da HTTP Archive, baseado em dados de julho de 2025, 44% dos sites mobile tinham um bom TTFB, contra 55% no desktop. No mobile, 40% precisavam melhorar e 17% estavam ruins (Web Almanac 2025, Performance).

Por que o TTFB é maior no celular

O TTFB é maior no celular porque cada etapa antes do primeiro byte é uma ida e volta, e uma ida e volta em conexão móvel leva mais tempo do que em uma conexão cabeada. Em uma primeira visita por HTTPS com conexão fria, a sequência é:

1. Busca de DNS, para encontrar o endereço do servidor.
2. Handshake TCP: uma ida e volta até o servidor.
3. Handshake TLS: mais uma ida e volta com TLS 1.3, que a RFC 8446 chama de «handshake de 1-RTT».
4. A requisição HTTP e o primeiro byte da resposta: uma ida e volta mais o tempo que o seu servidor leva.

Ou seja, só a rede custa três idas e voltas até o servidor mais a busca de DNS, antes do trabalho do próprio servidor. A tabela abaixo é uma conta com dois tempos de ida e volta (RTT) escolhidos como exemplo, não medições de nenhuma rede:

Com o RTT maior, um servidor que responde em 400 ms já ultrapassa o guia de 0,8 s depois de somar o DNS. O servidor não fez nada errado; a preparação da conexão levou mais da metade do orçamento.

Duas coisas reduzem essa sobrecarga. Reutilize a conexão: um visitante que volta e ainda está conectado pula as etapas 1 a 3. E use um protocolo mais novo: o HTTP/3 roda sobre QUIC, cujo handshake «combina a negociação dos parâmetros criptográficos e de transporte» (RFC 9000, maio de 2021), então a preparação precisa de menos idas e voltas do que TCP seguido de TLS. O web.dev observa que os CDNs servem o conteúdo com protocolos modernos como HTTP/2 ou HTTP/3 (web.dev).

Outra causa específica do celular: um site mobile separado. O conselho do Lighthouse sobre redirecionamentos diz que, para usuários mobile, convém considerar o design responsivo em vez de redirecioná-los para uma página mobile (Chrome for Developers). A abordagem responsiva é explicada em como tornar um site compatível com celulares.

Como medir o TTFB

Meça o TTFB duas vezes: em laboratório, para ver onde o tempo se perde, e em campo, para ver o que os celulares reais recebem. Os dois números podem diferir: uma execução de laboratório é um carregamento em uma máquina, e o valor de campo é o 75º percentil das visitas reais.

No DevTools (laboratório), abra o painel Rede, recarregue, selecione a primeira requisição (o documento) e abra a aba Timing. As fases se chamam Queueing, Stalled, DNS Lookup, Initial connection, Request sent e Waiting (TTFB), e o «Waiting (TTFB)» é uma ida e volta mais o tempo que o servidor leva para preparar a resposta (referência do Chrome DevTools). Se a barra de Initial connection é longa e a de Waiting é curta, a correção está na preparação da conexão, não na aplicação.

Na página (campo), a biblioteca web-vitals informa o TTFB e, na sua versão de atribuição, o divide nas mesmas fases. A documentação dela (README do web-vitals) as nomeia waitingDuration (redirecionamentos e trabalho do navegador antes da requisição), cacheDuration (checagem de cache e tempo do service worker), dnsDuration, connectionDuration e requestDuration (tempo de rede e processamento no servidor):

import {onTTFB} from 'web-vitals/attribution';

onTTFB(({value, rating, attribution}) => {
  // Envie para o seu endpoint de analytics; aqui apenas exibimos o detalhamento no console.
  console.log(rating, Math.round(value), {
    redirectsAndWaiting: attribution.waitingDuration,
    cache: attribution.cacheDuration,
    dns: attribution.dnsDuration,
    connection: attribution.connectionDuration,
    request: attribution.requestDuration,
  });
});

Por tipo de dispositivo (campo, sem código), a API do Chrome UX Report aceita um formFactor de PHONE, TABLET ou DESKTOP e devolve o 75º percentil de experimental_time_to_first_byte (uma métrica experimental da API) (documentação da API CrUX). Os dados são uma média móvel de 28 dias. É a forma mais rápida de ver se o TTFB no celular é pior do que no desktop. Como rodar o conjunto mais amplo de testes de velocidade está no guia de teste de velocidade em celulares, e como o Lighthouse relata o mesmo problema está no guia de auditoria mobile com Lighthouse.

No servidor, adicione um cabeçalho Server-Timing para ver qual etapa do backend é lenta. O Chrome 65, o Firefox 61 e o Safari 16.4 suportam (MDN browser-compat-data 8.1.7, outubro de 2026):

Server-Timing: db;dur=53, app;dur=47.2, cache;desc="miss"

Os valores aparecem depois na aba Timing do painel Rede e em navigationEntry.serverTiming do objeto de atribuição acima.

Como reduzir o TTFB

Comece pela fase maior do seu detalhamento, porque cada correção remove apenas a sua própria fase. Esta tabela relaciona o que você vê com o que mudar:

As correções abaixo seguem o guia do web.dev para otimizar o TTFB (web.dev, atualizado em novembro de 2025).

1. Remova os redirecionamentos. O web.dev orienta retirar os redirecionamentos 301 e 302 da mesma origem, como um https:// que falta ou uma diferença na barra final, e dar a URL final a anunciantes e newsletters. O HSTS indica ao navegador que use https:// diretamente em vez de pedir primeiro http://.
2. Coloque um CDN na frente. Um CDN responde a partir de um servidor de borda próximo ao visitante, o que encurta cada ida e volta da tabela acima. Segundo o web.dev, ele normalmente também traz HTTP/3, TLS 1.3 e compressão.
3. Coloque o HTML em cache. Uma página igual para todos os visitantes pode ser armazenada com Cache-Control e servida sem tocar na aplicação. O web.dev observa que tempos de cache curtos já ajudam sites muito acessados. Acrescente um parâmetro na URL para ignorar o cache durante o diagnóstico.
4. Reduza o trabalho do servidor. A orientação do Lighthouse é otimizar a lógica da aplicação e as consultas ao banco, melhorar o hardware se preciso, e usar um CDN para documentos que podem ser armazenados na borda. Use o Server-Timing para achar primeiro a etapa lenta.
5. Comprima o texto. O insight do Lighthouse sinaliza um documento principal enviado sem compressão. O navegador anuncia o que aceita em Accept-Encoding e o servidor responde com Content-Encoding.
6. Transmita o HTML em streaming. O web.dev recomenda manter o fluxo da resposta aberto, com renderização de servidor em streaming ou renderização estática quando possível, para que os primeiros bytes saiam cedo. O envio antecipado também é medido como responseStart, então o TTFB pode parecer melhor do que a página realmente se sente; verifique também o First Contentful Paint.
7. Envie 103 Early Hints. Se o servidor precisar de tempo para montar a página, pode enviar primeiro uma resposta 103 com cabeçalhos Link, para que o navegador comece um preconnect ou um preload enquanto espera.

HTTP/2 103
Link: </css/app.css>; rel=preload; as=style
Link: <https://cdn.example.com>; rel=preconnect

HTTP/2 200
content-type: text/html

O Early Hints funciona com HTTP/2 ou superior na maioria dos navegadores, e só a primeira resposta 103 é processada (MDN, junho de 2026). O suporte começa no Chrome 103, Firefox 120 e Safari 17. Uma resposta 103 conta como os primeiros bytes para o TTFB, e o Chrome mudou qual marca de tempo o responseStart informa (para a resposta final no Chrome 115, de volta aos primeiros bytes no Chrome 133), então compare o TTFB entre ferramentas com cuidado (web.dev).

Se o site tiver um service worker, servir a estrutura a partir do cache também reduz o TTFB nas visitas repetidas. O web.dev sugere stale-while-revalidate para recursos que mudam pouco e rede primeiro para o HTML personalizado.

Sites estáticos e sites com CMS

Um site estático já tem o melhor cenário: o HTML existe antes da requisição, então o TTFB é sobretudo a preparação da conexão, e um CDN é a principal correção. Um CMS monta a página na hora da requisição, então o maior ganho está no cache de página inteira. Para o WordPress, a documentação do Lighthouse cita um tema leve, cache de página inteira e menos plugins; para o Drupal, cache de página, OPcache do PHP e Redis ou Memcached; para o Magento, Varnish (Chrome for Developers, última atualização em 2019, antes do Lighthouse 13).

Uma URL AMP separada também acrescenta uma versão da página para manter consistente com a canônica; se você ainda precisa dela, veja AMP em 2026.

Confira a cadeia de redirecionamentos em uma página de tamanho de celular

Redirecionamentos são a única causa de TTFB que você consegue ver sem cronômetro: um celular pode ser enviado para um lugar diferente de um computador. O Mobile View Extension recarrega a aba com o user agent, o tamanho de tela e a densidade de pixels de um celular, então você pode conferir em qual URL cai e se a página mobile carrega como a versão real. Ele não mede o TTFB nem nenhuma métrica de velocidade, e roda com a conexão e o hardware do seu computador, então, para tempos em celulares reais, use as ferramentas de campo acima.

Perguntas frequentes

Qual é um bom TTFB?

Um bom TTFB é de 0,8 segundo ou menos no 75º percentil, e mais de 1,8 segundo é ruim, segundo o web.dev (novembro de 2025). São guias aproximados, e o TTFB não faz parte das Core Web Vitals.

O TTFB é uma Core Web Vital?

Não. As Core Web Vitals são Largest Contentful Paint, Interaction to Next Paint e Cumulative Layout Shift, e o web.dev deixa claro que o TTFB não é uma delas. Ele importa porque um TTFB alto atrasa o First Contentful Paint e o Largest Contentful Paint.

Por que o meu TTFB é diferente no Lighthouse e nos dados de campo?

O Lighthouse faz um carregamento em uma máquina com limitação de rede, enquanto os dados de campo cobrem visitas reais em redes e caches reais. Confie no valor de campo e use a execução de laboratório para descobrir qual fase está lenta.

O TTFB afeta o SEO?

O web.dev diz que o TTFB não é uma Core Web Vital, mas vem antes do First Contentful Paint, então um TTFB lento atrasa as métricas seguintes, principalmente o Largest Contentful Paint. Corrija primeiro essas métricas e use o TTFB para descobrir por que estão lentas.