Por que o seu Time to First Byte está lento e o que fazer a respeito

Comece pelo que o TTFB realmente mede

Time to First Byte, geralmente abreviado como TTFB, é o tempo entre o navegador solicitar um recurso e receber o primeiro byte da resposta.

Isso soa como uma métrica de servidor, mas não é apenas uma métrica de servidor. O TTFB inclui várias etapas:

• Consulta DNS, se o hostname ainda não estiver resolvido
• Configuração da conexão TCP
• Negociação TLS para HTTPS
• Tempo de deslocamento da solicitação até o servidor ou a borda da CDN
• Enfileiramento e processamento no servidor
• Tempo de deslocamento da resposta de volta ao navegador

Portanto, um TTFB alto pode significar que o seu backend está lento. Também pode significar que o utilizador está longe da sua origem, que a sua CDN está mal configurada, que a sua cache falha constantemente ou que o seu servidor está demorando demais para decidir o que enviar.

Isso importa porque o TTFB fica perto do início da cadeia de carregamento. Se o documento HTML chega tarde, o navegador também descobre tarde o CSS, JavaScript, fontes e imagens. Você pode ter uma excelente otimização de front-end e ainda assim parecer lento se a primeira resposta do documento levar 1,5 segundo.

O que conta como um TTFB lento?

Não há um número universal que sirva para todos os sites, regiões e arquiteturas. Ainda assim, limiares práticos ajudam.

A orientação do Google web.dev classifica um bom TTFB como abaixo de 800 ms, com 800–1800 ms precisando de melhorias e acima de 1800 ms sendo considerado ruim. Para uma página de marketing bem armazenada em cache e servida perto do utilizador, muitas vezes é possível fazer bem melhor do que isso. Para um dashboard autenticado complexo fazendo trabalho dinâmico, o número aceitável pode ser maior, mas ainda deve ser explicável.

O hábito importante é segmentar o número. Uma média global de TTFB de 900 ms pode esconder uma resposta de 150 ms para utilizadores próximos da borda da sua CDN e uma resposta de 2200 ms para utilizadores em outra região. Da mesma forma, a sua página inicial pode estar boa enquanto páginas de pesquisa, categoria ou com login estão discretamente dolorosas.

Meça em mais de um lugar

Não diagnostique TTFB a partir de uma única execução do Lighthouse. O Lighthouse é útil, mas é um teste feito a partir de um ambiente. Se você está começando a interpretá-lo, comece com uma leitura tranquila de como ler um relatório do Lighthouse sem entrar em pânico — a principal lição é separar sinais de laboratório da realidade de campo.

Para TTFB, você quer pelo menos três perspectivas:

1. Ferramentas de desenvolvimento do navegador

Abra o painel Network, recarregue com a cache desativada e inspecione a solicitação do documento principal. A decomposição de tempos mostra as fases de DNS, conexão, TLS, espera e download. A fase de “espera” muitas vezes é o que as pessoas querem dizer com tempo de backend, embora possa incluir latência upstream.

2. Testes sintéticos a partir de várias regiões

Execute testes de locais próximos e distantes dos seus utilizadores. Se o TTFB é baixo em uma região e alto em outra, suspeite de geografia, roteamento de CDN, localização da origem ou cobertura de cache antes de reescrever o código da aplicação.

3. Monitoramento de utilizadores reais ou logs do servidor

Dados de campo mostram o que utilizadores reais experimentam em dispositivos, redes e sessões. Logs do servidor podem indicar se a origem gerou uma resposta rapidamente. A diferença entre o TTFB observado pelo cliente e o tempo de processamento na origem costuma ser onde aparecem problemas de CDN e rede.

As causas usuais de TTFB lento

O seu HTML não está sendo armazenado em cache

Este é o problema mais comum em sites de conteúdo e ecommerce. Ativos estáticos são armazenados em cache de forma agressiva, mas o documento HTML — aquilo de que o navegador precisa primeiro — é gerado a cada solicitação.

Às vezes isso é necessário. Muitas vezes não é.

Se uma página pública muda algumas vezes por dia, provavelmente não deveria exigir uma renderização nova a partir do banco de dados para cada visitante anônimo. Use cache de página inteira, cache na borda, geração estática ou padrões stale-while-revalidate quando apropriado.

Verifique os cabeçalhos de resposta em busca de sinais como Cache-Control, CDN-Cache-Status, Age, Vary e Set-Cookie. Uma página que envia um cookie exclusivo para cada visitante pode, acidentalmente, tornar-se impossível de armazenar em cache. Se você precisa de uma forma prática de raciocinar sobre essa camada, os mesmos hábitos de depuração em nosso guia sobre redirecionamentos e cabeçalhos HTTP em produção se aplicam diretamente ao trabalho com TTFB.

A sua CDN só está armazenando ativos em cache

Muitas equipes adicionam uma CDN e presumem que o trabalho de desempenho está concluído. Mas, se a CDN só serve imagens, CSS e JavaScript, a primeira solicitação HTML ainda pode viajar até um único servidor de origem.

Isso pode estar bem para um site de negócio local com utilizadores locais. Não está bem para uma audiência internacional. Quanto mais longe o utilizador está da origem, mais latência você paga antes mesmo de o trabalho de backend começar.

Uma boa configuração de CDN para TTFB geralmente significa:

• Armazenar HTML público em cache quando for seguro
• Respeitar regras intencionais de bypass para páginas autenticadas ou personalizadas
• Evitar cabeçalhos Vary desnecessários que fragmentam demais a cache
• Usar purga de cache ou revalidação em vez de desativar a cache por completo
• Confirmar que as localizações de borda estão realmente servindo hits, não encaminhando todas as solicitações

Uma CDN não é mágica. É uma camada de cache e roteamento. Trate-a como tal.

O seu servidor está fazendo demais antes de responder

Um caminho de backend lento pode surgir de muitos pequenos atrasos: consultas ao banco de dados, chamadas de API, renderização de templates, verificações de feature flags, autenticação, personalização, logging e cold starts.

O pior padrão é o trabalho com dependências em série. Por exemplo:

1. Buscar dados da página
2. Depois buscar produtos relacionados
3. Depois buscar preços
4. Depois chamar um serviço de recomendações
5. Depois renderizar HTML

Se cada etapa espera pela anterior, o TTFB cresce rapidamente. Paralelize trabalho independente, remova chamadas não críticas da primeira resposta e armazene resultados caros em cache.

Uma regra útil: se o utilizador não consegue ver ou usar o resultado imediatamente, provavelmente ele não deve bloquear o primeiro byte.

Consultas ao banco de dados são lentas ou imprevisíveis

Bancos de dados costumam causar problemas de TTFB porque se comportam bem em desenvolvimento e mal sob tráfego real. Índices ausentes, joins grandes, consultas N+1, contenção de locks e conjuntos de resultados grandes demais aparecem todos como “o servidor está lento”.

Não adivinhe aqui. Capture os tempos de consulta para solicitações lentas. Observe p95 e p99, não apenas médias. Uma página que geralmente responde em 120 ms, mas ocasionalmente bloqueia por 4 segundos, ainda criará uma experiência ruim para o utilizador.

Correções comuns incluem:

• Adicionar ou corrigir índices
• Remover padrões de consulta N+1
• Armazenar em cache dados com muita leitura
• Paginar consultas grandes
• Tirar consultas de relatórios ou analytics do tempo de solicitação
• Definir timeouts sensatos para chamadas downstream

A sua aplicação tem cold starts

Plataformas serverless e conteinerizadas podem ser excelentes, mas cold starts podem prejudicar o TTFB quando o tráfego é irregular ou as regiões estão subprovisionadas.

Se a sua primeira solicitação após um período ocioso é muito mais lenta do que as solicitações posteriores, investigue cold starts. Talvez você precise de concorrência provisionada, bundles menores, menos dependências de inicialização, funções aquecidas ou um formato de implantação diferente para rotas sensíveis à latência.

Isto não é um argumento contra serverless. É um argumento contra fingir que o modelo de runtime é invisível.

Redirecionamentos estão desperdiçando a primeira solicitação

Um redirecionamento adiciona outro ciclo de solicitação-resposta antes que o navegador receba o documento final. Um redirecionamento de http:// para https:// pode ser inevitável para links antigos, mas cadeias são desperdício.

Cadeias comuns incluem:

• http://example.com → https://example.com → https://www.example.com
• normalização de barra final após normalização de protocolo
• redirecionamentos geográficos ou de idioma antes da consulta à cache
• links de campanhas antigas que passam por vários URLs

Corrija os links de origem quando possível, consolide regras de redirecionamento e faça URLs canônicos serem diretos. O tempo de redirecionamento nem sempre é reportado como TTFB da solicitação final, mas o utilizador ainda paga por ele.

Uma sequência prática de depuração

Quando o TTFB parece lento, use esta ordem. Ela evita o erro comum de otimizar código da aplicação antes de confirmar o comportamento de cache e roteamento.

Etapa 1: Teste o documento principal, não apenas a página inteira

Encontre a solicitação do documento HTML. Registre o TTFB total e a decomposição de tempos. Repita com e sem a cache do navegador. Teste uma página pública, uma página dinâmica e uma página com login, se for relevante.

Etapa 2: Compare regiões

Execute o mesmo URL a partir de várias localizações geográficas. Se as regiões lentas correlacionam com a distância da origem, priorize CDN e cache na borda. Se todas as regiões estão lentas, olhe para o processamento de backend e a capacidade da origem.

Etapa 3: Inspecione os cabeçalhos de resposta

Procure cabeçalhos de cache, cookies, Age, status da CDN e Vary. Um cabeçalho Age ausente ou falhas repetidas de cache são pistas. Um cabeçalho amplo Vary: Cookie em HTML público costuma destruir a cache.

Etapa 4: Verifique o tempo na origem

Adicione instrumentação de tempos do servidor. O cabeçalho Server-Timing pode expor fases do backend, como tempo de banco de dados, tempo de renderização e tempo de API upstream. Mesmo rótulos simples são úteis:

Server-Timing: db;dur=82, render;dur=41, api;dur=210

Agora os tempos do navegador podem mostrar se o servidor gastou 300 ms em trabalho real ou se o atraso aconteceu antes de a solicitação chegar à sua aplicação.

Etapa 5: Corrija o maior atraso confirmado

Isso parece óbvio, mas equipes muitas vezes corrigem o que é familiar em vez do que foi medido. Se falhas de cache dominam, corrija a cache. Se o banco de dados domina, corrija as consultas. Se TLS e configuração de conexão dominam para utilizadores globais, corrija roteamento, cobertura de CDN ou geografia da origem.

O trabalho de front-end ainda importa. Fontes, imagens e JavaScript afetam o que acontece depois que o HTML chega. Mas eles não substituem uma primeira resposta rápida. Se você também está trabalhando no desempenho de renderização, fontes web continuam sendo uma das vitórias mais fáceis em muitos sites, porque afetam a rapidez com que o texto se torna utilizável depois que o documento chega.

Correções que geralmente funcionam

Armazene HTML público em cache na borda

Para páginas de marketing, documentação, blogs, landing pages e páginas de categoria, cache na borda costuma ser a maior melhoria de TTFB. Use TTLs curtos se o conteúdo muda com frequência. Use stale-while-revalidate se conteúdo ligeiramente desatualizado for aceitável enquanto a cache é atualizada em segundo plano.

Tenha cuidado com personalização. Se uma página varia por moeda, idioma, estado de login ou grupo de experimento, defina essas variantes explicitamente. Variação acidental por utilizador destrói a eficiência da cache.

Remova trabalho não crítico do caminho da solicitação

Envio de email, enriquecimento de analytics, geração de recomendações, chamadas de webhook e logging pesado raramente devem bloquear o primeiro byte. Coloque-os em filas ou execute-os depois que a resposta for iniciada.

Reduza cadeias de dependência no backend

Paralelize chamadas independentes. Armazene em cache respostas de APIs lentas. Defina timeouts. Projete conteúdo de fallback para serviços que são úteis, mas não essenciais.

Um widget de recomendações lento não deve atrasar a página de produto inteira.

Coloque a computação mais perto dos utilizadores

Se os seus utilizadores são globais e a sua origem está em uma única região, a latência é estrutural. Cache em CDN pode esconder boa parte disso para conteúdo público. Para conteúdo dinâmico, considere implantações regionais, renderização na borda para rotas adequadas ou mover APIs para mais perto da audiência.

Mantenha redirecionamentos sem surpresas

Canonicalize URLs em um salto. Atualize links internos para que utilizadores e crawlers sigam diretamente para o destino final. Audite URLs de campanhas antigas e migrações de plataforma. Redirecionamentos são fáceis de ignorar porque são invisíveis quando funcionam, mas ainda custam tempo.

O que não fazer

Não persiga um número perfeito de TTFB para cada rota. Um relatório autenticado que executa computação real não se comportará como um post de blog em cache.

Não use TTFB médio como sua única métrica. Percentis importam. Geografia importa. Tipo de página importa.

Não presuma que uma CDN significa que o seu HTML está em cache. Verifique.

E não trate TTFB como algo separado de decisões de produto. Personalização, experimentação, inventário em tempo real e serviços de terceiros têm custos de latência. Alguns valem a pena. Alguns são apenas hábito.

<!-- tool-cta:start -->

💡 Experimente isto: Ao diagnosticar o TTFB, Get Headers revela o estado do cache, os tempos do servidor e os redirecionamentos que muitas vezes explicam de onde vem o atraso.

<!-- tool-cta:end -->

A versão tranquila do plano

Um TTFB lento geralmente é corrigível quando você deixa de tratá-lo como um vago “problema de servidor”. Meça a solicitação do documento. Segmente por região e tipo de página. Inspecione cabeçalhos. Compare tempos do cliente com tempos da origem. Depois corrija o maior gargalo confirmado.

A maioria dos sites não precisa de arquitetura exótica. Precisa de menos falhas de cache evitáveis, menos trabalho de backend bloqueante, redirecionamentos mais limpos e uma ideia mais clara do que precisa acontecer antes que o primeiro byte seja enviado.