Transloadit

O que é o tempo até o primeiro byte?

O tempo até o primeiro byte (TTFB) é o tempo decorrido entre o início de uma requisição ou navegação e a chegada do primeiro byte da resposta. Dependendo de quando a medição começa, ele pode incluir redirecionamento, DNS, estabelecimento da conexão e negociação TLS, além do processamento no servidor.

Como funciona o tempo até o primeiro byte

O TTFB marca o momento em que uma resposta começa a chegar, então tudo o que acontece antes desse momento entra no cálculo, e nada depois dele entra. Para uma navegação de página medida no navegador, o web.dev lista as fases somadas: tempo de redirecionamento, inicialização do service worker, consulta DNS, conexão e negociação TLS, e a requisição até o primeiro byte da resposta. Os navegadores expõem esse momento como responseStart nas APIs Navigation Timing e Resource Timing. Um acerto no cache da CDN elimina do total o percurso até o servidor de origem, e é por isso que a mesma URL pode apresentar valores muito diferentes em uma ausência no cache e em um acerto no cache. Quando uma CDN está no caminho, um cabeçalho de resposta Server-Timing pode detalhar ainda mais o número: o Amazon CloudFront, por exemplo, pode informar se a resposta correspondeu a um acerto ou a uma ausência no cache e, no caso de ausência, informar a latência do primeiro byte do servidor de origem separadamente da sua própria latência. Servidores e intermediários escolhem quais métricas de Server-Timing enviar, então o cabeçalho mostra apenas o que eles informam. Na entrega de mídia, o TTFB identifica o atraso antes do início da transferência de uma playlist, segmento, imagem ou resposta de API; ele não informa quanto tempo o download do corpo leva depois disso.

Informações essenciais

  1. Por que duas ferramentas informam TTFBs diferentes para a mesma requisição? Elas começam a contar o tempo em pontos diferentes. A biblioteca web-vitals mede uma navegação desde seu início, ou desde a ativação no caso de uma página pré-renderizada, até responseStart, o que inclui redirecionamentos, DNS, conexão e TLS. O Chrome DevTools usa o rótulo “Waiting (TTFB)” para uma fase mais restrita: ela vem depois das fases separadas de consulta DNS, conexão e envio da requisição, e abrange a latência de uma ida e volta mais o tempo que o servidor levou para preparar a resposta. A medição de time_starttransfer do curl começa no início da transferência e inclui resolução de nomes, estabelecimento da conexão e handshake TLS. Um log de CDN é ainda mais restrito: o campo time-to-first-byte do CloudFront é medido no servidor, do recebimento da requisição até a escrita do primeiro byte da resposta, portanto não inclui nenhum tempo de rede do cliente. Confira se as definições correspondem antes de comparar números ou definir uma meta.
  2. Existe um valor de referência? Para navegações de página, o web.dev oferece uma orientação aproximada: 0,8 segundos ou menos é bom, e mais de 1,8 segundos é ruim. O TTFB não é uma Core Web Vital, e o web.dev considera esses limites uma orientação aproximada porque uma página renderizada no servidor pode ter um TTFB maior e ainda exibir seu conteúdo antes de uma página renderizada no navegador. A orientação se aplica a requisições de navegação, ou seja, documentos HTML; o web.dev não define limites para imagens, segmentos de vídeo ou chamadas de API.
  3. É possível medir o TTFB em condições reais de uso para mídia servida por um hostname de CDN? Somente se a CDN permitir isso enviando um cabeçalho de resposta Timing-Allow-Origin que liste a origem da página ou o curinga *. Para um recurso de outra origem enviado sem esse cabeçalho, a API Resource Timing informa responseStart como 0, e faz o mesmo com os registros de tempo de DNS, conexão e requisição. responseStart também é 0 para um recurso recuperado instantaneamente de um cache, então exclua os zeros em vez de incluí-los na média. O mesmo cabeçalho controla se uma página pode ler métricas de Server-Timing de outra origem.
  4. Uma resposta 103 Early Hints conta como o primeiro byte? Nas APIs dos navegadores, sim: responseStart retorna o instante da primeira resposta provisória quando há uma, e o web.dev afirma que a resposta 103 conta como os primeiros bytes. Já finalResponseHeadersStart indica o início da resposta final. O Chrome passou a informar a resposta final como responseStart na versão 115 e reverteu essa mudança na versão 133, então os dados de TTFB do Chrome podem mudar entre essas versões para sites que enviam Early Hints. Enviar os cabeçalhos de resposta antecipadamente tem um efeito semelhante, então um TTFB menor após ativar qualquer um desses recursos não é, por si só, evidência de que o conteúdo principal chega mais cedo.

Quando o tempo até o primeiro byte importa

Compare o TTFB de uma ausência no cache da CDN com o de um acerto no cache para a mesma URL, mantendo as demais condições semelhantes, para ver quanta latência o caminho sem resultado em cache acrescenta ao caminho de entrega. Um TTFB baixo não garante uma resposta completa rápida, pois o tempo de download e o de renderização continuam separados.

Como a Transloadit ajuda com o tempo até o primeiro byte

No Smart CDN da Transloadit, uma ausência no cache exige um processamento que um acerto no cache dispensa. Quando há uma ausência no cache, a requisição importa o original do seu armazenamento e executa seu Template para produzir o resultado; quando há um acerto no cache, o resultado em cache é entregue pelo nó de borda sem executar nada. A página do produto Smart CDN informa separadamente os tempos das requisições com cache frio e aquecido e recomenda considerar o tempo de busca do arquivo de origem e de transformação quando o cache está frio.

A página do produto não informa se os tempos representam o tempo até o primeiro byte ou o tempo total de resposta, nem se algum byte da resposta é enviado antes do término do processamento quando há uma ausência no cache. Ela apresenta os tempos como medições datadas que variam conforme a carga de trabalho. Meça seu próprio Template comparando uma ausência no cache com um acerto no cache para a mesma URL. Uma primeira requisição e sua repetição não formam automaticamente esse par: a URL já pode estar em cache no nó de borda, e o Robot /file/serve orienta os navegadores a armazenar os resultados em cache por padrão, então uma requisição repetida de um navegador pode ser respondida localmente. A página do produto recomenda verificar os cabeçalhos de cache da resposta durante a depuração.

Explore os recursos de entrega da Transloadit

Fontes

Transforme conhecimento sobre mídia em um pipeline funcional

Conecte uploads, processamento, IA, armazenamento e entrega por meio de uma única API declarativa, com o stack de codificação, o ajuste de escala e as constantes mudanças de formatos gerenciados para você.

Experimente a Transloadit gratuitamente