Verificador de TTFB: teste o tempo até o primeiro byte

Verificador de TTFB: teste o tempo até o primeiro byte de um site

O TTFB (time to first byte) é o tempo desde o momento em que um navegador pede uma página até o momento em que chega o primeiro byte da resposta. Ele mostra a rapidez com que o servidor e a rede começam a responder, antes de aparecer uma única linha da página. Digite um endereço, escolha quantos testes fazer e receba o TTFB dividido em fases: redirecionamentos, DNS, conexão, TLS e espera pelo servidor. A ferramenta também é conhecida como teste de tempo até o primeiro byte e verificador do tempo de resposta do servidor.

Do que o TTFB é feito

• Redirecionamentos. Cada redirecionamento (por exemplo de http para https e depois para www) é uma requisição completa antes da verdadeira.
• DNS. Encontrar o endereço IP do nome do host.
• Conexão. A conexão TCP com o servidor. Depende da distância entre o visitante e o servidor: uma CDN tem servidores perto dos visitantes.
• TLS. O handshake do HTTPS, depois que a conexão é feita.
• Espera. O tempo do próprio servidor: a requisição viaja até lá, a aplicação e o banco de dados montam a página e o primeiro byte volta. O trabalho lento do servidor aparece aqui.

O que é um bom TTFB

O Google dá os limites no web.dev: um TTFB de 0,8 segundo ou menos é bom e acima de 1,8 segundo é ruim; a faixa entre os dois precisa melhorar. O TTFB não é um dos Core Web Vitals, mas o Google diz que os sites devem buscar 0,8 segundo ou menos, para que a maioria dos visitantes (o percentil 75) tenha um bom First Contentful Paint.

Por que a ferramenta faz vários testes

Um número só não é confiável: a rede varia de uma requisição para outra. O primeiro teste é marcado como frio: os caches do site e do DNS ainda podem estar vazios, então ele pode ser mais lento que os seguintes. Cada teste abre uma conexão nova, e a ferramenta mostra o teste mais rápido, o mais lento e a mediana, que é o número para comparar entre os testes.

Como reduzir o TTFB

A lista segue o guia do Google no web.dev, "Optimize Time to First Byte":

• Verifique primeiro a hospedagem. A hospedagem compartilhada costuma ser mais lenta.
• Use uma CDN. Os servidores dela ficam mais perto dos visitantes, e uma CDN geralmente traz HTTP/2, HTTP/3, TLS moderno e melhor compressão.
• Use conteúdo em cache sempre que possível, com os cabeçalhos Cache-Control.
• Evite redirecionamentos. Um redirecionamento acrescenta atraso à requisição. O HSTS (e a lista de HSTS preload) remove o redirecionamento de http para https.
• Envie a página em partes (streaming), use 103 Early Hints para os recursos importantes e adicione o cabeçalho Server-Timing para ver onde vai o tempo do servidor.

Como medir o TTFB por conta própria

Com o curl. Este comando mostra o tempo de cada fase. Note que o curl mostra a soma desde o início, então os números crescem de linha em linha, e time_starttransfer é o TTFB:

curl -o /dev/null -s -w 'DNS: %{time_namelookup}\nConnect: %{time_connect}\nTLS: %{time_appconnect}\nTTFB: %{time_starttransfer}\nTotal: %{time_total}\n' https://example.com/

No navegador. Abra as ferramentas de desenvolvedor do Chrome, a aba Network, clique na primeira requisição e abra Timing. A linha "Waiting (TTFB)" é o tempo que o navegador espera pelo primeiro byte; o Chrome diz que ele inclui um trajeto de ida e volta de latência e o tempo que o servidor levou para preparar a resposta. O Google também cita o Chrome User Experience Report (CrUX), a biblioteca web-vitals e o WebPageTest como ferramentas que medem o TTFB. Esta página mostra as fases uma a uma.

Como este verificador funciona

• A requisição é feita a partir do servidor do dieg.dev, de um só lugar. Os números de um visitante em outro país, ou de um site que só é rápido perto do servidor dele, podem ser bem diferentes.
• A ferramenta envia o próprio nome no User-Agent (DiegDevChecker) e apenas uma requisição GET simples: sem cookies, sem login, sem formulários. Só endereços públicos e as portas web usuais são verificados.
• O primeiro teste também lê o HTML (no máximo 2 MB) para mostrar o tamanho e a compressão. Os outros testes param assim que a resposta começa.
• O número de verificações é limitado por visitante e por site verificado, para que a ferramenta não possa ser usada para sobrecarregar um site. Um registro curto das verificações (o host verificado, o horário e um código do visitante, não o endereço) é guardado por 7 dias para responder a reclamações.

Ferramentas relacionadas

Para ver toda a cadeia de redirecionamentos e os cabeçalhos use o verificador de códigos de status HTTP e redirecionamentos, para verificar o certificado o DNS lookup (ele mostra também o certificado SSL) e, para ver qual versão do HTTP (HTTP/1.1 ou HTTP/2) o servidor usa e se ele anuncia HTTP/3, o mesmo verificador de códigos de status HTTP.