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 impacta diretamente tanto o Largest Contentful Paint (LCP) quanto o First Contentful Paint (FCP).

O que é o Time to First Byte

O Time to First Byte (TTFB) indica quanto tempo se passou em milissegundos entre o início da solicitação e o recebimento da primeira resposta (byte) de uma página. O TTFB é, portanto, também conhecido como tempo de espera. O TTFB é uma forma de medir a capacidade de resposta de um servidor web e o caminho de rede entre o usuário e esse servidor. O TTFB é uma métrica fundamental; isso significa que o tempo adicionado ao TTFB também será adicionado ao Largest Contentful Paint e ao First Contentful Paint. Cada milissegundo economizado no TTFB é um milissegundo economizado nessas duas métricas de renderização.

O TTFB não é um Core Web Vital

É importante afirmar isso com clareza: o TTFB não é um dos três Core Web Vitals. Os Core Web Vitals consistem no Largest Contentful Paint (LCP), no Interaction to Next Paint (INP) e no Cumulative Layout Shift (CLS). O Google não usa o TTFB diretamente nos seus sinais de classificação de experiência da página.

No entanto, o TTFB é classificado como uma métrica de diagnóstico. Ele ajuda você a entender por que o seu LCP ou FCP pode estar lento. De acordo com o Web Almanac de 2025, sites com um LCP ruim gastam em média 2,27 segundos apenas no TTFB, o que quase esgota o limite inteiro de 2,5 segundos do LCP antes mesmo de o navegador começar a renderizar a página. Corrigir o TTFB é, portanto, uma das coisas mais impactantes que você pode fazer para as suas pontuações gerais dos Core Web Vitals.

Por que o Time to First Byte é importante

O Time to First Byte não é um Core Web Vital e é muito possível passar nos Core Web Vitals enquanto falha na métrica do TTFB. Isso não significa que o TTFB não seja importante. O TTFB é uma métrica extremamente importante de otimizar, e corrigir o TTFB melhorará muito a velocidade da página e a experiência da página.

O impacto do TTFB para os visitantes

O Time to First Byte precede todas as outras métricas de renderização. Enquanto o navegador aguarda o Time to First Byte, ele não pode fazer nada e apenas mostrará uma tela em branco. Isso significa que qualquer aumento no Time to First Byte resultará em um tempo extra de "tela em branco" e qualquer diminuição no Time to First Byte se traduzirá em menos tempo de "tela em branco".

Para obter aquela sensação de páginas com 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 contabiliza a renderização: um TTFB baixo não significa necessariamente uma boa experiência do usuário porque não considera o tempo que o navegador leva para renderizar a página. Mesmo que todos os bytes sejam baixados rapidamente, a página ainda pode demorar muito para ser exibida se o navegador precisar processar muito JavaScript ou renderizar layouts complexos.

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

Recomenda-se que o seu servidor responda às solicitações de navegação rápido o suficiente para que o percentil 75 dos usuários experimente um FCP dentro do limite "bom". Como uma regra geral, a maioria dos sites deve se esforçar para ter um TTFB de 0,8 segundo ou menos.

• Um TTFB abaixo de 800 milissegundos é considerado bom.
• Um TTFB entre 800 e 1800 milissegundos precisa de melhoria.
• Um TTFB acima de 1800 milissegundos é considerado ruim e deve ser melhorado imediatamente.

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

A T-Mobile investiu pesado na redução do seu Time to First Byte como parte de uma iniciativa mais ampla de otimização de desempenho. Os resultados foram impressionantes: um aumento de 60% nas conversões de visita para pedido. Ao mudar para páginas renderizadas na borda e cache agressivo no lado do servidor, a T-Mobile reduziu drasticamente o tempo que os usuários passavam esperando pelo primeiro byte, o que se desdobrou em um LCP mais rápido, um FCP mais rápido e uma experiência do usuário mensuravelmente melhor. Este estudo de caso demonstra que a otimização do TTFB não é apenas um exercício técnico; ela afeta diretamente os resultados de negócios.

O TTFB da solicitação à resposta

Do navegador para o servidor: a solicitação

O tempo de solicitação do navegador é o tempo decorrido desde o momento em que o navegador de um usuário envia uma solicitação HTTP até que essa solicitação alcance o servidor que hospeda o site. O TTFB desta parte está em grande parte além do controle direto do site e depende fortemente de:

• A velocidade da internet do usuário.
• A qualidade da infraestrutura de rede dele.
• A distância física entre o usuário e o servidor.

Dentro desta etapa, a pesquisa de DNS, o tempo de inicialização do navegador, as pesquisas de cache do navegador e a negociação da conexão com o servidor (TCP e TLS) tomam um pouco de tempo.

No servidor: processando e preparando a resposta

Assim que o servidor recebe a solicitação, o relógio está correndo enquanto ele trabalha para gerar uma resposta. Esta etapa é onde a maioria dos desenvolvedores tende a focar e onde os esforços de otimização podem ter o impacto mais significativo. Os fatores a considerar incluem:

• Capacidades do servidor: Hardware poderoso (CPU, RAM), software eficiente (servidor web, banco de dados) e configurações otimizadas são essenciais.
• Duração do banco de dados: Se a solicitação exige a busca de dados em um banco de dados, consultas lentas podem ser um grande gargalo.
• Otimização de código: Código mal escrito no lado do servidor (por exemplo, scripts ineficientes) pode levar a longos tempos de processamento.
• Estratégias de cache: O cache efetivo (como o cache no lado do servidor ou o uso de uma Content Delivery Network) pode reduzir drasticamente a carga de processamento para solicitações repetidas.

De volta ao navegador: entregando o primeiro byte

Após o processamento, o servidor envia a resposta, começando pelo primeiro byte, de volta para o navegador do usuário.

• De forma semelhante à primeira etapa, as condições da rede e a distância desempenham um papel aqui também.
• As CDNs são particularmente benéficas nesta etapa porque armazenam conteúdo em cache mais perto dos usuários, minimizando o tempo de viagem.
• Os redirecionamentos são servidos neste ponto, o que faz com que o processo se repita com um atraso extra.

Etapas técnicas do Time To First Byte

Assim como no caminho da "solicitação à resposta" no seu navegador, o Time To First Byte das solicitações de navegação pode ser medido com a Navigation Timing API e dividido em 5 subpartes.

1. Tempo de redirecionamento: quando um recurso foi movido para um novo local, o tempo de redirecionamento é adicionado ao TTFB do recurso.
2. Tempo do worker e do cache: antes de um recurso ser buscado na internet, um navegador tentará primeiro procurá-lo no seu próprio cache ou através de um worker (se um worker tiver sido configurado).
3. Tempo de pesquisa de DNS: Em seguida, um navegador pode precisar realizar uma pesquisa de DNS para traduzir o nome de domínio (www.example.com) em um endereço IP.
4. Tempo de conexão TCP: Então o navegador se conectará ao servidor e realizará algumas verificações.
5. Handshake SSL: Em seguida, o navegador e o servidor criptografarão a sua comunicação.
6. Resposta do servidor: Por fim, o servidor precisa enviar o HTML. Ele pode precisar gerar o HTML primeiro.

Como medir o Time To First Byte (TTFB)

DICA do PageSpeed: cada recurso tem o seu próprio Time to First Byte. Neste contexto, no entanto, estamos falando sobre o Time to First Byte da página principal.

O Time to First Byte pode flutuar muito entre diferentes usuários com diferentes dispositivos e de diferentes locais. É por isso que automedir o Time to First Byte a partir do seu computador desktop provavelmente não é uma boa ideia. Usar ferramentas como o Pingdom ou o GTmetrix não é confiável pelo mesmo motivo.

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

Medir o TTFB com ferramentas sintéticas

Medir o TTFB com rastreamento RUM

Medir o TTFB com dados do CrUX

O CrUX (Chrome User Experience Report) é um conjunto de dados disponível publicamente pelo Google que contém dados de desempenho no mundo real para sites. O Google usa o conjunto de dados do CrUX para determinar se você está passando ou não nos Core Web Vitals.

O conjunto de dados do CrUX pode ser acessado através de ferramentas como o PageSpeed Insights, a API do CrUX, o Looker Studio ou o Google BigQuery. Use qualquer uma destas ferramentas para obter o TTFB para o seu site.

Medir o TTFB com JavaScript

Para medir o Time to First Byte (TTFB) com JavaScript, você pode usar a Navigation Timing API. Você pode criar um PerformanceObserver que escuta uma entrada de navegação e registra a propriedade responseStart no console. A propriedade responseStart representa o registro de data e hora em que o primeiro byte da resposta foi recebido. A biblioteca JavaScript web-vitals fornece uma forma mais concisa de medir o TTFB no navegador usando a função onTTFB.

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

const formatTime = (time) => {

// arredonda para 2 casas decimais, use Math.round() para número inteiro
return Math.round(time * 100) / 100;
};

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

// os tempos de início são relativos
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);

// atribuição baseada em https://www.w3.org/TR/navigation-timing-2/#processing-model
// use um array associativo para registrar os resultados de forma mais legível
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) };

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

console.log('%cEntrada de navegação original', 'color: blue; font-weight: bold;');
console.log(pageNav);

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

Encontre gargalos com a Server-Timing API

A Server-Timing API fornece uma forma padronizada de enviar tempos de desempenho do servidor back-end para o navegador. Ao utilizar os cabeçalhos Server-Timing, os desenvolvedores podem medir e analisar efetivamente os componentes no lado do servidor que contribuem para o TTFB, ajudando a identificar áreas para otimização e melhorando o desempenho geral do site.

O cabeçalho Server-Timing pode conter tempos para várias métricas separados por vírgulas. Cada entrada consiste em:

• 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"

Lendo o Server-Timing no Chrome DevTools

O Chrome DevTools exibe as entradas do Server-Timing diretamente no painel Network. Abra o DevTools, selecione a solicitação do documento na aba Network e role para baixo até a seção "Server Timing" na aba Timing. Cada métrica que você envia através do cabeçalho Server-Timing aparecerá com o seu nome, descrição e duração. Isso torna simples identificar se o seu banco de dados, renderização de modelo ou camada de cache é o gargalo.

Você também pode ler o cabeçalho Server-Timing de forma programática e enviar esses tempos para a sua ferramenta de RUM favorita, como o CoreDash, para rastreamento e alertas de longo prazo.

Acelere o TTFB com 103 Early Hints

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

Como o 103 Early Hints funciona

Em um fluxo de solicitação tradicional, o navegador fica ocioso durante todo o tempo de processamento do servidor. Com o 103 Early Hints, o servidor envia uma resposta parcial imediatamente após receber a solicitação. Esta resposta parcial contém cabeçalhos Link que dizem ao navegador quais recursos ele deve fazer preload ou preconnect. O navegador atua nessas dicas (hints) enquanto espera pela resposta 200 completa.

Isso efetivamente transforma o tempo de espera morto em tempo de carregamento produtivo. Embora o 103 Early Hints não reduza o TTFB do documento em si, ele reduz o impacto percebido do TTFB em métricas subsequentes como o LCP e o FCP, dando ao navegador uma vantagem na descoberta de recursos.

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

Muitas CDNs e servidores web agora suportam o 103 Early Hints. Aqui está um exemplo usando a Cloudflare, que gera automaticamente o 103 Early Hints a partir de cabeçalhos Link e tags preload/preconnect encontradas no seu 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
...

Para o Nginx, você pode configurar o Early Hints adicionando cabeçalhos Link à sua resposta e ativando o push no HTTP/2 ou HTTP/3. O Apache suporta o 103 Early Hints através da diretiva H2EarlyHints. Confira o nosso guia detalhado sobre a implementação do 103 Early Hints para obter instruções passo a passo.

Elimine o TTFB com a Speculation Rules API

A Speculation Rules API é projetada para melhorar o desempenho de navegações futuras. Uma vez que um visitante chegou na sua página, você pode usar as Speculation Rules para instruir um navegador a buscar (com a diretiva prefetch) ou até mesmo renderizar totalmente (com a diretiva prerender) as páginas que o visitante tem maior probabilidade de visitar a seguir.

Como as Speculation Rules eliminam o TTFB

Quando uma página é pré-renderizada (prerendered), o navegador a carrega e renderiza completamente em uma aba oculta. Quando o usuário clica no link, a página pré-renderizada é trocada instantaneamente. O resultado: um TTFB medido de 0 milissegundos. Este não é um número teórico. Dados de RUM do CoreDash no corewebvitals.io confirmam que as navegações pré-renderizadas através das Speculation Rules mostram um TTFB de p75 de 0ms.

O Prefetching é uma alternativa mais leve. Em vez de renderizar a página totalmente, o navegador busca apenas o documento HTML e o armazena em cache. Isso elimina a parte de rede do TTFB, embora ainda exija que o navegador faça o parse e renderize o documento no momento da navegação.

Sintaxe JSON das Speculation Rules

As Speculation Rules são definidas usando um bloco <script type="speculationrules"> contendo JSON. Aqui está um exemplo que pré-renderiza todos os links de navegação na sua barra de menu com eagerness "moderate" (acionada no hover ou no pointer down):

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

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

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

O suporte dos navegadores às Speculation Rules está crescendo. O Chrome 121+ suporta a API completa, incluindo regras de documento. Para navegadores que ainda não suportam as Speculation Rules, você pode usar um script leve como o quicklink como fallback. Use o nosso Gerador de Speculation Rules para criar a configuração certa para o seu site.

Como a hospedagem afeta o Time to First Byte?

A hospedagem afeta o Time to First Byte de várias formas. Ao investir em uma hospedagem melhor, geralmente é possível melhorar imediatamente o Time to First Byte sem alterar mais nada. Principalmente ao mudar de uma hospedagem compartilhada de baixo custo para servidores virtuais gerenciados e configurados corretamente, o TTFB pode melhorar drasticamente.

DICA de Hospedagem: uma hospedagem melhor envolve um processamento mais rápido, uma velocidade de rede melhor e mais memória de servidor, e mais rápida. Uma hospedagem cara nem sempre é igual a uma hospedagem melhor. Muitos upgrades em serviços de hospedagem compartilhada rendem apenas mais armazenamento, e não mais poder de CPU.

Não recomendo trocar de hospedagem sem saber as causas raízes dos problemas de TTFB. Aconselho você a configurar o rastreamento RUM e adicionar os cabeçalhos Server-Timing.

Ao atualizar a sua hospedagem, você geralmente deve procurar pelo menos uma destas três melhorias:

• Obter mais recursos (CPU + RAM): Especialmente quando o servidor leva muito tempo para gerar o HTML dinâmico.
• DNS mais rápido: Muitos provedores de hospedagem de baixo custo são conhecidos pelo seu baixo desempenho de DNS.
• Configuração melhor: Procure por cifras SSL mais rápidas, HTTP/3, compressão Brotli e acesso à configuração do servidor web (para desabilitar módulos desnecessários), para citar alguns.

Como melhorar o TTFB: acelere a conexão inicial

Um Time to First Byte alto pode ter várias causas. No entanto, o DNS, o TCP e o SSL afetam todos os Time to First Bytes. Então vamos começar por aí. Mesmo que a otimização desses três possa não render os maiores resultados, otimizá-los otimizará cada TTFB único.

Acelere o DNS

DICA do PageSpeed: o DNS, o TCP e o SSL geralmente são um problema maior quando você está usando uma hospedagem barata ou quando atende a um público global sem usar uma CDN. Use o rastreamento RUM para visualizar o seu TTFB global e divida o TTFB nas suas subpartes.

Use um provedor de DNS rápido. Nem todos os provedores de DNS são tão rápidos quanto os outros. Alguns provedores de DNS (gratuitos) são apenas mais lentos do que outros provedores de DNS (gratuitos). A Cloudflare, por exemplo, dará a você um dos provedores de DNS mais rápidos do mundo de graça.

Aumente o TTL do DNS. Outra forma é aumentar o valor do Time to Live (TTL). O TTL é uma configuração que determina por quanto tempo a pesquisa pode ser armazenada em cache. Quanto maior o TTL, menor a probabilidade de o navegador precisar realizar outra pesquisa de DNS. É importante observar que os ISPs também fazem cache de DNS.

Acelere o TCP

A "parte TCP" do TTFB é a conexão inicial ao servidor web. Ao conectar, o navegador e o servidor compartilham informações sobre como os dados serão trocados. Você pode acelerar o TCP conectando-se a um servidor que esteja geograficamente próximo à sua localização e garantindo que o servidor tenha recursos livres suficientes. Às vezes, mudar para um servidor leve como o NGINX pode acelerar a parte TCP do TTFB. Em muitos casos, o uso de uma CDN acelerará a conexão TCP.

Acelere o SSL/TLS

Assim que a conexão TCP for feita, o navegador e o servidor precisarão garantir a segurança da conexão através da criptografia. Você pode acelerar isso usando protocolos (cifras SSL) mais rápidos, mais novos e mais leves e por estar geograficamente mais próximo do seu servidor web (já que a negociação TLS leva várias viagens de ida e volta). O uso de uma CDN muitas vezes melhorará o tempo de conexão SSL, já que as CDNs geralmente são muito bem configuradas e têm vários servidores em todo o mundo. O TLS 1.3 em particular é projetado para manter a negociação TLS o mais curta possível.

Como melhorar o TTFB: acelere o lado do servidor

Cache de página

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

Também existem muitos plugins para diferentes sistemas CMS que farão o cache de páginas inteiras e muitos frameworks SPA como o Next.js têm a sua própria implementação de cache de página inteira, juntamente com diferentes estratégias de invalidação.

Se você gostaria de implementar o seu próprio cache, a ideia básica é simples. Quando um cliente solicita uma página, verifique se ela existe na pasta de cache. Se não existir, crie a página, grave-a no cache e mostre a página como você faria normalmente. Em qualquer próxima solicitação para a página, o arquivo de cache existirá e você poderá servir a página diretamente do cache.

Cache parcial

Com o cache parcial, a ideia é armazenar em cache partes da página ou recursos frequentemente usados, lentos ou caros (como chamadas de API, resultados do banco de dados) para recuperação rápida. Isso eliminará gargalos ao gerar uma página. Se você estiver interessado nesses tipos de otimizações, você deve procurar por 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 servida do cache (parcial) porque o arquivo de cache não existe, grandes partes das páginas são dinâmicas ou porque você esbarra em outros problemas. É por isso que precisamos otimizar o código da aplicação. A forma como isso é feito depende inteiramente da sua aplicação. Isso se baseia em reescrever e otimizar partes lentas do seu código.

Otimize as consultas do banco de dados

Na maioria das vezes, as consultas ineficazes do banco de dados são a causa raiz de um Time to First Byte lento. Comece registrando "consultas lentas" e "consultas que não usam índices" no disco. Analise-as, adicione índices ou peça a um especialista para realizar o ajuste do banco de dados para corrigir esses problemas. Veja o MongoDB Performance Advisor e o MySQL Slow Query Log para obter mais detalhes.

Reduza a latência da rede interna

Uma má prática com a qual me deparo mais vezes do que gostaria é um atraso no Time to First Byte causado pela lentidão na comunicação entre a aplicação web e o armazenamento de dados. Isso geralmente acontece apenas com sites grandes que terceirizaram o seu armazenamento de dados para APIs na nuvem.

Como melhorar o TTFB: acelere o lado do cliente

Cache no lado do cliente

O cache no lado do cliente envolve o navegador do usuário armazenando recursos que ele já acessou, como imagens e scripts. Assim, quando o usuário voltar ao seu site, o navegador dele poderá recuperar rapidamente os recursos em cache em vez de ter que baixá-los novamente. Isso pode reduzir significativamente o número de solicitações feitas ao servidor, o que, por sua vez, pode reduzir o TTFB.

Para implementar o cache no lado do cliente, você pode usar o cabeçalho HTTP Cache-Control. Esse cabeçalho permite que você especifique por quanto tempo o navegador deve armazenar um determinado recurso em cache.

Você poderia considerar fazer o cache completo do HTML da página no lado do cliente. Isso reduzirá drasticamente o TTFB, pois não será necessária nenhuma solicitação ao servidor. A desvantagem é que, uma vez que a página esteja no cache do navegador, quaisquer atualizações na versão ativa da página não serão vistas pelo usuário até que o cache da página expire.

Service Workers

Service workers são scripts que rodam no background do navegador de um usuário e podem interceptar as solicitações de rede feitas pelo navegador. Isso significa que os service workers podem armazenar em cache recursos como HTML, imagens, scripts e folhas de estilo, para que, quando o usuário voltar ao seu site, o navegador dele possa recuperar rapidamente os recursos em cache em vez de ter que baixá-los novamente.

Prefetching de página

Se você não deseja usar a Speculation Rules API devido ao seu suporte de navegador limitado, você pode usar um pequeno script chamado quicklink. Isso fará o prefetch de todos os links no viewport visível e praticamente eliminará o Time To First Byte para esses links.

A desvantagem do quicklink é que ele requer mais recursos do navegador, mas por enquanto ele superará a Speculation Rules API em termos de cobertura de navegadores.

Como melhorar o TTFB: use uma CDN

Uma Content Delivery Network ou CDN usa uma rede distribuída de servidores para entregar recursos aos usuários. Esses servidores geralmente estão geograficamente mais próximos dos usuários finais e altamente otimizados para velocidade. Se você estiver usando a Cloudflare, confira o nosso guia sobre como configurar a Cloudflare para um desempenho ideal nos Core Web Vitals.

TTFB com uma CDN e cache na borda

TTFB sem uma CDN, hospedado na Alemanha

Uma CDN pode ajudar a melhorar 5 das 6 partes do Time to First Byte:

• Tempo de redirecionamento: A maioria das CDNs pode armazenar redirecionamentos em cache na borda ou usar edge workers para lidar com redirecionamentos sem a necessidade de conectar ao servidor de origem.
• Tempo de pesquisa de DNS: A maioria das CDNs oferece servidores DNS extremamente rápidos que provavelmente superarão os seus servidores DNS atuais.
• Conexão TCP e tempo do Handshake SSL: A maioria das CDNs é configurada muito bem, e essas configurações, juntamente com a proximidade mais estreita aos usuários finais, acelerarão o tempo de conexão e de handshake.
• Resposta do servidor: CDNs podem acelerar o tempo de resposta do servidor de algumas maneiras. A primeira é armazenando a resposta do servidor em cache na borda (cache de página inteira na borda), mas também oferecendo uma compressão excelente (Brotli) e os protocolos mais novos (HTTP/3).

Como melhorar o TTFB: evite redirecionamentos

O tempo de redirecionamento é adicionado ao Time To First Byte. Portanto, como uma regra geral, evite redirecionamentos o máximo possível. Os redirecionamentos podem ocorrer quando um recurso não está mais disponível em um local, mas foi movido para outro local. O servidor responderá com um cabeçalho de resposta de redirecionamento e o navegador tentará esse novo local.

Redirecionamentos de mesma origem. Os redirecionamentos de mesma origem vêm de links do seu próprio site. Você deve ter controle total sobre esses links e deve priorizar a correção desses links ao trabalhar no Time to First Byte. Existem muitas ferramentas disponíveis que permitem verificar o seu site inteiro em busca de redirecionamentos.

Redirecionamentos de origens diferentes. Os redirecionamentos de origens diferentes vêm de links em outros sites. Você tem muito pouco controle sobre eles.

Múltiplos redirecionamentos. Múltiplos redirecionamentos ou cadeias de redirecionamento ocorrem quando um único redirecionamento não direciona para o local final do recurso. Esses tipos de redirecionamentos colocam mais pressão sobre o Time to First Byte e devem ser evitados a todo custo. Mais uma vez, use uma ferramenta para encontrar esses tipos de redirecionamentos e corrigi-los.

Redirecionamentos HTTP para HTTPS. Uma forma de contornar isso é usar o cabeçalho Strict-Transport-Security (HSTS), que forçará o HTTPS na primeira visita a uma origem e, em seguida, dirá ao navegador para acessar imediatamente a origem por meio do esquema HTTPS em visitas futuras.

Quando um usuário solicita uma página web, o servidor pode responder com um redirecionamento para outra página. Esse redirecionamento pode adicionar tempo extra ao TTFB porque o navegador deve fazer uma solicitação adicional para a nova página.

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

1. Atualize os seus links internos. Sempre que você alterar a localização de uma página, atualize os seus links internos para essa página a fim de garantir que nenhuma referência à localização anterior da página permaneça.
2. Lide com redirecionamentos no nível do servidor.
3. Use URLs relativos: Ao criar links para páginas do seu próprio site, use URLs relativos em vez de URLs absolutos. Isso ajudará a prevenir redirecionamentos desnecessários.
4. Use URLs canônicos: Se você tem várias páginas com conteúdo semelhante, use um URL canônico para indicar a versão preferida da página. Isso ajudará a prevenir conteúdo duplicado e redirecionamentos desnecessários.
5. Use redirecionamentos 301: Se você deve usar um redirecionamento, use um redirecionamento 301 em vez de um redirecionamento 302. Um redirecionamento 301 é um redirecionamento permanente, enquanto um redirecionamento 302 é um redirecionamento temporário. O uso de um redirecionamento 301 ajudará a prevenir redirecionamentos desnecessários.

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

Reduzir o TTFB é apenas parte da história do desempenho de carregamento. Assim que o primeiro byte chega, o navegador precisa saber quais recursos priorizar. Leia o nosso guia sobre a priorização de recursos para aprender como dicas (hints) fetchpriority, preload e preconnect funcionam juntas com um TTFB rápido para fornecer carregamentos de página o mais rápido possível. Além disso, considere hospedar localmente as suas Google Fonts para eliminar pesquisas de DNS de terceiros e tempos de conexão que são adicionados ao TTFB percebido pelos seus usuários.

O que os dados reais de TTFB mostram

Os dados a seguir vêm do Real User Monitoring do CoreDash e do Web Almanac de 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. Os dados do CoreDash do corewebvitals.io (hospedado na Europa) ilustram isso claramente:

Usuários europeus próximos ao servidor veem um TTFB abaixo de 170ms, enquanto os usuários na Índia experimentam um TTFB 3x maior e os usuários na China veem um TTFB quase 10x maior (1.468ms) devido ao Grande Firewall e à distância física absoluta. Estes dados demonstram por que uma CDN com locais de borda globais é essencial para públicos internacionais.

A pré-renderização via Speculation Rules entrega um TTFB de 0ms

Os dados de tipo de navegação do CoreDash confirmam que as páginas pré-renderizadas por meio de Speculation Rules atingem um TTFB de p75 de 0 milissegundos. Navegações padrão medem 131ms, recarregamentos chegam a 82ms (se beneficiando de conexões aquecidas), e as navegações de voltar e avançar são as mais lentas em 244ms. Isso faz das Speculation Rules a técnica mais eficaz para eliminar o TTFB em carregamentos de página subsequentes.

O TTFB no mobile é 2,5x o do desktop

No corewebvitals.io, os usuários de dispositivos móveis experimentam um TTFB de p75 de 316ms em comparação com 124ms no desktop. Esta lacuna de 2,5x é causada pela latência da rede móvel, não por diferenças de servidor. Apenas 88,5% dos carregamentos de página no mobile alcançam uma classificação de TTFB "boa" em comparação com 96,1% no desktop. Ao otimizar o TTFB, sempre teste em redes móveis reais.

Visitantes novos vs. repetidos veem um TTFB semelhante

Neste site, novos visitantes veem um TTFB de p75 de 127ms enquanto visitantes repetidos veem 138ms. A semelhança sugere que o cache consistente no lado do servidor (em vez de vantagens de cache no lado do cliente) é o fator principal no desempenho do TTFB. Em sites sem cache no lado do servidor, a diferença entre visitantes novos e repetidos pode ser muito maior.

O TTFB global estagnou por 5 anos

De acordo com o Web Almanac de 2025, apenas 44% das páginas mobile alcançam uma pontuação de TTFB "boa" globalmente. Este número quase não mudou de 41% em 2021, tornando o TTFB a métrica de desempenho mais estagnada na web. Enquanto isso, o LCP melhorou de 44% para 59% e o INP de 55% para 74% no mesmo período. Sites com um LCP ruim gastam uma média de 2,27 segundos apenas no TTFB, quase o limite inteiro de 2,5 segundos do LCP.

Guias Relacionados: Subpartes do TTFB

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

• <b>Corrija e Identifique Problemas de TTFB</b>: Um guia de diagnóstico passo a passo para encontrar a causa raiz de um TTFB lento usando o DevTools, Server-Timing e dados de RUM.
• <b>Reduza a Duração da Espera</b>: Como minimizar o tempo de redirecionamento e os atrasos no processamento do servidor que aumentam o seu TTFB.
• <b>Reduza a Duração do Cache</b>: Estratégias para cache do navegador, service workers e back/forward cache (bfcache) para eliminar o TTFB para visitantes recorrentes.
• <b>Minimize a Duração do DNS</b>: Como acelerar a resolução de DNS com provedores de DNS mais rápidos, valores de TTL aumentados e dicas (hints) de recursos dns-prefetch.
• <b>Otimize a Duração da Conexão (TCP + TLS)</b>: Reduzindo o tempo de handshake TCP e TLS com HTTP/3, TLS 1.3, retomada de sessão e dicas (hints) preconnect.