Guias

O TTFB, ou Time To First Byte, é o tempo entre o momento em que o seu navegador pede uma página a um servidor e o momento em que o primeiro byte da resposta regressa. É medido em milissegundos e abrange tudo o que tem de acontecer antes de o navegador poder sequer começar a ler a página: resolver o domínio, abrir a ligação e - a parte que normalmente domina - o servidor a fazer o seu trabalho e a enviar esse primeiro byte.

Importa porque o TTFB é o imposto pago em cada pedido antes de algo visível poder acontecer. Um navegador não consegue renderizar um único pixel enquanto os bytes não começam a chegar, por isso um TTFB lento atrasa a página inteira nessa mesma medida, por muito bem otimizados que estejam as suas imagens, o seu CSS e o seu JavaScript. É o piso por baixo da sua velocidade de carregamento.

O que o TTFB realmente mede

Nos bastidores, o TTFB é a soma de esperas mais pequenas: quaisquer redirecionamentos, a resolução DNS que transforma o seu domínio num endereço IP, a ligação TCP e o handshake TLS que a protege, o tempo que o pedido passa a viajar até ao servidor e, por fim, o tempo de processamento do servidor até o primeiro byte ser escrito de volta. Na maioria dos sites, esta última parte - quanto tempo o servidor demora a construir a resposta - é a maior e a mais fácil de corrigir.

Fundamentalmente, o TTFB é uma medição de back-end e de rede, não de front-end. Se o seu TTFB é elevado, o problema está no servidor, no alojamento ou no percurso de rede, não no seu código React ou Vue. É um diagnóstico útil: diz-lhe para olhar para o seu alojamento, para a sua cache e para a sua base de dados em vez do tamanho do seu bundle.

O que conta como um bom TTFB

A orientação da Google, publicada na web.dev, é que um bom TTFB está grosso modo abaixo dos 800 milissegundos para a maioria dos sites, sendo tudo o que ultrapassa 1.8 s considerado fraco. São limiares de campo - medidos em visitas reais - por isso já têm em conta redes e dispositivos reais em vez de um teste de laboratório em hardware rápido.

• Alojamento lento ou sobrecarregado - um servidor partilhado a esforçar-se sob o tráfego de outros sites
• Páginas dinâmicas sem cache regeneradas do zero em cada pedido
• Consultas pesadas à base de dados ou código back-end lento que inflacionam o tempo de processamento do servidor
• Sem CDN, pelo que cada visitante se liga a um único servidor de origem distante
• Cadeias de redirecionamento que acrescentam idas e voltas adicionais antes de a resposta real começar
• Handshakes TLS lentos ou um servidor situado longe da maior parte do seu público

O TTFB não é em si mesmo um dos três Core Web Vitals, mas alimenta diretamente o Largest Contentful Paint. O LCP nunca pode ser mais rápido do que o TTFB que o precede, porque o conteúdo principal não pode surgir enquanto a resposta não tiver começado. Melhorar um TTFB lento eleva muitas vezes o LCP gratuitamente, e é por isso que o trabalho de desempenho começa tantas vezes aqui.

Como reduzir o TTFB

A maior alavanca do lado do servidor é a cache. Servir uma página a partir de uma cache de página completa ou de uma cache de borda de um CDN evita o trabalho de a regenerar em cada pedido, transformando centenas de milissegundos de processamento num acesso quase instantâneo. Para além disso, um alojamento mais rápido ou menos congestionado, um código back-end mais leve e o aparo de consultas lentas à base de dados reduzem todos diretamente a parte de processamento.

Do lado da rede, um CDN encurta a distância física entre o seu servidor e cada visitante, de modo que o pedido e a resposta percorrem menos caminho. Um tratamento moderno das ligações - HTTP/2 ou HTTP/3, keep-alive e uma configuração TLS bem afinada - reduz a sobrecarga do handshake, e onde uma página pode ser pré-renderizada em ficheiros estáticos, o alojamento estático remove quase por completo o processamento do servidor do caminho crítico.

Em resumo

Em resumo, o TTFB é o imposto de resposta do servidor sobre cada página que serve, e define o teto de quão rápido o resto do seu site pode parecer. Um alojamento capaz, uma cache agressiva e um CDN são as três alavancas que mais o movem - e é por isso que corrigir o TTFB é normalmente o trabalho de desempenho com maior efeito de alavanca que pode fazer antes de tocar numa única linha de código front-end.