Corrigir e Identificar Problemas de Time to First Byte (TTFB)

Encontrar e Corrigir Problemas de Time to First Byte (TTFB)

Este artigo faz parte do nosso guia sobre Time to First Byte (TTFB). O TTFB é uma métrica de diagnóstico que mede o tempo entre o usuário solicitar uma página e o navegador receber o primeiro byte da resposta. Embora o TTFB não seja um Core Web Vital em si, ele influencia diretamente o First Contentful Paint (FCP) e o Largest Contentful Paint (LCP). Um bom TTFB é inferior a 800 milissegundos no percentil 75.

No nosso artigo anterior, falamos sobre o Time to First Byte. Se você quiser ler sobre os conceitos básicos, esse é um ótimo lugar para começar.

Neste artigo, vamos focar em identificar os diferentes problemas de Time to First Byte e depois explicar como corrigi-los.

DICA SOBRE TTFB: na maioria das vezes, o TTFB será muito pior para visitantes de primeira viagem, já que eles não têm um cache de DNS para o seu site. Ao rastrear o TTFB, faz muito sentido distinguir entre visitantes novos e recorrentes.

Passo 1: Verifique o TTFB no Search Console

"O primeiro passo para a recuperação é admitir que você tem um problema." Portanto, antes de fazermos qualquer coisa para corrigir o Time to First Byte, vamos garantir que realmente temos um problema com o TTFB.

Infelizmente, o Time to First Byte não é reportado no Google Search Console, então precisamos recorrer ao pagespeed.web.dev para consultar os dados CrUX do nosso site. Felizmente, os passos são fáceis: acesse pagespeed.web.dev, insira a URL da sua página e certifique-se de que o botão "origin" (origem) esteja marcado (já que precisamos de dados de todo o site e não apenas da página inicial). Agora, alterne entre Mobile e Desktop e verifique o Time to First Byte para ambos os tipos de dispositivos.

No exemplo abaixo, você verá um site que está reprovando nos Core Web Vitals devido a um TTFB alto.

Passo 1b: Use o Cabeçalho Server-Timing para Análises mais Profundas

O cabeçalho HTTP de resposta Server-Timing permite que o seu servidor comunique métricas de desempenho do backend diretamente para o navegador. Isso torna possível identificar exatamente qual parte do processamento do servidor está lenta sem precisar acessar os logs do servidor.

Um cabeçalho Server-Timing típico se parece com isto:

Server-Timing: db;dur=53, app;dur=120, cache;desc="miss"

Neste exemplo, o servidor relata três valores de tempo:

• db;dur=53: a consulta ao banco de dados levou 53 milissegundos.
• app;dur=120: a lógica da aplicação (renderização de templates, chamadas de API, etc.) levou 120 milissegundos.
• cache;desc="miss": o cache do servidor não foi usado para esta solicitação (um cache miss).

Você pode ler esses valores no Chrome DevTools abrindo a aba Network (Rede), selecionando a solicitação do documento e rolando até a seção "Server Timing" na aba Timing (Tempo). Os valores também são acessíveis através da API PerformanceServerTiming em JavaScript:

const [navigation] = performance.getEntriesByType('navigation');
if (navigation.serverTiming) {
  navigation.serverTiming.forEach(entry => {
    console.log(`${entry.name}: ${entry.duration}ms (${entry.description})`);
  });
}

Se o seu servidor ainda não envia cabeçalhos Server-Timing, considere adicioná-los. A maioria dos frameworks web torna isso simples. Em PHP, você pode adicionar o cabeçalho antes de qualquer saída:

header('Server-Timing: db;dur=' . $dbTime . ', app;dur=' . $appTime);

No Node.js com Express:

res.setHeader('Server-Timing', `db;dur=${dbTime}, app;dur=${appTime}`);

O cabeçalho Server-Timing é especialmente útil quando combinado com RUM (Real User Monitoring) porque permite correlacionar o desempenho do lado do servidor com o TTFB que os usuários reais experimentam. Saiba mais sobre como o 103 Early Hints pode reduzir ainda mais o TTFB percebido ao enviar dicas de recursos antes que a resposta completa esteja pronta.

Passo 2: Configure o Rastreamento RUM

O Time to First Byte é uma métrica complexa. Não podemos simplesmente confiar em testes sintéticos para medir o TTFB porque, na vida real, outros fatores contribuirão para as flutuações do TTFB. Para obter respostas a todas as perguntas acima, precisamos medir os dados na vida real e registrar quaisquer problemas que possam ocorrer com o Time to First Byte. Isso é chamado de Real User Monitoring (Monitoramento de Usuários Reais), e existem várias maneiras de ativar o rastreamento RUM. Desenvolvemos o CoreDash justamente para esses casos de uso. O CoreDash é uma ferramenta RUM de baixo custo, rápida e eficaz que faz o trabalho. É claro que existem muitas soluções RUM por aí e elas também farão o trabalho (embora a um preço mais alto).

Como pensar sobre o TTFB: Imagine que um servidor web é a cozinha de um restaurante, e um usuário solicitando uma página da web é um cliente faminto fazendo um pedido. O Time to First Byte (TTFB) é o intervalo de tempo entre o cliente fazer o pedido e a cozinha começar a preparar a comida.
Portanto, o TTFB NÃO é sobre o quão rápido a refeição inteira é cozida (First Contentful Paint) e servida (Largest Contentful Paint), mas sim o quão responsiva a cozinha é à solicitação inicial.
O rastreamento RUM se compara a pesquisar os clientes para entender sua experiência gastronômica. Você pode descobrir que clientes sentados mais longe da cozinha recebem menos atenção do garçom e são servidos mais tarde, ou que clientes frequentes recebem tratamento preferencial enquanto novos visitantes precisam esperar mais por uma mesa.

Passo 2b: Estabeleça uma Linha de Base de Desempenho

Antes de fazer qualquer alteração, estabeleça uma linha de base para o seu TTFB. Registre o TTFB no percentil 75 nas seguintes dimensões, pois isso ajudará você a medir a eficácia de suas otimizações mais tarde:

1. TTFB Geral (mobile e desktop separadamente): capture o percentil 75 para cada tipo de dispositivo.
2. Top 10 páginas por tráfego: registre o TTFB para suas páginas de maior tráfego individualmente.
3. Novos visitantes vs. visitantes recorrentes: visitantes de primeira viagem normalmente têm um TTFB mais alto devido à sobrecarga de DNS e conexão.
4. Top 5 países por tráfego: a distância geográfica do seu servidor afeta significativamente o TTFB.
5. Detalhamento das subpartes do TTFB: registre o percentil 75 para cada subparte (espera, cache, DNS, conexão, requisição).

Documente esses números em uma planilha. Após implementar cada otimização, espere pelo menos 7 dias para coletar dados RUM suficientes antes de comparar os resultados. Uma boa abordagem é lidar com uma subparte do TTFB de cada vez, medir e depois passar para a próxima.

Passo 3: Identifique os Problemas de Time to First Byte

Embora o Chrome User Experience Report (CrUX) do Google forneça dados de campo valiosos, ele não oferece detalhes específicos sobre as causas do TTFB alto. Para melhorar efetivamente o TTFB, precisamos saber exatamente o que está acontecendo em um nível mais detalhado. Neste ponto, faz sentido distinguir entre um TTFB geral reprovado e um TTFB reprovado sob condições específicas (embora, na realidade, sempre haverá uma mistura).

3.1 O TTFB está Reprovando no Geral

1. Verifique se há "tempos de requisição" ruins em geral: Tempos de requisição ruins significam que o "problema" está no tempo que o servidor leva para gerar a página. Esta é a causa mais comum para pontuações ruins de TTFB.
2. Verifique se há outras subpartes do TTFB com problemas: O TTFB não é apenas uma métrica única, mas pode ser dividido em várias partes, cada uma com seu próprio potencial de otimização. Se a duração de espera, duração de cache, duração de pesquisa de DNS, ou a duração de conexão estiverem lentas, você provavelmente precisará ajustar as configurações do seu servidor ou começar a procurar por uma hospedagem de melhor qualidade.

3.2 O TTFB está Reprovando sob Condições Específicas

1. Segmentação por país: Entender a distribuição geográfica do TTFB alto é importante, especialmente para sites com um público global. Se você estiver servindo suas páginas de um servidor em apenas um país (sem cache de borda de CDN), a distância física entre a localização do usuário e o servidor que hospeda o site causará todos os tipos de atrasos e impactará o TTFB. Considere configurar o Cloudflare ou outra CDN para aproximar seu conteúdo dos usuários em todo o mundo.
   
2. Segmentação por cache: O cache pode reduzir o TTFB ao pular a geração do HTML no lado do servidor. Infelizmente, é comum que o cache seja desativado ou ignorado por muitos motivos. Por exemplo, o cache pode ser desativado para usuários logados, páginas de carrinho de compras, páginas com query strings (por exemplo, do Google Ads), páginas de resultados de pesquisa e páginas de checkout. Se o seu site usar cache (de borda), use o rastreamento RUM para verificar a taxa de acertos de cache.
   
3. Segmentação de página (cluster): A diferença de desempenho do Time to First Byte (ou a falta de diferença) entre as páginas ou tipos de página é outra coisa que precisamos determinar. Saber quais páginas são reprovadas na métrica TTFB fornecerá insights valiosos sobre como melhorar o Time to First Byte.
   
4. Segmentação de redirecionamento: O tempo de redirecionamento é adicionado diretamente ao TTFB. Cada redirecionamento adiciona tempo extra antes que o servidor web possa começar a carregar a página. Medir e eliminar redirecionamentos desnecessários pode ajudar a melhorar o TTFB. Para uma visão mais aprofundada sobre a otimização de redirecionamentos, consulte nosso guia sobre a subparte de duração de espera do TTFB.
   
5. Outras segmentações: Embora a segmentação pelas variáveis acima cubra os suspeitos usuais, cada site é único e tem seus próprios desafios. Felizmente, o rastreamento RUM foi projetado para permitir a segmentação por muitas outras variáveis, como Memória RAM do Dispositivo, Velocidade da Rede, Tipo de Dispositivo, Sistema Operacional, variáveis personalizadas e muito mais.

Passo 4: Aprofunde-se nos Problemas e Corrija-os

As subpartes do Time to First Byte (TTFB) são:

• Espera + Redirecionamento (ou duração de espera)
• Worker + Cache (ou duração de cache)
• DNS (ou duração de DNS)
• Conexão (ou duração de conexão)
• Requisição (ou duração de requisição)

Passo 5: Checklist de Soluções Rápidas para Problemas Comuns de TTFB

Com base na subparte que mais está contribuindo para o seu TTFB, aqui está uma referência rápida para as correções mais comuns:

Medindo o TTFB com JavaScript

Você pode medir o TTFB completo e suas subpartes diretamente no navegador usando a API Navigation Timing. O snippet a seguir calcula o TTFB e registra cada subparte:

new PerformanceObserver((entryList) => {
  const [nav] = entryList.getEntriesByType('navigation');
  const activationStart = nav.activationStart || 0;

  const ttfb = nav.responseStart - activationStart;
  const waitingDuration = (nav.workerStart || nav.fetchStart) - activationStart;
  const cacheDuration = nav.domainLookupStart - (nav.workerStart || nav.fetchStart);
  const dnsDuration = nav.domainLookupEnd - nav.domainLookupStart;
  const connectionDuration = nav.connectEnd - nav.connectStart;
  const requestDuration = nav.responseStart - nav.requestStart;

  console.log('TTFB:', ttfb.toFixed(0), 'ms');
  console.log('  Waiting:', waitingDuration.toFixed(0), 'ms');
  console.log('  Cache:', cacheDuration.toFixed(0), 'ms');
  console.log('  DNS:', dnsDuration.toFixed(0), 'ms');
  console.log('  Connection:', connectionDuration.toFixed(0), 'ms');
  console.log('  Request:', requestDuration.toFixed(0), 'ms');
}).observe({
  type: 'navigation',
  buffered: true
});

Este código fornece o mesmo detalhamento que ferramentas como o CoreDash exibem no painel de atribuição de TTFB. Executar esse snippet no console do navegador fornece uma leitura imediata para o carregamento de uma única página, enquanto as ferramentas RUM coletam esses dados de milhares de usuários reais para produzir valores confiáveis de percentil 75.

Leitura Adicional: Guias de Otimização

Guias relacionados:

• 103 Early Hints: envie dicas de recursos antes que a resposta completa esteja pronta, permitindo que o navegador comece a carregar recursos críticos enquanto o servidor ainda está processando.
• Configurar o Cloudflare para Desempenho: configure a CDN, o cache e os recursos de borda do Cloudflare para reduzir o TTFB para públicos globais.

Subpartes do TTFB: Guias Completos

Cada subparte do Time to First Byte tem suas próprias estratégias de otimização. Comece com qualquer subparte que seus dados RUM identifiquem como o gargalo:

• Duração de Espera: redirecionamentos, enfileiramento do navegador e otimização de HSTS.
• Duração de Cache: desempenho do service worker, cache do navegador e bfcache.
• Duração de DNS: seleção de provedor de DNS, configuração de TTL e dns-prefetch.
• Duração de Conexão: handshake TCP, otimização de TLS, HTTP/3 e preconnect.
• Duração de Requisição: tempo de processamento do servidor, consultas ao banco de dados e otimização de backend.