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

O Time to First Byte (TTFB) mede o tempo em milissegundos entre a solicitação de uma página pelo navegador e o recebimento do primeiro byte da resposta do servidor. Um bom TTFB é de 800 milissegundos ou menos no 75º percentil. O TTFB não é um Core Web Vital, mas é uma métrica de diagnóstico crítica porque impacta 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 quanto tempo se passou em milissegundos entre o início da solicitação e o recebimento da primeira resposta (byte) de uma página da web. O TTFB, portanto, também é chamado de tempo de espera. O TTFB é uma maneira de medir a capacidade de resposta de um servidor web e do 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 em ambas essas métricas de pintura.

O TTFB não é um Core Web Vital

É importante afirmar isso de forma clara: O TTFB não é um dos três Core Web Vitals. Os Core Web Vitals consistem em Largest Contentful Paint (LCP), Interaction to Next Paint (INP) e Cumulative Layout Shift (CLS). O Google não usa o TTFB diretamente em 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 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 todo o limite de 2,5 segundos do LCP antes mesmo que o navegador comece a renderizar a página. Corrigir o TTFB é, portanto, uma das coisas mais impactantes que você pode fazer por suas pontuações gerais de 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 de TTFB. Isso não significa que o TTFB não seja importante. O TTFB é uma métrica extremamente importante para 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 pintura. Enquanto o navegador está esperando pelo 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 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 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 contabiliza a renderização: um baixo TTFB não significa necessariamente uma boa experiência do usuário porque não considera o tempo que leva para o navegador renderizar a página da web. Mesmo que todos os bytes sejam baixados rapidamente, a página da web 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 seu servidor responda às solicitações de navegação rápido o suficiente para que o 75º percentil de usuários experimente um FCP dentro do limite "bom". Como um guia geral, a maioria dos sites deve se esforçar para ter um TTFB de 0,8 segundos ou menos.

• Um TTFB abaixo de 800 milissegundos é considerado bom.
• Um TTFB entre 800 e 1800 milissegundos precisa de melhorias.
• 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 pesadamente 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, FCP mais rápido e uma experiência do usuário significativamente melhor. Este estudo de caso demonstra que a otimização do TTFB não é apenas um exercício técnico; 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á amplamente fora do controle direto do site e depende fortemente de:

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

Nesta 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 se concentrar e onde os esforços de otimização podem ter o impacto mais significativo. Os fatores a serem considerados incluem:

• Capacidades do Servidor: Hardware poderoso (CPU, RAM), software eficiente (servidor web, banco de dados) e configurações otimizadas são importantes.
• Duração do Banco de Dados: Se a solicitação exigir a busca de dados de 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 eficaz (como o cache no lado do servidor ou o uso de uma Content Delivery Network) pode reduzir drasticamente o fardo 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.

• Semelhante à primeira etapa, as condições da rede e a distância também desempenham um papel aqui.
• As CDNs são particularmente benéficas nesta etapa, pois armazenam conteúdo em cache mais perto dos usuários, minimizando o tempo de viagem.
• 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

Semelhante ao "caminho da solicitação à resposta" em 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 que um recurso seja buscado na internet, um navegador primeiro tentará procurá-lo em seu próprio cache ou por meio 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 comunicação deles.
6. Resposta do servidor: Finalmente, o servidor precisa enviar o HTML. Pode ser necessário 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 do 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 auto-medir o Time to First Byte do seu computador desktop provavelmente não é uma ótima ideia. Usar ferramentas como Pingdom ou GTMetrix não é confiável pelo mesmo motivo.

A melhor maneira de medir o Time To First Byte é coletar dados de Real User Metrics (RUM) dos seus visitantes. Você mesmo pode fazer isso 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 publicamente disponível do 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á ou não passando nos Core Web Vitals.

O conjunto de dados do CrUX pode ser acessado por meio de ferramentas como o PageSpeed Insights, a API do CrUX, Looker Studio ou Google BigQuery. Use qualquer uma dessas 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 maneira 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) => {

//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
});

Encontrar gargalos com a Server-Timing API

A Server-Timing API fornece uma maneira padronizada de enviar tempos de desempenho do servidor backend para o navegador. Utilizando os cabeçalhos Server-Timing, os desenvolvedores podem medir e analisar de forma eficaz os componentes do 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 guia Network, role para baixo até a seção "Server Timing" na guia Timing. Cada métrica que você enviar por meio do cabeçalho Server-Timing aparecerá com seu nome, descrição e duração. Isso torna simples identificar se seu banco de dados, renderização de modelo ou camada de cache é o gargalo.

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

Acelerar o TTFB com 103 Early Hints

O 103 Early Hints é um código de status HTTP que permite que o servidor envie cabeçalhos de resposta preliminares para o 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 de 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 informam ao navegador quais recursos fazer preload ou preconnect. O navegador age sobre essas dicas enquanto espera pela resposta 200 completa.

Isso efetivamente transforma o tempo de espera inativo 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 LCP e 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 de preload/preconnect encontrados em 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 HTTP/2 ou HTTP/3 push. O Apache suporta o 103 Early Hints por meio da diretiva H2EarlyHints. Confira nosso guia detalhado sobre como implementar o 103 Early Hints para obter instruções passo a passo.

Eliminar 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 chega à sua página, você pode usar a Speculation Rules para instruir um navegador a buscar (com a diretiva prefetch) ou mesmo renderizar totalmente (com a diretiva prerender) as páginas que o visitante tem maior probabilidade de visitar em seguida.

Como a Speculation Rules elimina o TTFB

Quando uma página é pré-renderizada (prerendered), o navegador carrega e renderiza a página completamente em uma guia 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. Os dados de RUM do CoreDash em corewebvitals.io confirmam que as navegações pré-renderizadas via Speculation Rules mostram um TTFB p75 de 0ms.

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

Sintaxe JSON da Speculation Rules

A Speculation Rules é definida 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 menus com um ímpeto "moderate" (acionado ao passar o mouse ou ao 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íficos:

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

O suporte dos navegadores à Speculation Rules está crescendo. O Chrome 121+ suporta toda a API, incluindo as regras de documentos. Para navegadores que ainda não suportam a Speculation Rules, você pode usar um script leve como o quicklink como fallback. Use nosso Speculation Rules Generator 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 maneiras. Ao investir em uma hospedagem melhor, geralmente é possível melhorar imediatamente o Time to First Byte sem alterar mais nada. Especialmente ao mudar de uma hospedagem compartilhada de baixo orçamento para servidores virtuais adequadamente configurados e gerenciados, o TTFB pode melhorar drasticamente.

DICA de Hospedagem: uma hospedagem melhor envolve processamento mais rápido, melhor velocidade de rede e mais memória de servidor, além de mais rápida. Hospedagem cara nem sempre é sinônimo de melhor hospedagem. Muitos upgrades em serviços de hospedagem compartilhada oferecem apenas mais armazenamento, e não mais poder de CPU.

Eu não recomendo mudar de hospedagem sem conhecer as causas raízes dos problemas de TTFB. Aconselho você a configurar o rastreamento de RUM e a adicionar cabeçalhos Server-Timing.

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

• Obter mais recursos (CPU + RAM): Especialmente quando leva muito tempo para o servidor gerar o HTML dinâmico.
• DNS Mais Rápido: Muitos provedores de hospedagem de baixo orçamento são notórios por seu desempenho de DNS ruim.
• Melhor configuração: Procure por cifras SSL mais rápidas, HTTP/3, compactação Brotli e acesso à configuração do servidor web (para desativar módulos desnecessários) para citar algumas.

Como melhorar o TTFB: acelerar a conexão inicial

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

Acelerar o DNS

DICA do PageSpeed: DNS, TCP e SSL costumam ser um problema maior quando você está usando um host barato ou quando você atende a um público global enquanto não usa uma CDN. Use o rastreamento de RUM para ver o seu TTFB global e divida o TTFB em 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, fornecerá a você um dos provedores de DNS mais rápidos do mundo gratuitamente.

Aumente o TTL do DNS. Outra maneira é aumentar o valor do Time to Live (TTL). 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 armazenam DNS em cache.

Acelerar o TCP

A "parte do TCP" do TTFB é a conexão inicial com o servidor web. Ao se 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 do TCP do TTFB. Em muitos casos, usar uma CDN acelerará a conexão TCP.

Acelerar o SSL/TLS

Depois que a conexão TCP for feita, o navegador e o servidor precisarão proteger a conexão por meio de criptografia. Você pode acelerar isso usando protocolos mais rápidos, mais novos e mais leves (cifras SSL) e por estar geograficamente mais perto do seu servidor web (já que a negociação TLS leva um bom número de idas e vindas). Usar uma CDN muitas vezes melhorará o tempo de conexão SSL, pois as CDNs geralmente são muito bem configuradas e têm vários servidores espalhados pelo mundo. O TLS 1.3 em particular é projetado para manter a negociação TLS a mais curta possível.

Como melhorar o TTFB: acelerar o lado do servidor

Cache de Página

De longe, a maneira mais eficiente de acelerar o Time to First Byte é servir o HTML do cache do servidor. Existem várias maneiras de implementar o cache de página inteira. A maneira mais eficaz é fazendo 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 de CMS que irão armazenar páginas inteiras em cache e muitos frameworks de SPA como Next.js têm sua própria implementação de cache de página inteira juntamente com diferentes estratégias de invalidação.

Se você quiser 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 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 de 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.

Otimizar o código do aplicativo

À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ê encontra outros problemas. É por isso que precisamos otimizar o código do aplicativo. A forma como isso é feito depende inteiramente do seu aplicativo. Baseia-se em reescrever e otimizar partes lentas do seu código.

Otimizar consultas de banco de dados

Na maioria das vezes, consultas de banco de dados ineficazes 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. Consulte MongoDB Performance Advisor e MySQL Slow Query Log para obter mais detalhes.

Reduzir a latência da rede interna

Uma prática ruim que eu encontro mais vezes do que gostaria é um atraso no Time to First Byte causado por lentidão na comunicação entre a aplicação web e o armazenamento de dados. Isso geralmente só acontece com sites grandes que terceirizaram o seu armazenamento de dados para APIs na nuvem.

Como melhorar o TTFB: acelerar 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 pode recuperar rapidamente os recursos armazenados 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. Este cabeçalho permite que você especifique por quanto tempo o navegador deve armazenar um recurso em cache.

Você pode considerar o cache completo do HTML da página no lado do cliente. Isso reduzirá drasticamente o TTFB, pois nenhuma solicitação do servidor é necessária. A desvantagem é que, uma vez que a página esteja no cache do navegador, quaisquer atualizações na versão ao vivo 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 em segundo plano no 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 retornar ao seu site, o navegador dele possa recuperar rapidamente os recursos armazenados em cache em vez de ter que baixá-los novamente.

Prefetching de Página

Se você não quiser usar a Speculation Rules API devido ao seu limitado suporte de navegadores, você pode usar um pequeno script chamado quicklink. Isso fará o prefetch de todos os links na janela de visualização 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: usar uma CDN

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

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 se 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.
• Tempo de conexão TCP e Handshake SSL: A maioria das CDNs é configurada extremamente bem e essas configurações, junto com a maior proximidade aos usuários finais, acelerarão o tempo de conexão e handshake.
• Resposta do servidor: As CDNs podem acelerar o tempo de resposta do servidor de algumas maneiras. A primeira é fazendo o cache da resposta do servidor na borda (cache de página inteira na borda), mas também oferecendo uma excelente compactação (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 regra geral, evite redirecionamentos tanto quanto possível. Redirecionamentos podem acontecer 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á aquele novo local.

Redirecionamentos de mesma origem. Redirecionamentos de mesma origem originam-se de links no 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. Há muitas ferramentas por aí que permitirão verificar todo o seu site em busca de redirecionamentos.

Redirecionamentos de origem cruzada. Redirecionamentos de origem cruzada originam-se de links em outros sites. Você tem muito pouco controle sobre eles.

Vários redirecionamentos. Vários redirecionamentos ou cadeias de redirecionamento ocorrem quando um único redirecionamento não redireciona 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. Novamente, use uma ferramenta para encontrar esses tipos de redirecionamentos e corrigi-los.

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

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

Existem várias maneiras 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 para garantir que nenhuma referência ao local anterior da página permaneça.
2. Lide com os redirecionamentos no nível do servidor.
3. Use URLs relativos: Ao criar links para páginas no seu próprio site, use URLs relativos em vez de URLs absolutos. Isso ajudará a evitar redirecionamentos desnecessários.
4. Use URLs canônicos: Se você tiver 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 evitar conteúdo duplicado e redirecionamentos desnecessários.
5. Use redirecionamentos 301: Se você precisar 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. Usar um redirecionamento 301 ajudará a evitar 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. Uma vez que o primeiro byte chega, o navegador precisa saber quais recursos priorizar. Leia nosso guia para priorização de recursos para aprender como as dicas fetchpriority, preload e preconnect trabalham juntas com um TTFB rápido para fornecer os carregamentos de página mais rápidos possíveis. Além disso, considere o self-hosting do seu Google Fonts para eliminar pesquisas de DNS de terceiros e tempos de conexão que são adicionados ao TTFB percebido pelos 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 de corewebvitals.io (hospedado na Europa) ilustram isso claramente:

Os usuários europeus perto do 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 à enorme distância física. Esses dados demonstram por que uma CDN com locais de borda globais é essencial para públicos internacionais.

O prerender do Speculation Rules oferece TTFB de 0ms

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

O TTFB em dispositivos móveis é 2,5x maior do que no desktop

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

Visitantes novos vs. recorrentes veem um TTFB semelhante

Neste site, os novos visitantes veem um TTFB p75 de 127ms, enquanto os visitantes recorrentes 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 recorrentes pode ser muito maior.

O TTFB global estagnou há 5 anos

De acordo com o Web Almanac de 2025, apenas 44% das páginas móveis alcançam uma pontuação "boa" de TTFB globalmente. Esse número mal mudou em relação aos 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% durante o mesmo período. Sites com um LCP ruim gastam uma média de 2,27 segundos apenas no TTFB, quase todo o limite de 2,5 segundos do LCP.

Guias Relacionados: Subpartes do TTFB

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

• <b>Corrigir e Identificar Problemas de TTFB</b>: Um guia de diagnóstico passo a passo para encontrar a causa raiz de um TTFB lento usando dados do DevTools, Server-Timing e RUM.
• <b>Reduzir a Duração da Espera</b>: Como minimizar o tempo de redirecionamento e os atrasos de processamento do servidor que são adicionados ao seu TTFB.
• <b>Reduzir a Duração do Cache</b>: Estratégias para cache no navegador, service workers e cache de voltar/avançar (bfcache) para eliminar o TTFB para visitantes recorrentes.
• <b>Minimizar 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 de recurso dns-prefetch.
• <b>Otimizar a Duração da Conexão (TCP + TLS)</b>: Reduzir o tempo de handshake TCP e TLS com HTTP/3, TLS 1.3, retomada de sessão e dicas de preconnect.