O que é o Time To First Byte (TTFB) e como melhorá-lo

O que é o Time to First Byte

O time-to-first byte (TTFB) indica quanto tempo decorreu em milissegundos entre o início da solicitação e o recebimento da primeira resposta (byte) de uma página web. O TTFB é, portanto, também referido como o tempo de espera. O TTFB é uma forma de medir algumas partes da velocidade de uma página web. O TTFB é uma métrica fundamental, o que significa que o tempo adicionado ao TTFB também será adicionado ao Largest Contentful Paint e ao First Contentful Paint.

Por que o Time to First Byte é importante

O Time to First Byte não é um Core Web Vital e é muito possível passar nos Core Web Vitals enquanto falha na métrica TTFB. Isso não significa que o TTFB não seja importante. O TTFB é uma métrica extremamente importante para otimizar e corrigir o TTFB vai melhorar significativamente a velocidade da página & a experiência da página!

O impacto do TTFB para os visitantes

O time to first byte precede todas as outras métricas de pintura. Enquanto o navegador está aguardando o Time to First byte, o navegador não pode fazer nada e vai apenas mostrar uma tela em branco! Isso significa que qualquer aumento no time to first byte resultará em tempo extra de 'tela em branco' e qualquer diminuição no time to first byte se traduzirá em menos tempo de 'tela em branco'.

Para obter aquela 'sensação de carregamento instantâneo de páginas', o time to first byte precisa ser o mais rápido possível!

Por que o TTFB não é um Core Web Vital? O TTLB não leva em conta a renderização: Um TTLB baixo não necessariamente significa uma boa experiência do usuário porque não considera o tempo que o navegador leva para renderizar a página web. Mesmo que todos os bytes sejam baixados rapidamente, a página web ainda pode levar muito tempo para ser exibida se o navegador precisar processar muito JavaScript ou renderizar layouts complexos.

O que é uma boa pontuação de TTFB?

É recomendado que seu servidor responda às solicitações de navegação rápido o suficiente para que o 75º percentil dos usuários experiencie um FCP dentro do limite "bom". Como guia geral, a maioria dos sites deve buscar ter um TTFB de 0,8 segundos ou menos.

• um TTFB abaixo de 800 milissegundos é considerado bom.
• um TTFB entre 800 e 1800 milissegundos precisa de melhoria
  
• um TTFB acima de 1800 milissegundos é considerado ruim e deve ser melhorado imediatamente

O TTFB da solicitação à resposta

Do navegador ao servidor: A solicitação

O tempo de solicitação do navegador é o tempo decorrido desde o momento em que o navegador de um usuário envia uma solicitação HTTP até que essa solicitação chegue ao servidor que hospeda o site. O TTFB desta parte está em grande parte além do controle direto do site e depende fortemente de

• A velocidade de internet do usuário.
• A qualidade da infraestrutura de rede.
• A distância física entre o usuário e o servidor.○

Dentro desta etapa,  a consulta DNS, o tempo de inicialização do navegador, as consultas ao cache do navegador e a negociação da conexão com o servidor (TCP & TSL) consomem um pouco de tempo.

No servidor: Processando e preparando a resposta

Uma vez que o servidor recebe a solicitação, o tempo está correndo enquanto trabalha para gerar uma resposta. Esta etapa é onde a maioria dos desenvolvedores tende a focar e onde  os esforços de otimização podem ter o impacto mais significativo. Fatores a considerar incluem:

• Capacidades do servidor: Hardware poderoso (CPU, RAM), software eficiente (servidor web, banco de dados) e configurações otimizadas são todos importantes.
  
• Duração do banco de dados: Se a solicitação requer buscar dados de um banco de dados, consultas lentas podem ser um grande gargalo.
• Otimização de código: Código do lado do servidor mal escrito (por exemplo, scripts ineficientes) pode levar a longos tempos de processamento.
• Estratégias de cache: Cache eficaz (como cache do lado do servidor ou uso de uma Content Delivery Network - CDN) pode reduzir drasticamente a carga de processamento para solicitações repetidas.

De volta ao navegador: Entregando o primeiro byte

Após o processamento, o servidor envia a resposta, começando com o primeiro byte, de volta ao navegador do usuário. 

• Similar à primeira etapa, as condições de rede e a distância também desempenham um papel aqui. 
• CDN's são particularmente benéficos nesta etapa, pois armazenam conteúdo em cache mais perto dos usuários, minimizando o tempo de viagem.
  
• Redirecionamentos são servidos neste ponto, o que faz o processo se repetir com um atraso extra.

Etapas técnicas do Time To First Byte

Similar ao 'caminho de solicitação à resposta' no seu navegador, o Time To First Byte de solicitações de navegação pode ser medido com a Navigation Timing API e dividido em 5 sub-partes.

1. Tempo de redirecionamento: quando um recurso foi movido para um novo local, o tempo de redirecionamento é adicionado ao TTFB do recurso.
2. Tempo de Worker & Cache: antes de um recurso ser buscado na internet, o navegador primeiro tentará procurar no seu próprio cache ou via um worker (se um worker tiver sido configurado)
3. Tempo de consulta DNS: Em seguida, o navegador pode precisar realizar uma consulta DNS para traduzir o nome de domínio (www.example.com) em um endereço IP
4. Tempo de conexão TCP: Então o navegador se conectará ao servidor e realizará algumas verificações
5. Handshake SSL: Então o navegador e o servidor criptografarão sua comunicação
6. Resposta do servidor: Finalmente, o servidor precisa enviar o HTML. Pode ser necessário gerar o HTML primeiro.

Como medir o Time To First Byte TTFB

Dica de PageSpeed: cada recurso tem seu próprio time to first byte. Neste contexto, porém, estamos falando sobre o time to first byte da página principal!

O Time to First Byte pode flutuar significativamente entre diferentes usuários com diferentes dispositivos e de diferentes localizações. É por isso que medir o time to first byte do seu computador desktop provavelmente não é uma boa ideia. Usar ferramentas como pingdom ou GTMetrix não é confiável pela mesma razão.

A melhor forma de medir o Time To First Byte é coletar dados de Real User Metrics (RUM) dos seus visitantes. Você pode fazer isso por conta própria com este código ou usar uma ferramenta RUM como CoreDash

Medir o TTFB com ferramentas sintéticas

Medir o TTFB com rastreamento RUM

Medir o TTFB com dados CrUX

CrUX (Chrome User Experience Report) é um conjunto de dados publicamente disponível do Google que contém dados de desempenho do mundo real para sites. O Google usa o conjunto de dados CrUX para determinar se você está ou não passando nos Core Web Vitals.

O conjunto de dados CrUX pode ser acessado através de ferramentas como PageSpeed Insights, a API CrUX, Looker Studio ou Google BigQuery. Use qualquer uma dessas ferramentas para obter o TTFB do seu site.

Medir o TTFB com JavaScript

Para medir o Time to First Byte (TTFB) com JavaScript, você pode usar a Navigation Timing API.  Você pode criar um PerformanceObserver que escuta uma entrada de navegação e registra a propriedade responseStart no console. A propriedade responseStart representa o timestamp de quando o primeiro byte da resposta foi recebido. A web-vitals JavaScript library  fornece uma forma mais concisa de medir o TTFB no navegador usando a função onTTFB.

O código abaixo pode ser usado para medir o Time To First Byte (TTFB)

const formatTime = (time) => {

//round by 2 decimals, use Math.round() for integer
return Math.round(time * 100) / 100;
};

new PerformanceObserver((entryList) => {
const [pageNav] = entryList.getEntriesByType('navigation');

// timing start times are relative
const activationStart = pageNav.activationStart || 0;
const workerStart = Math.max(pageNav.workerStart - activationStart, activationStart);
const dnsStart = Math.max(pageNav.domainLookupStart - activationStart, workerStart);
const tcpStart = Math.max(pageNav.connectStart - activationStart, dnsStart);
const sslStart = Math.max(pageNav.secureConnectionStart - activationStart, tcpStart);
const requestStart = Math.max(pageNav.requestStart - activationStart, sslStart);
const responseStart = Math.max(pageNav.responseStart - activationStart, requestStart);

// attribution based on https://www.w3.org/TR/navigation-timing-2/#processing-model
// use associative array to log the results more readable
let attributionArray = [];
attributionArray['Redirect Time'] = { 'time in ms': formatTime(workerStart - activationStart) };
attributionArray['Worker and Cache Time'] = { 'time in ms': formatTime(dnsStart - workerStart) };
attributionArray['DNS Time'] = { 'time in ms': formatTime(tcpStart - dnsStart) };
attributionArray['TCP Time'] = { 'time in ms': formatTime(sslStart - tcpStart) };
attributionArray['SSL Time'] = { 'time in ms': formatTime(requestStart - sslStart) };
attributionArray['Request Time'] = { 'time in ms': formatTime(responseStart - requestStart) };
attributionArray['Total TTFB'] = { 'time in ms': formatTime(responseStart - activationStart) };

// log the results
console.log('%cTime to First Byte (' + formatTime(responseStart - activationStart) + 'ms)', 'color: blue; font-weight: bold;');
console.table(attributionArray);

console.log('%cOrigininal navigation entry', 'color: blue; font-weight: bold;');
console.log(pageNav);

}).observe({
type: 'navigation',
buffered: true
});

Encontrar gargalos com Server Timing

Server Timings fornecem uma forma de enviar métricas de desempenho do servidor backend para o navegador. Ao utilizar Server Timings, os desenvolvedores podem medir e analisar eficazmente os componentes do lado do servidor que contribuem para o TTFB, ajudando a identificar áreas para otimização e melhorando o desempenho geral do site.

O cabeçalho Server-Timing pode ter tempos para múltiplas métricas separadas por vírgulas:

Um nome curto para a métrica (como database e processing)
Uma duração em milissegundos (expressa como dur=123)
Uma descrição (expressa como desc="My Description")

Server-Timing: database;dur=123, processing;dur=234

Um navegador agora pode ler o cabeçalho server timings. Esses cabeçalhos server timings podem ser enviados para sua ferramenta de RUM favorita como CoreDash

Como a hospedagem afeta o Time to First Byte?

A hospedagem afeta o time to first byte de múltiplas formas. Ao investir em uma melhor hospedagem, geralmente é possível melhorar imediatamente o time to First byte sem alterar mais nada. Especialmente ao mudar de hospedagem compartilhada de baixo custo para servidores virtuais devidamente configurados e gerenciados, o TTFB pode melhorar drasticamente.

Dica de hospedagem: uma melhor hospedagem envolve processamento mais rápido, melhor velocidade de rede e mais memória de servidor e mais rápida. Hospedagem cara nem sempre é igual a melhor hospedagem! Muitas atualizações em serviços de hospedagem compartilhada apenas dão mais armazenamento, não mais poder de CPU

Eu não recomendo trocar de hospedagem sem conhecer as causas raiz dos problemas de TTFB. Aconselho você a configurar rastreamento RUM & adicionar cabeçalhos server timing.

Quando você atualizar sua hospedagem, geralmente deve procurar pelo menos 1 destas 3 melhorias:

• Obter mais recursos (CPU + RAM): Especialmente quando o servidor demora muito para gerar o HTML dinâmico.
• DNS mais rápido: Muitos provedores de hospedagem de baixo custo são notórios pelo seu fraco desempenho de DNS
  
• Melhor configuração: Procure por Ciphers SSL mais rápidos, HTTP/3, compressão Brotli, acesso à configuração do servidor web (para desativar módulos desnecessários), para citar alguns.
  

Como melhorar o TTFB - Acelerar a conexão inicial

Um Time to First Byte alto pode ter múltiplas causas. No entanto, DNS, TCP e SSL afetam todos os time to first bytes. Então vamos começar por aí. Mesmo que otimizar esses 3 possa não gerar os maiores resultados, otimizá-los otimizará cada TTFB!

Acelerar o DNS

Dica de PageSpeed: DNS, TCP & SSL geralmente são um problema maior quando você está usando um host barato ou quando serve um público global sem usar um CDN. Use rastreamento RUM para visualizar seu TTFB global e decompor o TTFB em suas sub-partes

Use um provedor de DNS rápido. Nem todos os provedores de DNS são tão rápidos quanto outros. Alguns provedores de DNS (gratuitos) são simplesmente mais lentos que outros provedores de DNS (gratuitos). O CloudFlare, por exemplo, oferece um dos provedores de DNS mais rápidos do mundo gratuitamente!

Aumente o TTL do DNS. Outra forma é aumentar o valor do Time to Live (TTL). TTL é uma configuração que determina por quanto tempo a consulta pode ser armazenada em cache. Quanto maior o TTL, menos provável que o navegador precise realizar outra consulta DNS. É importante notar que os ISPs também armazenam DNS em cache.

Acelerar o TCP

A 'parte TCP' do TTFB é a conexão inicial com o servidor web. Ao conectar, o navegador e o servidor compartilham informações sobre como as informações serão trocadas. Você pode acelerar o TCP conectando-se a um servidor que está geograficamente próximo à sua localização e garantindo que o servidor tenha recursos livres suficientes. Às vezes, mudar para um servidor leve como o NGINX pode acelerar a parte TCP do TTFB. Em muitos casos, usar um CDN acelerará a conexão TCP!

Acelerar o SSL/TSL

Uma vez que a conexão TCP foi feita, o navegador e o servidor precisarão proteger sua conexão através de criptografia. Você pode acelerar isso usando protocolos mais rápidos, novos e leves (SSL Ciphers) e estando geograficamente mais próximo do seu servidor web (já que a negociação TSL requer várias viagens de ida e volta). Usar um CDN frequentemente melhora o tempo de conexão SSL, pois eles são geralmente muito bem configurados e possuem múltiplos servidores ao redor do globo. O TLS 1.3, em particular, é projetado para manter a negociação TLS o mais curta possível.

Como melhorar o TTFB - Acelerar o lado do servidor

Cache de página

De longe, a forma mais eficiente de acelerar o time to first byte é servir o HTML do cache do servidor. Existem várias formas de implementar cache de página completa. A forma mais eficaz é fazê-lo diretamente no nível do servidor web, com por exemplo o módulo de cache do NGINX ou usando o Varnish como proxy de cache reverso.

Também existem muitos plugins para diferentes sistemas CMS que armazenarão páginas completas em cache e muitos frameworks SPA como o NextJS têm sua própria implementação de cache de página completa junto com diferentes estratégias de invalidação.

Se você deseja implementar seu próprio cache, a ideia básica é super simples. Quando um cliente solicita uma página, verifique se ela existe na pasta de cache. Se não existir, crie a página, escreva-a no cache e mostre a página como você normalmente faria. Em qualquer próxima solicitação à página, o arquivo de cache existirá e você pode servir a página diretamente do cache.

Cache parcial

Com cache parcial, a ideia é armazenar em cache partes frequentemente usadas, lentas ou caras da página ou recursos (como chamadas de API, resultados de banco de dados) para recuperação rápida. Isso eliminará gargalos ao gerar uma página. Se você está interessado nestes tipos de otimizações (você deveria estar interessado!!) procure estes conceitos: Memory Cache, Object Cache, Database Cache, Object-Relational Mapping (ORM) Cache, Content Fragment Cache e Opcode Cache.

Otimizar o código da aplicação

Às vezes a página não pode ser servida do cache (parcial) porque o arquivo de cache não existe, grandes partes das páginas são dinâmicas ou porque você encontra outros problemas. É por isso que precisamos otimizar o código da aplicação. Como isso é feito depende inteiramente da sua aplicação. É baseado em reescrever e otimizar partes lentas do seu código.

Otimizar consultas ao banco de dados

Na maioria das vezes, consultas ineficazes ao banco de dados são a causa raiz de um Time to First Byte lento. Comece registrando 'consultas lentas' e 'consultas que não usam índices' em disco. Analise-as, adicione índices ou peça a um especialista para realizar a otimização do banco de dados para corrigir esses problemas. Veja https://www.mongodb.com/docs/atlas/performance-advisor/ e https://dev.mysql.com/doc/refman/8.0/en/slow-query-log.html

Reduzir a latência de rede interna

Uma má prática que encontro mais vezes do que gostaria é um atraso no time to first byte causado por lentidão na comunicação entre a aplicação web e o armazenamento de dados. Isso geralmente só acontece com sites grandes que terceirizaram seu armazenamento de dados para APIs na nuvem.

Como melhorar o TTFB - acelerar o lado do cliente

Cache do lado do cliente

O cache do lado do cliente envolve o navegador do usuário armazenar recursos que já foram acessados, como imagens e scripts. Assim, quando o usuário volta ao seu site, o navegador pode recuperar rapidamente os recursos em cache em vez de ter que baixá-los novamente. Isso pode reduzir significativamente o número de solicitações feitas ao servidor, o que por sua vez pode reduzir o TTFB.

Para implementar o cache do lado do cliente, você pode usar o cabeçalho HTTP Cache-Control. Este cabeçalho permite que você especifique por quanto tempo o navegador deve armazenar em cache um recurso específico.

Você poderia considerar armazenar completamente em cache o HTML da página no lado do cliente. Isso reduzirá dramaticamente o TTFB já que não precisamos mais de uma solicitação. A desvantagem é que uma vez que a página está no cache do navegador, quaisquer atualizações na versão ao vivo da página não serão vistas pelo usuário até que o cache da página expire.

Service Workers

Service workers são scripts que rodam em segundo plano no navegador do usuário e podem interceptar solicitações de rede feitas pelo navegador. Isso significa que service workers podem armazenar em cache recursos como HTML, imagens, scripts e folhas de estilo, para que quando o usuário voltar ao seu site, o navegador possa recuperar rapidamente os recursos em cache em vez de ter que baixá-los novamente.

Speculation Rules API

A Speculation Rules API é projetada para melhorar o desempenho para navegações futuras. Uma vez que um visitante aterrissou na sua página, você pode usar as speculationrules para instruir o navegador a buscar (com a diretiva prefetch) ou até renderizar (com a diretiva prerender) páginas que o visitante provavelmente visitará. A Speculation Rules API é mais flexível e configurável que o método link prefetch.

Veja este exemplo onde o navegador é instruído a fazer prefetch da URL na barra de menu para uma navegação futura, mantendo-a em memória para que possa ser usada para acelerar a próxima navegação.

<script type="speculationrules">
{"prerender": 
[{
  "source": "document",
  "where": {"selector_matches": "nav a"},
  "eagerness": "moderate"
}]}
</script>

Page Prefetching

Se você não deseja usar a Speculation Rules API por causa do seu fraco suporte de navegador você poderia usar um pequeno script chamado quicklink. Isso fará prefetch de todos os links no viewport visível e praticamente eliminará o Time To First Byte para esses links!

A desvantagem do quicklinks é que requer mais recursos do navegador, mas por enquanto ele superará a Speculation Rules API.

Como melhorar o TTFB - aproveitar um CDN

Uma Content Delivery Network ou CDN usa uma rede distribuída de servidores para entregar recursos aos usuários. Esses servidores geralmente estão geograficamente mais próximos dos usuários finais e super-otimizados para velocidade.

T
TTFB com CDN e edge caching

T
TTFB sem CDN hospedado na Alemanha

Um CDN pode ajudar a melhorar 5 de 6 partes do Time to First Byte:

• Tempo de redirecionamento: A maioria dos CDN's pode armazenar em cache redirecionamentos na edge ou usar edge workers para lidar com redirecionamentos sem a necessidade de conectar ao servidor de origem.
• Tempo de consulta DNS: A maioria dos CDN's oferece servidores DNS extremamente rápidos que provavelmente superarão seus servidores DNS atuais
  
• Conexão TCP & Tempo de handshake SSL. A maioria dos CDN's é configurada extremamente bem e essas configurações, junto com a maior proximidade aos usuários finais, acelerarão o tempo de conexão + handshake
  
• Resposta do servidor: CDN's podem acelerar o tempo de resposta do servidor de várias formas. A primeira é armazenando em cache a resposta do servidor na edge (cache de página completa na edge), mas também oferecendo excelente compressão (Brotli) e os protocolos mais recentes (HTTP/3)

Como melhorar o TTFB - Evitar redirecionamentos

O tempo de redirecionamento é adicionado ao Time To First Byte. Portanto, como regra geral, evite redirecionamentos o máximo possível. Redirecionamentos podem acontecer quando um recurso não está mais disponível em um local, mas foi movido para outro local. O servidor responderá com um cabeçalho de resposta de redirecionamento e o navegador tentará esse novo local.

Redirecionamentos de mesma origem. Redirecionamentos de mesma origem originam-se de links no seu próprio site. Você deve ter controle total sobre esses links e deve priorizar a correção desses links ao trabalhar no Time to First Byte. Existem muitas ferramentas disponíveis que permitem verificar todo o seu site em busca de redirecionamentos

Redirecionamentos de origem cruzada. Redirecionamentos de origem cruzada originam-se de links em outros sites. Você tem muito pouco controle sobre esses.

Múltiplos redirecionamentos. Múltiplos redirecionamentos ou cadeias de redirecionamento ocorrem quando um único redirecionamento não redireciona para o local final do recurso. Esses tipos de redirecionamento sobrecarregam mais o Time to First byte e devem ser evitados a todo custo. Novamente, use uma ferramenta para encontrar esses tipos de redirecionamentos e corrigi-los!

Redirecionamentos HTTP-para-HTTPS. Uma forma de contornar isso é usar o cabeçalho Strict-Transport-Security (HSTS), que forçará o HTTPS na primeira visita a uma origem e depois dirá ao navegador para acessar imediatamente a origem através do esquema HTTPS em visitas futuras.

Quando um usuário solicita uma página web, o servidor pode responder com um redirecionamento para outra página. Este redirecionamento pode adicionar tempo adicional ao TTFB porque o navegador deve fazer uma solicitação adicional para a nova página.

Existem várias formas de evitar redirecionamentos ou minimizar o impacto dos redirecionamentos:

1. Atualize seus links internos! Sempre que você mudar a localização de uma página, atualize seus links internos para essa página para garantir que nenhuma referência à localização anterior da página permaneça.
   
2. Lide com redirecionamentos no nível do servidor.
   
3. Use URLs relativos: Ao vincular páginas no seu próprio site, use URLs relativos em vez de URLs absolutos. Isso ajudará a prevenir redirecionamentos desnecessários.
   
4. Use URLs canônicos: Se você tem múltiplas páginas com conteúdo similar, use um URL canônico para indicar a versão preferida da página. Isso ajudará a prevenir conteúdo duplicado e redirecionamentos desnecessários.
   
5. Use redirecionamentos 301: Se você precisar usar um redirecionamento, use um redirecionamento 301 em vez de um redirecionamento 302. Um redirecionamento 301 é um redirecionamento permanente, enquanto um redirecionamento 302 é um redirecionamento temporário. Usar um redirecionamento 301 ajudará a prevenir redirecionamentos desnecessários.