TTFB vs tempo de resposta vs latência: o que cada um mede

O que cada termo significa

A latência de rede, muitas vezes reportada como tempo de ida e volta, é o tempo que um pacote passa viajando até o servidor e voltando, sem nenhum trabalho de aplicação no meio. É determinada pela distância física, o número de saltos e a qualidade da rota. Nada que você faça no seu código muda isso.

O tempo até o primeiro byte (TTFB) é medido a partir do momento em que o cliente inicia a requisição até o primeiro byte da resposta chegar até ele. Esse trecho contém a consulta DNS, a conexão TCP, o handshake TLS, o tempo que a requisição passa em trânsito, o que quer que o servidor faça para produzir uma resposta, e a viagem de volta. O TTFB é, portanto, sempre maior do que uma ida e volta, geralmente várias vezes maior.

Tempo de resposta é o mais impreciso dos três. A maioria das ferramentas de monitoramento o usa para o tempo total de conclusão da requisição, do primeiro pacote ao último byte do corpo. Algumas ferramentas o usam como sinônimo de TTFB. Antes de comparar dois números rotulados "tempo de resposta", verifique em que ponto cada ferramenta parou o relógio.

Como cada um é medido

A latência vem de um eco ICMP, que é o que o ping envia, ou da medição do handshake TCP quando o ICMP está bloqueado. O TTFB e o tempo total vêm do próprio cliente HTTP. Uma chamada do curl imprime todos os limites:

curl -sS -o /dev/null -w 'dns=%{time_namelookup} connect=%{time_connect} tls=%{time_appconnect} ttfb=%{time_starttransfer} total=%{time_total}\n' https://example.com/

Cada valor é cumulativo a partir do início da requisição, então você os lê como limites, não como durações. Subtraia o anterior para obter a duração de uma etapa.

Qual número a sua ferramenta está mostrando

Toda ferramenta reporta uma fatia diferente da mesma requisição, que é o motivo usual de duas medições de um site discordarem:

• ping reporta só a latência de ida e volta, sem nenhum trabalho do servidor incluído
• curl -w reporta todo limite listado acima, o que o torna a referência quando os números discordam
• As ferramentas de desenvolvedor do navegador mostram o TTFB como a etapa de espera de uma requisição, separada da etapa de download abaixo dela
• O Lighthouse e o PageSpeed reportam tempo de resposta do servidor, que é o TTFB para a requisição do documento
• Os monitores de uptime reportam um tempo de resposta cuja definição varia por produto, e que inclui o estabelecimento de conexão a partir de onde quer que a verificação tenha rodado
• O monitoramento de usuário real reporta o TTFB de campo, agregado entre visitantes reais em redes reais

Como é um número bom

A latência é limitada pela geografia. Abaixo de 30 ms é normal dentro de uma região metropolitana, 50 a 100 ms através de um continente, e 150 a 250 ms entre continentes. Uma rota que mede bem acima da distância sugere uma rota ruim, não um servidor lento.

Para o TTFB, o web.dev trata 800 ms ou menos como bom e qualquer coisa acima de 1,8 segundos como ruim, enquanto a auditoria de tempo de resposta do servidor do Lighthouse começa a falhar acima de 600 ms. Mire abaixo de 600 ms para a requisição do documento e trate 200 ms como o alvo para qualquer coisa em cache ou servida de forma estática.

O tempo de resposta total depende do tamanho do que você está enviando, então não há um número universal. Meça a sua própria linha de base em um dia normal e trate a mudança em relação a ela como o sinal, não o número absoluto.

Lendo as lacunas

Os números individuais importam menos do que a distância entre eles, porque cada lacuna aponta para um subsistema diferente:

• TTFB menos a latência de ida e volta é aproximadamente quanto tempo o servidor passou pensando. Se essa for a parte maior, o problema é código de aplicação, uma consulta lenta ou um cache frio
• Conexão menos consulta DNS é uma ida e volta para o handshake TCP. Se for muito maior do que a sua latência medida, o caminho de rede está congestionado ou mal roteado
• TLS menos conexão é o custo do handshake, tipicamente uma ou duas idas e voltas extras, e um valor grande aponta para problemas de cadeia de certificado ou retomada de sessão
• Total menos TTFB é tempo de transferência. Se isso dominar, a resposta é grande demais ou a conexão é lenta demais, e nenhum ajuste de servidor vai ajudar
• A consulta DNS sozinha deveria ser de alguns milissegundos uma vez em cache. Uma consulta consistentemente lenta é um problema de resolvedor ou de servidor de nomes autoritativo, não de servidor web

A mesma leitura funciona ao contrário quando só uma localidade está lenta. Um tempo de pensamento do servidor igual em todo lugar, com a diferença vivendo inteiramente na latência e na transferência, significa que o servidor está bem e a rota não está. Rode a verificação a partir de vários lugares antes de mexer na aplicação.

Medindo tudo em um só lugar

Para ver esses números de uma página sem montá-los na mão, rode o teste de velocidade de página, que carrega a página a partir de uma localidade externa e divide o carregamento nas suas etapas. O guia de tempo de resposta do servidor cobre a mesma medição pela linha de comando. Uma única execução só conta sobre aquele momento, então, se o número importa, coloque uma verificação agendada nele: a HostTracker mede o tempo de resposta em toda verificação a partir de mais de 300 pontos de verificação em 158 cidades, o que transforma uma leitura em uma linha de base contra a qual você consegue identificar uma regressão. Mais definições estão na seção de conceitos de monitoramento.