Corrija e Identifique Problemas de Time to First Byte (TTFB)

Encontre e Corrija Problemas de Time to First Byte (TTFB)

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

No nosso artigo anterior falamos sobre o Time to First Byte. Se quiser rever os conceitos básicos, esse é um ótimo ponto de partida.

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

DICA DE TTFB: na maioria das vezes o TTFB será muito pior para visitantes de primeira vez, já que eles não possuem cache de DNS para o seu site. Ao monitorar o TTFB faz muito sentido distinguir entre visitantes de primeira vez e visitantes recorrentes.

Passo 1: Verifique o TTFB no Search Console

"O primeiro passo para a recuperação é admitir que você tem um problema." Então, antes de fazer qualquer coisa para corrigir o Time to First Byte, vamos ter certeza de 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 do CrUX do nosso site. Felizmente os passos são simples: navegue até pagespeed.web.dev, insira a URL da sua página e certifique-se de que o botão "origin" esteja marcado (pois 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 dispositivo.

No exemplo abaixo você verá um site que está falhando nos Core Web Vitals por causa de um TTFB alto.

Passo 1b: Use o Cabeçalho Server-Timing para uma Análise Mais Profunda

O cabeçalho de resposta HTTP Server-Timing permite que o seu servidor comunique métricas de desempenho do backend diretamente ao navegador. Isso possibilita identificar exatamente qual parte do processamento do servidor está lenta, sem precisar de acesso aos 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 reporta três valores de temporização:

• 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 utilizado para esta requisição (um cache miss).

Você pode ler esses valores no Chrome DevTools abrindo a aba Network, selecionando a requisição do documento e rolando até a seção "Server Timing" na aba Timing. 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);

Em Node.js com Express:

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

O cabeçalho Server-Timing é especialmente útil quando combinado com 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 enviando dicas de recursos antes que a resposta completa esteja pronta.

Passo 2: Configure o Monitoramento 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 contribuem para flutuações no TTFB. Para obter respostas a todas as perguntas acima precisamos medir os dados na vida real e registrar qualquer problema que possa ocorrer com o Time to First Byte. Isso se chama Real User Monitoring, e existem várias maneiras de habilitar o monitoramento RUM. Desenvolvemos o CoreDash justamente para esses casos de uso. O CoreDash é uma ferramenta de RUM de baixo custo, rápida e eficaz que dá conta do recado. É claro que existem muitas soluções de RUM por aí e elas também farão o trabalho (porém a um custo 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 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.
Então o TTFB NÃO é sobre quão rápido a refeição inteira é cozida (First Contentful Paint) e servida (Largest Contentful Paint), mas sim sobre quão responsiva a cozinha é ao pedido inicial.
Monitoramento 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 recorrentes recebem tratamento preferencial enquanto novos visitantes precisam esperar mais tempo 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 percentil 75 do TTFB nas seguintes dimensões, pois isso ajudará a medir a eficácia das suas otimizações posteriormente:

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 vez tipicamente têm TTFB mais alto por causa da sobrecarga de DNS e conexão.
4. Top 5 países por tráfego: a distância geográfica até o seu servidor afeta significativamente o TTFB.
5. Detalhamento das subpartes do TTFB: registre o percentil 75 para cada subparte (waiting, cache, DNS, connection, request).

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

Passo 3: Identifique 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 de um 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 TTFB falhando de forma geral e TTFB falhando sob condições específicas (embora na realidade sempre haverá uma combinação).

3.1 O TTFB Está Falhando de Forma Geral

1. Verifique se há tempos de requisição ruins de forma 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 outras subpartes do TTFB com desempenho ruim: O TTFB não é apenas uma métrica única, mas pode ser dividido em múltiplas partes, cada uma com seu próprio potencial de otimização. Se a waiting duration, a cache duration, a DNS lookup duration ou a connection duration estiverem lentas, você provavelmente precisará ajustar as configurações do seu servidor ou começar a procurar hospedagem de melhor qualidade.

3.2 O TTFB Está Falhando Sob Condições Específicas

1. Segmentação por país: Entender a distribuição geográfica de TTFB alto é importante, especialmente para sites com audiência global. Se você está servindo suas páginas a partir de um servidor em apenas um país (sem cache de borda via CDN), a distância física entre a localização do usuário e o servidor que hospeda o site causará todo tipo de atrasos e impactará o TTFB. Considere configurar o Cloudflare ou outro CDN para aproximar seu conteúdo dos usuários em todo o mundo.
   
2. Segmentação por cache: O cache pode reduzir o TTFB pulando a geração do HTML no lado do servidor. Infelizmente é comum que o cache esteja desabilitado ou seja contornado por diversas razões. Por exemplo, o cache pode ser desabilitado para usuários logados, páginas de carrinho de compras, páginas com query strings (ex.: vindas do Google Ads), páginas de resultados de busca e páginas de checkout. Se o seu site usa cache (de borda), use monitoramento RUM para verificar a taxa de acerto do cache.
   
3. Segmentação por página (cluster): A diferença no desempenho do Time to First Byte (ou a falta de diferença) entre páginas ou tipos de página é outra coisa que precisamos determinar. Saber quais páginas falham na métrica de TTFB fornecerá insights valiosos sobre como melhorar o Time to First Byte.
   
4. Segmentação por 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 análise mais aprofundada sobre otimização de redirecionamentos, consulte nosso guia sobre a waiting duration, subparte do TTFB.
   
5. Outras segmentações: Embora a segmentação pelas variáveis acima cubra os suspeitos habituais, cada site é único e tem seus próprios desafios. Felizmente o monitoramento RUM é projetado para permitir segmentação por muitas outras variáveis como RAM do dispositivo, velocidade da rede, tipo de dispositivo, sistema operacional, variáveis personalizadas e muito mais.

Passo 4: Analise os Problemas em Detalhe e Corrija

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

• Waiting + Redirect (ou waiting duration)
• Worker + Cache (ou cache duration)
• DNS (ou DNS duration)
• Connection (ou connection duration)
• Request (ou request duration)

Passo 5: Checklist Rápido para Problemas Comuns de TTFB

Com base na subparte que mais contribui 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 Navigation Timing API. O seguinte trecho de código 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 do TTFB. Executar este trecho no console do navegador fornece uma leitura imediata para um único carregamento de página, enquanto ferramentas de RUM coletam esses dados de milhares de usuários reais para produzir valores confiáveis no percentil 75.

Leitura Adicional: Guias de Otimização

Para técnicas de otimização específicas que melhoram o TTFB, explore estes 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.
• Configure o Cloudflare para Desempenho: configure o CDN, cache e recursos de borda do Cloudflare para reduzir o TTFB para audiências globais.

Subpartes do TTFB: Artigos de Análise Aprofundada

Cada subparte do Time to First Byte tem estratégias de otimização únicas. Explore a área específica que seus dados de RUM identificam como gargalo:

• Waiting Duration: redirecionamentos, enfileiramento do navegador e otimização de HSTS.
• Cache Duration: desempenho do service worker, cache do navegador e bfcache.
• DNS Duration: seleção de provedor de DNS, configuração de TTL e dns-prefetch.
• Connection Duration: handshake TCP, otimização de TLS, HTTP/3 e preconnect.