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 75º percentil. 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 decorreu em milissegundos entre o início da solicitação e o recebimento da primeira resposta (byte) de uma página web. O TTFB é, portanto, também referido como o tempo de espera. O TTFB é uma forma de medir a capacidade de resposta de um servidor web e o caminho da 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 as métricas de pintura.

TTFB não é um Core Web Vital

É importante afirmar isso claramente: o TTFB não é um dos três Core Web Vitals. Os Core Web Vitals consistem no 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 de 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 2025 Web Almanac, sites com LCP ruim gastam uma média de 2,27 segundos apenas no TTFB, o que quase esgota todo o limite 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 pelas 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 é perfeitamente possível passar nos Core Web Vitals enquanto falha na métrica 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 pagespeed 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 espera 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 carregamento instantâneo de páginas, 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 leva em conta 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 web. Mesmo que todos os bytes sejam baixados rapidamente, a página web ainda pode levar muito tempo para ser exibida se o navegador precisar processar muito JavaScript ou renderizar layouts complexos.

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

É recomendado 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 aproximado, 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

T-Mobile investiu pesadamente na redução do seu Time to First Byte como parte de uma iniciativa mais ampla de otimização de performance. Os resultados foram impressionantes: um aumento de 60% nas conversões de visita para pedido. Ao mudar para páginas renderizadas na borda (edge-rendered) e caching agressivo no lado do servidor, a T-Mobile reduziu drasticamente o tempo que os usuários passavam esperando pelo primeiro byte, o que cascateou em LCP mais rápido, FCP mais rápido e uma experiência de 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ócio.

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 chegue ao servidor que hospeda o site. O TTFB desta parte está amplamente além 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.

Dentro desta fase, 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) ocupam um pouco de tempo.

No Servidor: Processamento

Assim que a solicitação chega ao seu servidor, este precisa gerar o HTML. O tempo de processamento do servidor é o tempo que o servidor leva para processar a solicitação e gerar uma resposta. O TTFB desta parte é influenciado por:

• A complexidade do código da aplicação.
• O número e a eficiência das consultas ao banco de dados.
• O uso de caching no lado do servidor.
• O desempenho do hardware do servidor.

Do Servidor para o Navegador: A Resposta

Assim que o servidor gera a resposta, ele envia o primeiro byte de volta ao navegador do usuário. O tempo desta parte depende de:

• A largura de banda da conexão de rede do servidor.
• O congestionamento da rede entre o servidor e o usuário.
• A eficiência da transmissão de dados do servidor (por exemplo, compressão Brotli ou Gzip).

Como medir o Time to First Byte

Existem várias maneiras de medir o TTFB. As ferramentas mais comuns são Lighthouse, PageSpeed Insights e Chrome DevTools. Todas essas ferramentas usam dados de laboratório, o que significa que simulam uma visita à página sob condições controladas. Para entender o desempenho real de seus usuários, você deve usar ferramentas que coletam dados de campo.

Meça o TTFB usando os dados do Chrome User Experience Report (CrUX)

A melhor maneira de medir o TTFB real que seus usuários estão experimentando é usando o Chrome User Experience Report (CrUX). O CrUX coleta dados de performance de usuários reais do Chrome que optaram por compartilhar seu histórico de navegação. Você pode acessar os dados do CrUX através do PageSpeed Insights ou do Google Search Console.

Meça o TTFB usando dados de RUM

As ferramentas de Real User Monitoring (RUM), como o CoreDash, coletam dados de performance de cada visitante real do seu site em tempo real. Isso fornece uma visão muito mais granular do seu TTFB em diferentes dispositivos, redes e localizações geográficas.

Meça o TTFB usando o Chrome DevTools

Você pode medir o TTFB de qualquer carregamento de página diretamente no seu navegador. Abra o Chrome DevTools (F12 ou Ctrl+Shift+I), vá para a aba Network e recarregue a página. Clique no primeiro recurso (o documento HTML) e selecione a aba Timing. Você verá o TTFB listado como "Waiting (TTFB)".

Diagnosticando o TTFB com a Server-Timing API

Para entender o que está acontecendo dentro do seu servidor, você deve usar a Server-Timing API. Esta API permite que o seu servidor envie métricas de performance detalhadas (como tempo de consulta ao banco de dados, renderização de template ou tempo de resposta da API) em um cabeçalho HTTP. Essas métricas aparecem diretamente no Chrome DevTools e podem ser coletadas por ferramentas de RUM.

Como implementar o Server-Timing

O cabeçalho Server-Timing pode conter várias métricas separadas 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="Minha Descrição")

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 de 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 via cabeçalho Server-Timing aparecerá com seu nome, descrição e duração. Isso torna simples identificar se o seu banco de dados, a renderização do template ou a camada de caching é 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 monitoramento e alertas de longo prazo.

Acelere o TTFB com 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 que a resposta final esteja pronta. Enquanto o servidor ainda está processando a solicitaçã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 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 carregar antecipadamente (preload) ou aos quais se conectar (preconnect). O navegador age sobre essas dicas 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 LCP e FCP, dando ao navegador uma vantagem inicial na descoberta de recursos.

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

Muitos CDNs e servidores web agora suportam 103 Early Hints. Aqui está um exemplo usando o Cloudflare, que gera automaticamente 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 habilitando o push HTTP/2 ou HTTP/3. O Apache suporta o 103 Early Hints através da diretiva H2EarlyHints. Verifique nosso guia detalhado sobre a implementação de 103 Early Hints para instruções passo a passo.

Elimine o TTFB com a Speculation Rules API

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

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 em corewebvitals.io confirmam que as navegações pré-renderizadas via Speculation Rules mostram um p75 TTFB de 0ms.

O Prefetching é uma alternativa mais leve. Em vez de renderizar totalmente a página, o navegador apenas busca o documento HTML e o armazena em cache. Isso elimina a parte de rede do TTFB, mas ainda exige que o navegador analise 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" moderada (ativada ao passar o mouse ou ao pressionar):

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

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

Como o hosting afeta o Time to First Byte?

O hosting afeta o Time to First Byte de várias maneiras. Ao investir em um hosting melhor, geralmente é possível melhorar imediatamente o Time to First Byte sem mudar mais nada. Especialmente ao mudar de um hosting compartilhado de baixo custo para servidores virtuais configurados e gerenciados adequadamente, o TTFB pode melhorar drasticamente.

DICA de Hosting: um hosting melhor envolve processamento mais rápido, melhor velocidade de rede e mais memória de servidor e mais rápida. Hosting caro nem sempre significa hosting melhor. Muitos upgrades em serviços de hosting compartilhado apenas dão a você mais armazenamento, não mais poder de CPU.

Não recomendo mudar de hosting sem conhecer as causas raiz dos problemas de TTFB. Aconselho você a configurar o rastreamento de RUM e adicionar cabeçalhos de Server-Timing.

Ao fazer o upgrade do seu hosting, você deve geralmente procurar por 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 hosting de baixo orçamento são conhecidos por seu fraco desempenho de DNS.
• Melhor configuração: 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, DNS, TCP e SSL afetam todos os Time to First Bytes. Então, vamos começar por aí. Mesmo que otimizar esses três possa não render os maiores resultados, otimizá-los otimizará cada TTFB.

Acelere o DNS

DICA de PageSpeed: DNS, TCP e SSL são geralmente um problema maior quando você está usando um host barato ou quando serve um público global sem usar um CDN. Use o rastreamento de RUM para visualizar seu TTFB global e decompor 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 outros. Alguns provedores de DNS (gratuitos) são apenas mais lentos do que outros provedores de DNS (gratuitos). O Cloudflare, por exemplo, dará 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). O TTL é uma configuração que determina por quanto tempo a pesquisa pode ser armazenada em cache. Quanto maior o TTL, menos provável que o navegador precise realizar outra pesquisa de DNS. É importante notar que os ISPs também armazenam DNS em cache.

Acelere o TCP

A "parte TCP" do TTFB é a conexão inicial com o 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, usar um CDN acelerará a conexão TCP.

Acelere o SSL/TLS

Assim que a conexão TCP é feita, o navegador e o servidor precisarão garantir a segurança da conexão através de criptografia. Você pode acelerar isso usando protocolos mais rápidos, novos e leves (cifras SSL) e estando geograficamente mais próximo do seu servidor web (já que a negociação TLS leva várias viagens de ida e volta). Usar um CDN frequentemente melhorará o tempo de conexão SSL, já que os CDNs são frequentemente muito bem configurados e têm múltiplos servidores em todo o globo. O TLS 1.3, em particular, foi projetado para manter a negociação TLS o mais curta possível.

Como melhorar o TTFB: acelere o lado do servidor

Caching 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 caching de página inteira. A maneira mais eficaz é fazer isso diretamente no nível do servidor web com, por exemplo, o módulo de caching do NGINX ou usando o Varnish como um proxy de cache reverso.

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

Se você quiser implementar seu próprio caching, 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, escreva-a no cache e mostre a página como faria normalmente. Em qualquer próxima solicitação à página, o arquivo de cache existirá e você poderá servir a página diretamente do cache.

Caching parcial

Com o caching parcial, a ideia é armazenar em cache partes da página ou recursos (como chamadas de API, resultados de banco de dados) frequentemente usados, lentos ou caros para recuperação rápida. Isso eliminará gargalos ao gerar uma página. Se você estiver interessado nesses tipos de otimizações, deve pesquisar 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ê encontra outros problemas. É por isso que precisamos otimizar o código da aplicação. Como isso é feito depende inteiramente da sua aplicação. É baseado em reescrever e otimizar partes lentas do seu código.

Otimize as consultas ao banco de dados

Na maioria das vezes, consultas ao banco de dados ineficazes são a causa raiz de um Time to First Byte lento. Comece logando "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 (database tuning) para corrigir esses problemas. Veja o MongoDB Performance Advisor e o MySQL Slow Query Log para mais detalhes.

Reduza a latência interna da rede

Uma má prática que encontro 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 seu armazenamento de dados para APIs de nuvem.

Como melhorar o TTFB: acelere o lado do cliente

Caching no lado do cliente

O caching no lado do cliente envolve o navegador do usuário armazenar recursos que ele já acessou, como imagens e scripts. Assim, quando o usuário volta 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 caching no lado do cliente, você pode usar o cabeçalho HTTP Cache-Control. Este cabeçalho permite especificar por quanto tempo o navegador deve armazenar em cache um recurso específico.

Você poderia considerar o armazenamento em cache completo do HTML da página no lado do cliente. Isso reduzirá drasticamente o TTFB, já que nenhuma solicitação do servidor é necessária. A desvantagem é que, uma vez que a página está 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 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 armazenados em cache em vez de ter que baixá-los novamente.

Pré-busca de Página (Page Prefetching)

Se você não quiser usar a Speculation Rules API devido ao seu limitado suporte de navegador, você pode usar um pequeno script chamado quicklink. Isso fará a pré-busca 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 exige mais recursos do navegador, mas por enquanto ele superará a Speculation Rules API em termos de cobertura de navegador.

Como melhorar o TTFB: use um CDN

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

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

• Tempo de Redirecionamento: A maioria dos 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 dos CDNs oferece servidores DNS extremamente rápidos que provavelmente superarão seus servidores DNS atuais.
• Tempo de conexão TCP e SSL Handshake: A maioria dos CDNs é configurada extremamente bem e essas configurações, juntamente com a maior proximidade dos usuários finais, acelerarão o tempo de conexão e handshake.
• Resposta do servidor: Os CDNs podem acelerar o tempo de resposta do servidor de algumas maneiras. A primeira é armazenando em cache a resposta do servidor na borda (full page edge caching), mas também oferecendo excelente compressã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 o máximo possível. Redirecionamentos podem acontecer quando um recurso não está mais disponível em um local, mas mudou 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 (Same-origin redirects). Os redirecionamentos de mesma origem partem 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. Existem muitas ferramentas por aí que permitem verificar todo o seu site em busca de redirecionamentos.

Redirecionamentos de origem cruzada (Cross-origin redirects). Os redirecionamentos de origem cruzada partem de links em outros sites. Você tem muito pouco controle sobre eles.

Redirecionamentos múltiplos. Redirecionamentos múltiplos ou cadeias de redirecionamento ocorrem quando um único redirecionamento não redireciona para o local final do recurso. Esses tipos de redirecionamentos sobrecarregam mais 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 HTTP para HTTPS. Uma maneira 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 através 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. Este 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 mesmos:

1. Atualize seus links internos. Sempre que mudar a localização de uma página, atualize seus links internos para essa página para garantir que nenhuma referência à localização anterior da página permaneça.
2. Lide com os redirecionamentos no nível do servidor.
3. Use URLs relativas: Ao criar links para páginas no seu próprio site, use URLs relativas em vez de URLs absolutas. Isso ajudará a evitar redirecionamentos desnecessários.
4. Use URLs canônicas: Se você tiver várias páginas com conteúdo semelhante, use uma URL canônica 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ê 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. Usar um redirecionamento 301 ajudará a evitar redirecionamentos desnecessários.

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

Reduzir o TTFB é apenas parte da história 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 as dicas de fetchpriority, preload e preconnect trabalham juntas com um TTFB rápido para entregar os carregamentos de página mais rápidos possíveis. Além disso, considere auto-hospedar suas Google Fonts para eliminar as pesquisas de DNS de terceiros e os tempos de conexão que aumentam o TTFB percebido pelos seus usuários.

O que os dados de TTFB do mundo real mostram

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

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 de corewebvitals.io (hospedado na Europa) ilustram isso claramente:

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

Prerender das Speculation Rules entrega 0ms de TTFB

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

TTFB mobile é 2,5x o de desktop

No corewebvitals.io, usuários mobile experimentam um p75 TTFB de 316ms em comparação com 124ms no desktop. Esse gap de 2,5x é causado pela latência da rede móvel, não por diferenças de servidor. Apenas 88,5% dos carregamentos de página móveis atingem 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. recorrentes veem TTFB semelhante

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

TTFB global estagnou por 5 anos

De acordo com o 2025 Web Almanac, apenas 44% das páginas móveis atingem uma pontuação de TTFB "boa" globalmente. Este número mal mudou de 41% em 2021, tornando o TTFB a métrica de performance 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 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 suas próprias estratégias de otimização:

• <b>Identificar e Corrigir Problemas de TTFB</b>: Um guia de diagnóstico passo a passo para encontrar a causa raiz de um TTFB lento usando DevTools, Server-Timing e dados de RUM.
• <b>Reduzir a Waiting Duration</b>: Como minimizar o tempo de redirecionamento e os atrasos de processamento do servidor que aumentam seu TTFB.
• <b>Reduzir a Cache Duration</b>: Estratégias para caching do navegador, service workers e back/forward cache (bfcache) para eliminar o TTFB para visitantes recorrentes.
• <b>Minimizar a DNS Duration</b>: Como acelerar a resolução de DNS com provedores de DNS mais rápidos, aumento dos valores de TTL e dicas de recursos dns-prefetch.
• <b>Otimizar a Connection Duration (TCP + TLS)</b>: Reduzindo o tempo de TCP e TLS handshake com HTTP/3, TLS 1.3, retomada de sessão e dicas de preconnect.