O que é o Time to First Byte (TTFB) e como melhorá-lo

O Time to First Byte (TTFB) mede o tempo em milissegundos entre o navegador solicitar uma página e receber o primeiro byte da resposta do servidor. Um bom TTFB é de 800 milissegundos ou menos no percentil 75. O TTFB não é um Core Web Vital, mas é uma métrica de diagnóstico crítica porque afeta diretamente o Largest Contentful Paint (LCP) e o First Contentful Paint (FCP).

O que é o Time to First Byte

O Time to First Byte (TTFB) indica o tempo decorrido, em milissegundos, entre o início da requisição e o recebimento do primeiro byte de resposta de uma página web. Por isso, o TTFB também é chamado de tempo de espera. Ele mede a capacidade de resposta do servidor web e do trajeto de rede entre o usuário e esse servidor. O TTFB é uma métrica de base: qualquer tempo a mais no TTFB é somado diretamente ao Largest Contentful Paint e ao First Contentful Paint. Cada milissegundo economizado no TTFB é um milissegundo a menos nessas duas métricas de paint.

O TTFB não é um Core Web Vital

Vale deixar isto bem claro: o TTFB não é um dos três Core Web Vitals. Os Core Web Vitals são o Largest Contentful Paint (LCP), o Interaction to Next Paint (INP) e o Cumulative Layout Shift (CLS). O Google não usa o TTFB diretamente nos sinais de ranqueamento da experiência da página.

No entanto, o TTFB é classificado como uma métrica de diagnóstico. Ele ajuda a entender por que o LCP ou o FCP estão lentos. Segundo o Web Almanac 2025, sites com LCP ruim gastam em média 2,27 segundos só no TTFB. Isso consome quase todo o limite de 2,5 segundos do LCP antes mesmo de o navegador começar a renderizar a página. Por isso, corrigir o TTFB é uma das ações de maior impacto para a pontuação geral nos Core Web Vitals.

Por que o Time to First Byte é importante

O Time to First Byte não é um Core Web Vital e é perfeitamente possível passar nos Core Web Vitals mesmo reprovando no TTFB. Mas isso não significa que ele não seja importante. O TTFB é uma métrica essencial para otimizar, e corrigi-lo melhora muito a velocidade e a experiência da página.

O impacto do TTFB para os visitantes

O Time to First Byte antecede todas as outras métricas de paint. Enquanto espera pelo Time to First Byte, o navegador não consegue fazer nada e exibe apenas uma tela em branco. Isso significa que qualquer aumento no Time to First Byte resulta em mais tempo de tela branca; qualquer redução se traduz em menos tela branca.

Para passar a sensação de carregamento instantâneo, o Time to First Byte precisa ser o mais rápido possível.

Por que o TTFB não é um Core Web Vital? O TTFB não considera a renderização: um TTFB baixo não garante uma boa experiência para o usuário porque ignora o tempo que o navegador leva para renderizar a página. Mesmo que todos os bytes baixem rápido, a página ainda pode demorar para aparecer se o navegador tiver que processar muito JavaScript ou renderizar layouts complexos.

O que é uma boa pontuação de TTFB?

O recomendado é que o servidor responda às requisições de navegação com rapidez suficiente para que o percentil 75 dos usuários tenha um FCP dentro da faixa "boa". Como regra geral, a maioria dos sites deve buscar um TTFB de 0,8 segundo ou menos.

• Um TTFB abaixo de 800 milissegundos é considerado bom.
• Um TTFB entre 800 e 1.800 milissegundos precisa de melhorias.
• Um TTFB acima de 1.800 milissegundos é considerado ruim e deve ser corrigido imediatamente.

Impacto no mundo real: o estudo de caso da T-Mobile

A T-Mobile investiu pesado na redução do Time to First Byte dentro de uma iniciativa ampla de otimização de performance. O resultado foi impressionante: um aumento de 60% nas conversões de visita em pedido. Ao adotar páginas renderizadas no edge e cache agressivo no servidor, a empresa reduziu drasticamente o tempo que os usuários passavam esperando pelo primeiro byte. Isso gerou um efeito cascata que acelerou o LCP e o FCP, melhorando a experiência do usuário de forma mensurável. Esse estudo de caso prova que otimizar o TTFB não é apenas um capricho técnico: impacta diretamente os resultados de negócio.

O TTFB da requisição à resposta

Do navegador ao servidor: a requisição

O tempo de requisição do navegador é o intervalo entre o envio da requisição HTTP pelo navegador e a chegada dela ao servidor que hospeda o site. O TTFB desta etapa foge quase que totalmente do controle direto do site e depende muito de:

• Velocidade da internet do usuário.
• Qualidade da infraestrutura de rede.
• Distância física entre o usuário e o servidor.

Nessa etapa, a consulta de DNS, a inicialização do navegador, as buscas no cache local e a negociação da conexão com o servidor (TCP e TLS) consomem um pouco de tempo cada.

No servidor: processamento e preparação da resposta

Quando o servidor recebe a requisição, o cronômetro começa a rodar enquanto ele gera a resposta. É aqui que a maioria dos desenvolvedores foca e onde as otimizações costumam ter o impacto mais visível. Fatores para avaliar:

• Capacidade do servidor: hardware potente (CPU, RAM), software eficiente (servidor web, banco de dados) e configurações otimizadas fazem toda a diferença.
• Tempo de banco de dados: se a requisição busca dados no banco, consultas lentas são um gargalo crítico.
• Otimização de código: código mal escrito no servidor (scripts ineficientes, por exemplo) gera tempos longos de processamento.
• Estratégias de cache: cache eficiente (no servidor ou via Content Delivery Network) reduz drasticamente a carga de processamento nas requisições seguintes.

De volta ao navegador: entrega do primeiro byte

Após o processamento, o servidor envia a resposta de volta ao navegador, a começar pelo primeiro byte.

• Assim como na primeira etapa, as condições de rede e a distância também pesam aqui.
• As CDNs ajudam muito nessa fase, pois mantêm o conteúdo em cache mais perto dos usuários, reduzindo o tempo de trânsito.
• Redirecionamentos são enviados neste ponto, fazendo todo o processo recomeçar com atraso extra.

Etapas técnicas do Time to First Byte

Assim como no caminho entre a requisição e a resposta no navegador, o Time to First Byte das requisições de navegação pode ser medido com a Navigation Timing API e dividido em 5 etapas.

1. Tempo de redirecionamento: quando um recurso muda de endereço, o tempo do redirecionamento é somado ao TTFB do recurso.
2. Tempo de worker e cache: antes de buscar um recurso na internet, o navegador tenta encontrá-lo no cache local ou via worker (caso haja um configurado).
3. Tempo de consulta DNS: em seguida, o navegador pode precisar consultar o DNS para traduzir o domínio (www.example.com) em um endereço IP.
4. Tempo de conexão TCP: depois, o navegador se conecta ao servidor e executa algumas validações.
5. Handshake SSL: na sequência, o navegador e o servidor negociam a criptografia da comunicação.
6. Resposta do servidor: por fim, o servidor envia o HTML, gerando o conteúdo antes se necessário.

Como medir o Time to First Byte (TTFB)

Dica de PageSpeed: todo recurso tem seu próprio Time to First Byte. Mas, neste contexto, estamos falando do Time to First Byte da página principal.

O Time to First Byte varia muito conforme o usuário, o dispositivo e a localização. Por isso, medir o TTFB apenas pelo seu próprio computador não é uma boa ideia. Ferramentas como Pingdom ou GTMetrix também não são confiáveis pelo mesmo motivo.

A melhor forma de medir o Time to First Byte é coletar dados de Real User Metrics (RUM) dos visitantes. Você pode fazer isso manualmente com o código abaixo ou usar uma ferramenta de RUM como o CoreDash.

Meça o TTFB com ferramentas sintéticas

Meça o TTFB com monitoramento RUM

Meça o TTFB com dados do CrUX

O CrUX (Chrome User Experience Report) é uma base de dados pública do Google com dados de performance real de sites. O Google usa o CrUX para determinar se o site passa ou não nos Core Web Vitals.

Os dados do CrUX podem ser acessados por ferramentas como PageSpeed Insights, CrUX API, Looker Studio ou Google BigQuery. Use qualquer uma delas para consultar o TTFB do site.

Meça o TTFB com JavaScript

Para medir o Time to First Byte (TTFB) com JavaScript, você pode usar a Navigation Timing API. Basta criar um PerformanceObserver que monitore a entrada de navegação e registre a propriedade responseStart no console. O responseStart representa o momento exato em que o primeiro byte da resposta foi recebido. A biblioteca JavaScript web-vitals oferece uma forma mais concisa de medir o TTFB no navegador por meio da função onTTFB.

O código abaixo pode ser usado para medir o Time to First Byte (TTFB):

const formatTime = (time) => {

//round by 2 decimals, use Math.round() for integer
return Math.round(time * 100) / 100;
};

new PerformanceObserver((entryList) => {
const [pageNav] = entryList.getEntriesByType('navigation');

// timing start times are relative
const activationStart = pageNav.activationStart || 0;
const workerStart = Math.max(pageNav.workerStart - activationStart, activationStart);
const dnsStart = Math.max(pageNav.domainLookupStart - activationStart, workerStart);
const tcpStart = Math.max(pageNav.connectStart - activationStart, dnsStart);
const sslStart = Math.max(pageNav.secureConnectionStart - activationStart, tcpStart);
const requestStart = Math.max(pageNav.requestStart - activationStart, sslStart);
const responseStart = Math.max(pageNav.responseStart - activationStart, requestStart);

// attribution based on https://www.w3.org/TR/navigation-timing-2/#processing-model
// use associative array to log the results more readable
let attributionArray = [];
attributionArray['Redirect Time'] = { 'time in ms': formatTime(workerStart - activationStart) };
attributionArray['Worker and Cache Time'] = { 'time in ms': formatTime(dnsStart - workerStart) };
attributionArray['DNS Time'] = { 'time in ms': formatTime(tcpStart - dnsStart) };
attributionArray['TCP Time'] = { 'time in ms': formatTime(sslStart - tcpStart) };
attributionArray['SSL Time'] = { 'time in ms': formatTime(requestStart - sslStart) };
attributionArray['Request Time'] = { 'time in ms': formatTime(responseStart - requestStart) };
attributionArray['Total TTFB'] = { 'time in ms': formatTime(responseStart - activationStart) };

// log the results
console.log('%cTime to First Byte (' + formatTime(responseStart - activationStart) + 'ms)', 'color: blue; font-weight: bold;');
console.table(attributionArray);

console.log('%cOrigininal navigation entry', 'color: blue; font-weight: bold;');
console.log(pageNav);

}).observe({
type: 'navigation',
buffered: true
});

Encontre gargalos com a Server-Timing API

A Server-Timing API padroniza o envio de métricas de performance do servidor para o navegador. Com os cabeçalhos Server-Timing, você consegue medir e analisar com precisão os componentes do servidor que compõem o TTFB, identificando gargalos e melhorando a performance geral do site.

O cabeçalho Server-Timing pode incluir métricas para vários eventos separados por vírgula. Cada entrada é formada por:

• Um nome curto para a métrica (como database e processing)
• Uma duração em milissegundos (expressa como dur=123)
• Uma descrição opcional (expressa como desc="My Description")

Server-Timing: database;dur=123;desc="DB Query", processing;dur=234;desc="Template Render", cache;dur=0;desc="Cache HIT"

Como ler o Server-Timing no Chrome DevTools

O Chrome DevTools exibe as entradas de Server-Timing diretamente no painel Network. Abra o DevTools, selecione a requisição do documento na aba Network e role até a seção "Server Timing" dentro da aba Timing. Cada métrica enviada pelo cabeçalho Server-Timing aparece com nome, descrição e duração. Isso facilita identificar se o gargalo está no banco de dados, na renderização de templates ou na camada de cache.

Você também pode ler o cabeçalho Server-Timing via código e enviar esses dados para sua ferramenta de RUM favorita, como o CoreDash, para monitoramento contínuo e alertas.

Acelere o TTFB com o 103 Early Hints

103 Early Hints é um código de status HTTP que permite ao servidor enviar cabeçalhos de resposta preliminares ao navegador antes de a resposta definitiva estar pronta. Enquanto o servidor ainda processa a requisição (consultando o banco de dados, renderizando o template), o navegador já pode começar a carregar recursos críticos como folhas de estilo, fontes e a imagem do LCP.

Como funciona o 103 Early Hints

No fluxo tradicional de uma requisição, o navegador fica ocioso durante todo o tempo de processamento do servidor. Com o 103 Early Hints, o servidor envia uma resposta parcial assim que recebe a requisição. Essa resposta parcial traz cabeçalhos Link indicando quais recursos o navegador deve adiantar via preload ou preconnect. O navegador executa essas instruções enquanto aguarda a resposta 200 completa.

Isso transforma tempo ocioso de espera em tempo útil de carregamento. Embora o 103 Early Hints não reduza o TTFB do documento em si, ele diminui o impacto percebido do TTFB em métricas seguintes como LCP e FCP, adiantando a descoberta de recursos pelo navegador.

Exemplo de configuração de servidor para o 103 Early Hints

Várias CDNs e servidores web já são compatíveis com o 103 Early Hints. Veja um exemplo com a Cloudflare, que gera o 103 Early Hints automaticamente a partir de cabeçalhos Link e tags de preload/preconnect encontradas no HTML:

HTTP/1.1 103 Early Hints
Link: </style.css>; rel=preload; as=style
Link: </static/img/hero.webp>; rel=preload; as=image
Link: <https://fonts.googleapis.com>; rel=preconnect

HTTP/1.1 200 OK
Content-Type: text/html
...

No Nginx, você pode configurar o Early Hints adicionando cabeçalhos Link à resposta e ativando o push no HTTP/2 ou HTTP/3. O Apache é compatível com o 103 Early Hints por meio da diretiva H2EarlyHints. Consulte nosso guia detalhado sobre como implementar o 103 Early Hints para conferir o passo a passo.

Elimine o TTFB com a Speculation Rules API

A Speculation Rules API foi projetada para turbinar a performance de navegações futuras. Quando o visitante acessa a página, você pode usar as Speculation Rules para orientar o navegador a buscar previamente (com a diretiva prefetch) ou até renderizar por completo (com a diretiva prerender) as páginas com maior probabilidade de visita a seguir.

Como as Speculation Rules eliminam o TTFB

Quando uma página passa por prerender, o navegador carrega e renderiza o conteúdo por completo em uma aba oculta. Quando o usuário clica no link, a página já renderizada entra no ar instantaneamente. O resultado: um TTFB medido de 0 milissegundo. Esse valor não é teórico. Dados de RUM do CoreDash no corewebvitals.io confirmam que navegações pré-renderizadas com Speculation Rules apresentam um p75 de TTFB de 0ms.

O prefetching é uma alternativa mais leve. Em vez de renderizar a página por completo, o navegador apenas baixa o documento HTML e o salva no cache. Isso zera a parte de rede do TTFB, mas ainda exige que o navegador analise o código e renderize o documento no momento da navegação.

Sintaxe JSON das Speculation Rules

As Speculation Rules são configuradas por um bloco <script type="speculationrules"> em formato JSON. Veja um exemplo que aplica prerender a todos os links do menu com urgência "moderate" (acionada ao passar o mouse ou pressionar o ponteiro):

<script type="speculationrules">
{"prerender":
[{
  "source": "document",
  "where": {"selector_matches": "nav a"},
  "eagerness": "moderate"
}]}
</script>

Você também pode usar uma abordagem baseada em lista para URLs específicas:

<script type="speculationrules">
{"prefetch":
[{
  "source": "list",
  "urls": ["/core-web-vitals/", "/pagespeed/103-early-hints"]
}]}
</script>

A compatibilidade dos navegadores com as Speculation Rules está crescendo. O Chrome 121+ é compatível com a API completa, incluindo regras de documento. Para navegadores que ainda não têm suporte às Speculation Rules, você pode usar um script leve como o quicklink como fallback. Use nosso Gerador de Speculation Rules para criar a configuração ideal para o site.

Como a hospedagem afeta o Time to First Byte?

A hospedagem impacta o Time to First Byte de várias formas. Ao investir em uma hospedagem melhor, quase sempre dá para melhorar o Time to First Byte de imediato, sem mudar mais nada. Principalmente ao migrar de uma hospedagem compartilhada barata para servidores virtuais bem configurados e gerenciados, a melhora no TTFB pode ser gritante.

Dica de hospedagem: uma hospedagem superior oferece processamento mais ágil, velocidade de rede melhor e mais memória no servidor. Mas pagar caro nem sempre é garantia de qualidade. Muitos upgrades em planos compartilhados só entregam mais espaço em disco, e não mais poder de CPU.

Não recomendo trocar de hospedagem sem antes entender a causa raiz dos problemas de TTFB. O primeiro passo é configurar o monitoramento RUM e implementar os cabeçalhos Server-Timing.

Ao fazer upgrade da hospedagem, foque em pelo menos uma destas três melhorias:

• Mais recursos (CPU + RAM): essencial quando o servidor demora demais para gerar o HTML dinâmico.
• DNS mais rápido: muitos provedores de hospedagem barata são conhecidos pela performance ruim de DNS.
• Configuração melhor: busque cifras SSL mais rápidas, HTTP/3, compactação Brotli e acesso à configuração do servidor web (para desativar módulos desnecessários), entre outros pontos.

Como melhorar o TTFB: acelere a conexão inicial

Um Time to First Byte alto pode ter várias causas. No entanto, DNS, TCP e SSL afetam todo e qualquer TTFB. Vamos começar por aí. Mesmo que otimizar esses três pontos não traga o maior ganho isolado, essa melhoria vai otimizar cada TTFB individual.

Acelere o DNS

Dica de PageSpeed: DNS, TCP e SSL costumam ser problemas maiores quando você usa um servidor barato ou atende a um público global sem CDN. Use o monitoramento RUM para visualizar seu TTFB global e dividi-lo em etapas.

Use um provedor de DNS rápido. Nem todos os provedores de DNS têm a mesma velocidade. Alguns serviços (gratuitos) são simplesmente mais lentos do que outros. A Cloudflare, por exemplo, oferece um dos DNS mais rápidos do mundo de graça.

Aumente o TTL do DNS. Outra solução é aumentar o valor de Time to Live (TTL). O TTL determina por quanto tempo a resposta da consulta pode ficar em cache. Quanto maior o TTL, menor a chance de o navegador precisar fazer uma nova consulta de DNS. Vale lembrar que os provedores de internet (ISPs) também mantêm cache de DNS.

Acelere o TCP

A etapa do TCP no TTFB é a conexão inicial com o servidor web. Ao se conectarem, o navegador e o servidor combinam como os dados serão trocados. Dá para acelerar o TCP usando um servidor geograficamente mais próximo da sua localização e garantindo que ele tenha recursos livres suficientes. Às vezes, migrar para um servidor leve como o NGINX já acelera a etapa do TCP no TTFB. Na maioria dos casos, usar uma CDN resolve.

Acelere o SSL/TLS

Estabelecida a conexão TCP, o navegador e o servidor precisam proteger a comunicação com criptografia. Você pode acelerar essa etapa adotando protocolos e cifras SSL mais novas e leves, além de reduzir a distância física até o servidor web (já que a negociação TLS exige vários round-trips de ida e volta). Usar uma CDN costuma encurtar bastante o tempo de conexão SSL, já que as CDNs são muito bem configuradas e distribuídas globalmente. O TLS 1.3, em especial, foi desenhado para encurtar ao máximo a negociação TLS.

Como melhorar o TTFB: acelere o servidor

Cache de página

De longe, a forma mais eficiente de acelerar o Time to First Byte é entregar o HTML a partir do cache do servidor. Existem várias maneiras de implementar o cache de página inteira. A mais eficaz é fazer isso direto no nível do servidor web com, por exemplo, o módulo de cache do NGINX ou usando o Varnish como proxy reverso de cache.

Existem também diversos plugins para diferentes sistemas de CMS que fazem cache de páginas completas. Além disso, muitos frameworks SPA como o Next.js trazem implementações próprias de cache de página com diferentes estratégias de invalidação.

Se você quiser implementar seu próprio cache, a lógica é simples: quando o cliente requisitar uma página, verifique se ela existe na pasta de cache. Se não existir, gere a página, salve-a no cache e entregue o conteúdo normalmente. Na próxima requisição, o arquivo já existirá e você poderá entregá-lo direto do cache.

Cache parcial

No cache parcial, a ideia é salvar partes frequentes, lentas ou pesadas da página ou de recursos (como chamadas de API e consultas ao banco) para recuperação rápida. Isso elimina gargalos na geração da página. Se você quer se aprofundar nesse tipo de otimização, pesquise sobre estes conceitos: Memory Cache, Object Cache, Database Cache, Object-Relational Mapping (ORM) Cache, Content Fragment Cache e Opcode Cache.

Otimize o código da aplicação

Às vezes, a página não pode ser entregue a partir do cache (total ou parcial) porque o arquivo de cache não existe, boa parte do conteúdo é dinâmica ou surgem outros problemas. É por isso que precisamos otimizar o código da aplicação. Como fazer isso depende totalmente da aplicação: envolve reescrever e otimizar os trechos mais lentos do código.

Otimize as consultas ao banco de dados

Na maioria das vezes, consultas ineficientes ao banco de dados são a causa raiz de um Time to First Byte lento. Comece gravando em disco o log de "slow queries" e de consultas sem índices. Analise esses registros, adicione índices ou peça a um especialista para fazer o tuning do banco para corrigir esses problemas. Veja o MongoDB Performance Advisor e o MySQL Slow Query Log para saber mais.

Reduza a latência interna de rede

Uma má prática que vejo com mais frequência do que gostaria é o atraso no Time to First Byte provocado pela lentidão na comunicação entre a aplicação web e o armazenamento de dados. Isso costuma acontecer em sites grandes que terceirizam o armazenamento para APIs na nuvem.

Como melhorar o TTFB: acelere o lado do cliente

Cache no lado do cliente

O cache no lado do cliente consiste no navegador do usuário armazenar recursos já acessados, como imagens e scripts. Quando o usuário retorna ao site, o navegador recupera rapidamente os recursos em cache em vez de baixá-los novamente. Isso reduz consideravelmente o número de requisições feitas ao servidor, o que por sua vez diminui o TTFB.

Para implementar o cache no cliente, use o cabeçalho HTTP Cache-Control. Esse cabeçalho permite definir por quanto tempo o navegador deve manter um determinado recurso em cache.

Você também pode considerar armazenar o HTML da página inteira no cache do cliente. Isso derruba o TTFB, já que nenhuma requisição ao servidor é necessária. A desvantagem: depois que a página entra no cache do navegador, o usuário não verá nenhuma atualização na versão publicada até que o cache da página expire.

Service Workers

Service workers são scripts executados em segundo plano no navegador que conseguem interceptar requisições de rede. Isso significa que eles podem armazenar recursos em cache — como HTML, imagens, scripts e folhas de estilo —, para que, no retorno do usuário ao site, o navegador carregue esses arquivos direto do cache sem precisar baixá-los de novo.

Prefetch de páginas

Se você não quiser usar a Speculation Rules API por conta da sua compatibilidade limitada nos navegadores, você pode adotar um script leve chamado quicklink. Ele faz o prefetch de todos os links visíveis na viewport e praticamente elimina o Time to First Byte para esses links.

A desvantagem do quicklink é que ele exige mais recursos do navegador, mas por enquanto ele supera a Speculation Rules API em cobertura de navegadores.

Como melhorar o TTFB: use uma CDN

Uma Content Delivery Network (CDN) utiliza uma rede distribuída de servidores para entregar recursos aos usuários. Esses servidores ficam geograficamente mais perto dos usuários finais e altamente otimizados para velocidade. Se você usa a Cloudflare, confira nosso guia sobre como configurar a Cloudflare para otimizar a performance nos Core Web Vitals.

TTFB com CDN e cache no edge

TTFB sem CDN, hospedado na Alemanha

Uma CDN ajuda a melhorar 5 das 6 etapas do Time to First Byte:

• Tempo de redirecionamento: a maioria das CDNs armazena redirecionamentos em cache no edge ou usa edge workers para processá-los sem precisar bater no servidor de origem.
• Tempo de consulta DNS: a maioria das CDNs oferece servidores DNS extremamente rápidos, superando com facilidade os servidores DNS convencionais.
• Tempo de conexão TCP e handshake SSL: as CDNs têm configurações de ponta que, aliadas à proximidade física com o usuário final, aceleram muito o tempo de conexão e de handshake.
• Resposta do servidor: as CDNs encurtam o tempo de resposta do servidor de duas formas principais: salvando a resposta em cache no edge (cache de página inteira no edge) e entregando excelente compactação (Brotli), além dos protocolos mais novos (HTTP/3).

Como melhorar o TTFB: evite redirecionamentos

O tempo de redirecionamento é somado ao Time to First Byte. Por isso, como regra geral, evite redirecionamentos ao máximo. Eles ocorrem quando um recurso muda de endereço: o servidor responde com um cabeçalho de redirecionamento e o navegador dispara uma nova requisição para o novo endereço.

Redirecionamentos de mesma origem. Partem de links no próprio site. Você tem controle total sobre esses links e deve priorizar sua correção ao trabalhar no Time to First Byte. Existem diversas ferramentas para varrer o site inteiro atrás de redirecionamentos.

Redirecionamentos entre origens (cross-origin). Partem de links em outros sites. Você tem pouco ou nenhum controle sobre eles.

Múltiplos redirecionamentos. Ocorrem quando há cadeias de redirecionamento, em que um redirecionamento não leva diretamente ao destino final do recurso. Esse tipo de encadeamento sobrecarrega o Time to First Byte e deve ser evitado a qualquer custo. Mais uma vez, use uma ferramenta para encontrar esses casos e corrigi-los.

Redirecionamentos de HTTP para HTTPS. Uma forma de contornar isso é usar o cabeçalho Strict-Transport-Security (HSTS), que força o HTTPS logo na primeira visita a uma origem e orienta o navegador a acessar a origem diretamente pelo protocolo HTTPS nas visitas seguintes.

Quando um usuário acessa uma página, o servidor pode responder com um redirecionamento para outra página. Isso acrescenta tempo extra ao TTFB porque o navegador é obrigado a disparar uma nova requisição para o novo endereço.

Existem várias formas de evitar redirecionamentos ou minimizar seu impacto:

1. Atualize seus links internos: sempre que mudar o endereço de uma página, atualize os links internos para ela, garantindo que não sobre nenhuma referência à URL antiga.
2. Processe redirecionamentos no nível do servidor.
3. Use URLs relativas: ao criar links para páginas do seu próprio site, prefira URLs relativas em vez de URLs absolutas. Isso ajuda a prevenir redirecionamentos desnecessários.
4. Use URLs canônicas: se você tem páginas parecidas com conteúdos similares, use a URL canônica para indicar a versão preferencial. Isso evita conteúdo duplicado e redirecionamentos desnecessários.
5. Use redirecionamentos 301: se precisar redirecionar, use o código 301 em vez do 302. O redirecionamento 301 é definitivo, enquanto o 302 é temporário. O uso do redirecionamento 301 ajuda a evitar redirecionamentos desnecessários.

Otimize a priorização de recursos junto com o TTFB

Reduzir o TTFB é apenas uma parte da performance de carregamento. Assim que o primeiro byte chega, o navegador precisa saber quais recursos priorizar. Leia nosso guia de priorização de recursos para aprender como os recursos fetchpriority, preload e preconnect funcionam junto com um TTFB rápido para entregar carregamentos com máxima agilidade. Além disso, considere hospedar localmente as fontes do Google Fonts para eliminar consultas de DNS e tempos de conexão de terceiros que aumentam o TTFB percebido pelos usuários.

O que os dados reais de TTFB revelam

Os dados a seguir vêm do Real User Monitoring do CoreDash e do Web Almanac 2025.

A variação geográfica é enorme

O TTFB varia drasticamente com base na distância física entre o usuário e o servidor. Dados do CoreDash no corewebvitals.io (hospedado na Europa) mostram isso com clareza:

Usuários europeus perto do servidor têm TTFB abaixo de 170ms, enquanto usuários na Índia enfrentam um TTFB 3 vezes maior e usuários na China chegam a quase 10 vezes mais (1.468ms) devido ao Grande Firewall e à enorme distância física. Esses dados comprovam por que uma CDN com pontos de presença (edge) globais é indispensável para públicos internacionais.

Prerender com Speculation Rules entrega TTFB de 0ms

Dados por tipo de navegação do CoreDash confirmam que páginas pré-renderizadas via Speculation Rules atingem um p75 de TTFB de 0 milissegundo. Navegações normais registram 131ms, recarregamentos ficam em 82ms (beneficiados por conexões já ativas) e navegações de voltar/avançar são as mais lentas, com 244ms. Isso torna as Speculation Rules a técnica mais eficiente para zerar o TTFB nos carregamentos seguintes.

O TTFB no celular é 2,5 vezes maior que no desktop

No corewebvitals.io, usuários no celular têm um p75 de TTFB de 316ms, contra 124ms no desktop. Essa diferença de 2,5 vezes decorre da latência da rede móvel, não do servidor. Apenas 88,5% dos carregamentos no celular atingem a classificação "bom" no TTFB, comparados a 96,1% no desktop. Ao otimizar o TTFB, sempre teste em redes móveis reais.

Visitantes novos e recorrentes têm TTFB parecido

Neste site, visitantes novos registram um p75 de TTFB de 127ms, enquanto visitantes recorrentes ficam em 138ms. A proximidade dos números indica que o cache consistente no servidor (e não vantagens no cache do cliente) é o fator determinante para o TTFB. Em sites sem cache no servidor, a diferença entre visitantes novos e recorrentes costuma ser bem maior.

O TTFB global está estagnado há 5 anos

De acordo com o Web Almanac 2025, apenas 44% das páginas no celular atingem uma avaliação "boa" de TTFB no mundo. Esse número quase não mudou em relação aos 41% de 2021, tornando o TTFB a métrica de performance mais estagnada da web. Enquanto isso, o LCP subiu de 44% para 59% e o INP foi de 55% para 74% no mesmo período. Sites com LCP ruim gastam em média 2,27 segundos só no TTFB — consumindo quase todo o limite de 2,5 segundos do LCP.

Guias relacionados: etapas do TTFB

Cada etapa do Time to First Byte tem suas próprias estratégias de otimização:

• <b>Identificar e corrigir problemas de TTFB</b>: um guia prático de diagnóstico para encontrar a causa raiz de um TTFB lento usando DevTools, Server-Timing e dados de RUM.
• <b>Reduzir o tempo de espera</b>: como minimizar o tempo de redirecionamento e atrasos no processamento do servidor que inflam o TTFB.
• <b>Reduzir o tempo de cache</b>: estratégias de cache no navegador, service workers e back/forward cache (bfcache) para zerar o TTFB de visitantes recorrentes.
• <b>Minimizar o tempo de DNS</b>: como acelerar a resolução de DNS com provedores mais rápidos, valores mais altos de TTL e dicas de recursos com dns-prefetch.
• <b>Otimizar o tempo de conexão (TCP + TLS)</b>: como encurtar o tempo de handshake TCP e TLS usando HTTP/3, TLS 1.3, retomada de sessão e dicas de preconnect.