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 de Time to First Byte (TTFB). TTFB é uma métrica de diagnóstico que mede o tempo entre a solicitação de uma página por um usuário e o navegador recebendo o primeiro byte da resposta. Embora o TTFB não seja um Core Web Vitals por si só, ele influencia diretamente o First Contentful Paint (FCP) e o Largest Contentful Paint (LCP). Um bom TTFB é inferior a 800 milissegundos no percentil 75.

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

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

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

Etapa 1: Verificar 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 é relatado 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: 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 do site todo 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á falhando nos Core Web Vitals devido a um alto TTFB.

Etapa 1b: Usar o Cabeçalho Server-Timing para Obter Insights Mais Profundos

O cabeçalho de resposta HTTP Server-Timing permite que seu servidor comunique métricas de desempenho de backend diretamente para o navegador. Isso torna possível apontar 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 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 template, 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, selecionando a solicitaçã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, pois permite que você correlacione o desempenho do lado do servidor com o TTFB que 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.

Etapa 2: Configurar Rastreamento RUM

O Time to First Byte é uma métrica complexa. Não podemos simplesmente confiar em testes sintéticos para medir o TTFB, pois na vida real outros fatores contribuirão para flutuações no 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 (RUM), e existem várias maneiras de habilitar o rastreamento RUM. Nós desenvolvemos o CoreDash exatamente 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 no mercado e elas também farão o trabalho (embora por 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 web é um cliente com fome 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 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 a experiência deles no restaurante. Você pode descobrir que os clientes sentados mais longe da cozinha recebem menos atenção do garçom e são servidos mais tarde, ou que os clientes recorrentes recebem tratamento preferencial, enquanto os novos visitantes precisam esperar mais por uma mesa.

Etapa 2b: Estabelecer 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 do percentil 75 nas seguintes dimensões, pois isso ajudará você a medir a eficácia das 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 as suas páginas de maior tráfego individualmente.
3. Novos visitantes vs. visitantes recorrentes: visitantes de primeira viagem normalmente têm um TTFB maior 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 por vez, medir e depois passar para a próxima.

Etapa 3: Identificar 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 o TTFB de forma eficaz, precisamos saber exatamente o que está acontecendo em um nível mais detalhado. Neste ponto, faz sentido distinguir entre o TTFB falhando em geral e o TTFB falhando sob condições específicas (embora, na realidade, sempre haverá uma mistura).

3.1 O TTFB Está Falhando em 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 de pontuações ruins de TTFB.
2. Verifique se há outras subpartes ruins do TTFB: O TTFB não é apenas uma métrica única, mas pode ser dividido em várias partes que têm seu próprio potencial de otimização. Se a duração da espera, duração do cache, duração da busca DNS ou a duração da 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á Falhando 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 edge caching via 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 trazer seu conteúdo para mais perto de usuários em todo o mundo.
   
2. Segmentação de cache: O cache pode reduzir o TTFB pulando 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 acerto do 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 páginas ou tipos de página é outra coisa que precisamos determinar. Saber quais páginas falham 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 um olhar mais profundo sobre a otimização de redirecionamento, veja nosso guia para a subparte de duração da espera 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 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.

Etapa 4: Ampliar Foco nos Problemas e Corrigir

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

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

Etapa 5: Lista de Verificação de Correção Rápida para Problemas Comuns de TTFB

Com base na subparte que está contribuindo mais 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 trecho 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 este trecho no console do navegador fornece uma leitura imediata para o carregamento de uma única página, enquanto as ferramentas RUM coletam esses dados através 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 por qualquer subparte que seus dados RUM identifiquem como o gargalo:

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