TTFB (Time to First Byte, ou “tempo até o primeiro byte”) é o tempo que o servidor leva para começar a responder a uma requisição — ou seja, quanto o navegador espera, depois de pedir uma página, até receber o primeiro byte de dados de volta. É medido em milissegundos e funciona como um termômetro da rapidez do seu servidor e da sua hospedagem. Um TTFB de até 800 ms é considerado bom; acima de 1800 ms, ruim.
O TTFB é uma das métricas de performance mais importantes — e mais ignoradas. Ele não aparece tanto quanto a “nota do PageSpeed”, mas está por trás dela: se o servidor demora a responder, todo o resto do carregamento atrasa. Neste guia você vai entender o que é o TTFB, do que ele é feito, qual o valor ideal, como medir e — o mais importante — como reduzir. Para o contexto geral de velocidade, veja também nosso guia de PageSpeed.
Conteúdo
O que é TTFB (Time to First Byte)?
O TTFB mede o tempo entre o momento em que o navegador inicia o pedido de uma página e o instante em que recebe o primeiro byte da resposta do servidor. É, em essência, o tempo de espera inicial: enquanto o TTFB não acontece, o navegador fica parado, sem nada para mostrar — a tela fica em branco.
É importante entender o que o TTFB não é: ele não é a velocidade total do site, nem o tempo até a página ficar pronta. É só o tempo de resposta inicial do servidor — a primeira etapa de tudo. Um TTFB baixo não garante um site rápido (o resto ainda precisa carregar e renderizar), mas um TTFB alto garante um site lento, porque tudo o que vem depois espera por ele.
Por medir a capacidade de resposta do servidor e do caminho de rede até ele, o TTFB é o melhor indicador de quão ágil é a sua infraestrutura — servidor, hospedagem e conexão.
Do que o TTFB é composto
O TTFB não é uma coisa só: ele soma várias etapas que acontecem entre o clique e o primeiro byte. Entender isso ajuda a saber onde atacar:
Em resumo, o TTFB inclui a resolução de DNS (encontrar o endereço do servidor), o estabelecimento da conexão (incluindo o handshake TLS/SSL no caso de HTTPS), o processamento no servidor (executar o código, consultar o banco de dados, montar a página) e o envio do primeiro byte de volta. Qualquer atraso em qualquer uma dessas etapas se soma ao TTFB total. Na maioria dos sites dinâmicos (como WordPress), a etapa de processamento no servidor é a que mais pesa.
Qual é o TTFB ideal?
A referência mais usada é a do Google (web.dev), medida no percentil 75 dos acessos reais:
Ou seja: mire em 800 ms ou menos. Na prática, servidores bem configurados entregam TTFB bem abaixo disso — valores abaixo de 200 ms são excelentes, e o PageSpeed Insights sinaliza problema quando o tempo de resposta passa de 600 ms. Quanto mais perto de zero, melhor: cada milissegundo de TTFB é um milissegundo a mais que todas as outras métricas de carregamento terão que esperar.
TTFB e Core Web Vitals: qual a relação?
Aqui está um ponto que confunde muita gente: o TTFB não é uma Core Web Vital. As Core Web Vitals são três (LCP, INP e CLS), e o TTFB não está entre elas. Mas ele é uma métrica de diagnóstico fundamental, porque precede e afeta as outras — especialmente o LCP e o FCP.
A lógica é simples: o LCP (tempo até o maior elemento aparecer) só pode começar a contar depois que o servidor responde. Se o TTFB é alto, o LCP já começa atrasado, por melhor que seja o resto. Segundo o Web Almanac 2025, sites com LCP ruim gastam em média 2,27 segundos só no TTFB — quase todo o orçamento de 2,5s do LCP é consumido antes mesmo de o navegador começar a desenhar a página. Por isso, reduzir o TTFB é uma das ações de maior impacto para melhorar as Core Web Vitals e o PageSpeed como um todo. Entenda as três métricas oficiais no nosso guia de Core Web Vitals.
Como medir o TTFB
Há várias formas de verificar o TTFB do seu site:
- Google PageSpeed Insights: mostra o TTFB tanto nos dados de campo (usuários reais) quanto no diagnóstico. É o ponto de partida.
- Chrome DevTools: abra o DevTools (F12), vá na aba Rede (Network), recarregue a página e clique na primeira requisição (o documento HTML). O TTFB aparece como “Waiting (TTFB)” no detalhamento de tempo.
- GTmetrix e WebPageTest: no gráfico de cascata (waterfall), o TTFB aparece como o tempo de “espera” (Waiting/TTFB) da primeira requisição. Veja como usar no nosso tutorial de GTmetrix.
Uma observação importante ao medir: como o TTFB inclui a latência de rede, testar do seu próprio computador reflete também a sua conexão e distância até o servidor. Para um resultado mais justo, use ferramentas que testam de servidores em locais conhecidos, e teste sempre a partir da mesma referência.
O que causa um TTFB alto
Se o seu TTFB está alto, a causa quase sempre está em uma destas frentes:
- Hospedagem lenta ou sobrecarregada: o motivo mais comum. Em hospedagem compartilhada barata, centenas de sites dividem o mesmo servidor, disputando CPU e memória — e o tempo de resposta dispara.
- Falta de cache: sem cache, o servidor reprocessa a página inteira a cada visita (executa o PHP, consulta o banco) em vez de entregar uma versão pronta.
- Versão antiga do PHP: versões mais novas do PHP são significativamente mais rápidas. Rodar uma versão desatualizada penaliza o TTFB.
- Banco de dados lento: consultas pesadas ou mal otimizadas atrasam a montagem da página.
- Datacenter distante do público: se o servidor está em outro continente, a latência de rede sozinha já adiciona centenas de milissegundos.
- Excesso de plugins e código: quanto mais código o servidor precisa processar a cada requisição, maior o tempo até o primeiro byte.
- Redirecionamentos em cadeia: cada redirecionamento adiciona uma ida e volta ao servidor antes da resposta final.
Como reduzir o TTFB (na prática)
Atacando as causas acima, na ordem de maior impacto:
Use uma hospedagem rápida. É a base de tudo — e a alavanca mais subestimada. Um servidor com bom hardware (SSD/NVMe), recursos adequados e que não esteja superlotado responde muito mais rápido. Se o seu TTFB está alto e o site é simples, o problema provavelmente é a hospedagem.
Ative o cache. Cache de página no servidor (e plugins como WP Rocket ou LiteSpeed Cache no WordPress) faz o servidor entregar uma versão pronta da página, sem reprocessar tudo a cada acesso. É, muitas vezes, a redução mais drástica de TTFB que você consegue. Entenda melhor em nosso guia sobre o que é cache.
Use um CDN. Um CDN serve o conteúdo a partir de servidores próximos do visitante, reduzindo a latência de rede — parte importante do TTFB, sobretudo para público distante do seu datacenter.
Atualize o PHP. Use sempre a versão estável mais recente suportada pelo seu site. O ganho de desempenho entre versões antigas e novas do PHP é grande.
Otimize o banco de dados. Limpe dados desnecessários, otimize consultas e mantenha o banco enxuto, para o servidor montar a página mais rápido.
Adote protocolos modernos. O HTTP/3 reduz a latência de conexão em relação às versões anteriores, ajudando a entregar o primeiro byte mais cedo.
Reduza redirecionamentos. Elimine cadeias de redirecionamento desnecessárias, que adicionam idas e voltas antes da resposta.
O papel da hospedagem (a causa nº 1)
Vale insistir neste ponto, porque é o que mais determina o TTFB: a hospedagem. Você pode otimizar cache, banco e código ao máximo, mas o TTFB tem um piso definido pelo servidor — o hardware, a quantidade de sites dividindo a máquina, a tecnologia de cache no servidor, a versão do PHP e a localização do datacenter. Um servidor lento ou lotado cria um teto de TTFB que nenhuma otimização de front-end ultrapassa.
Por isso, escolher uma hospedagem rápida, com infraestrutura adequada e servidores próximos do seu público (no Brasil, para público brasileiro), é a decisão de maior impacto sobre o TTFB. É a diferença entre um site que tenta ser rápido e um que é rápido desde o primeiro byte.
Perguntas frequentes sobre TTFB
A hospedagem da Homehost tem servidores rápidos, SSD/NVMe, cache, HTTP/3 e infraestrutura no Brasil — o melhor TTFB para fazer suas otimizações renderem de verdade.
Conheça a hospedagem HomehostConclusão
O TTFB é o ponto de partida da velocidade do seu site: o tempo que o servidor leva para começar a responder. Ele não é uma Core Web Vital, mas afeta diretamente o LCP e o FCP — e, por consequência, o seu PageSpeed e o seu ranqueamento. Mire em 800 ms ou menos (idealmente bem abaixo), meça com PageSpeed Insights, DevTools ou GTmetrix, e ataque as causas: cache, CDN, PHP atualizado, banco otimizado e protocolos modernos. Mas lembre-se da base de tudo — por trás de cada milissegundo de TTFB está o servidor. Uma hospedagem rápida é o alicerce que faz todas as outras otimizações renderem de verdade.
