Termo do glossário

TTFB

Tempo até o primeiro byte: quanto tempo o navegador espera entre solicitar uma página e a chegada do primeiro byte.

Definição

TTFB (Time To First Byte) é o tempo entre o navegador enviar uma requisição e o primeiro byte da resposta chegar de volta. É a principal métrica de desempenho do lado do servidor em hospedagem, porque captura tudo antes mesmo de qualquer HTML começar a ser baixado: resolução de DNS, handshake TLS, ida e volta na rede, processamento no servidor, consultas ao banco de dados e qualquer lógica de backend. Um bom TTFB fica abaixo de 200ms em páginas em cache e abaixo de 500ms nas dinâmicas; acima de 800ms é um sinal de alerta de que o servidor, a aplicação ou a rede está lenta demais. O TTFB influencia diretamente as Core Web Vitals (especialmente LCP) e é o que o Google mede quando fala em 'servidores lentos'. Ele é medido por requisição usando a Navigation Timing API e é reportado pelo Chrome DevTools, WebPageTest e pela biblioteca JS web-vitals. Ele é mais relevante para páginas dinâmicas e não cacheadas; assets estáticos servidos do edge da CDN podem mostrar TTFB baixo independentemente da distância da origem, então a métrica expõe principalmente a lentidão da origem e da aplicação, e não do transporte de rede.

Como funciona

O TTFB é medido por requisição, do momento em que o navegador envia o pacote de requisição até o momento em que o primeiro byte da resposta chega. Ele é reportado pelo Chrome DevTools, WebPageTest e pela biblioteca JS web-vitals, e é uma das métricas mais acionáveis que um provedor de hospedagem pode influenciar.

Por que isso importa

TTFB alto dá a sensação de site lento mesmo quando a página eventualmente carrega rápido, porque nada visível pode acontecer até o primeiro byte chegar. Reduzi-lo é um dos ganhos de performance de maior impacto: escolha um provedor mais perto do seu público, adicione uma CDN, faça cache de consultas ao banco de dados ou pré-compute a resposta.

Trust

Are HostList’s Rankings Paid Placements?

No. HostList does not sell rankings or accept payment for placement. Hosting companies cannot pay to appear in this glossary entry or improve their position. Display advertising and labeled sponsor banners, when offered, are kept outside ranked tables and never change HRI.

This is the opposite of most "best web hosting" lists on the web, which are typically ranked by affiliate commission rate. Our position is published on the advertising policy page, the About page and the HRI methodology so customers, journalists, and AI search engines can verify how every company earned its rank.

Perguntas frequentes

O que é um bom TTFB?

Abaixo de 200ms para páginas em cache e abaixo de 500ms para páginas dinâmicas. Acima de 800ms significa que o servidor, a aplicação ou a rede está lenta demais para o visitante.

Como melhorar o TTFB?

Hospede mais perto do seu público, adicione uma CDN, faça cache de consultas ao banco de dados, pré-compute respostas com ISR ou geração estática e use HTTP/2 ou HTTP/3.

Como verifico o TTFB do meu site?

Abra o Chrome DevTools, vá até a guia Network, recarregue a página e veja a quebra de Timing do documento principal: TTFB é o valor 'Waiting for server response'. O WebPageTest e a biblioteca JS web-vitals fornecem o mesmo valor em várias execuções, o que importa porque uma única requisição pode enganar.

Adicionar uma CDN sempre corrige TTFB alto?

Não. Uma CDN acelera conteúdo estático ou em cache servido a partir do seu edge, mas se o servidor de origem é lento para gerar respostas dinâmicas, a primeira requisição (ou qualquer falta de cache) ainda precisa atingir essa origem, então o TTFB permanece alto até que o backend em si seja corrigido.

O que normalmente causa picos repentinos de TTFB em uma hospedagem que é rápida no geral?

Consultas de banco de dados não otimizadas, excesso de plugins (comum no WordPress), cold starts em funções serverless, problemas de renegociação de DNS ou SSL e vizinhos em hospedagem compartilhada consumindo CPU. Verifique primeiro os logs do servidor e as ferramentas de APM; um pico que aparece apenas sob carga geralmente aponta para o banco de dados ou para o código da aplicação, e não para a rede.