Qual é um bom valor alvo de TTFB?

Abaixo de 200ms é considerado bom para a maioria dos sites, 200-500ms precisa de melhorias, e qualquer coisa acima de 500ms é um problema genuíno. Ao contrário do LCP ou do CLS, não é um Core Web Vital oficial, mas é uma base rígida sob os três - nada a jusante pode começar até o primeiro byte chegar.

Uma CDN corrige o TTFB mesmo em páginas dinâmicas?

Apenas parcialmente. Uma CDN acelera recursos estáticos e pode colocar em cache respostas HTML completas para páginas que não mudam por pedido, mas uma página genuinamente dinâmica (conteúdo personalizado, dados em tempo real) ainda tem de chegar à sua origem - para isso, a correção é do lado do servidor (velocidade de consultas, cold starts de funções, posicionamento regional), não a cache.

Porque é que o TTFB é lento no meu primeiríssimo pedido após um deploy mas rápido depois disso?

Isso é quase sempre um cold start em infraestrutura serverless - a função tem de se inicializar antes de conseguir processar o pedido. Pedidos seguintes chegam a uma instância já quente. Se o seu padrão de tráfego é irregular, os cold starts podem importar mais do que o seu TTFB médio sugere.

O Scanverra mede o TTFB separadamente do LCP?

Sim. É uma métrica distinta, capturada na mesma passagem do Lighthouse usada para o LCP e o CLS, para que possa perceber se um LCP lento é na verdade um problema de servidor lento disfarçado ou um problema de renderização genuinamente separado.

Como Corrigir um Time to First Byte (TTFB) Lento

Porque é que o Seu Servidor É Lento a Responder

O TTFB é quase inteiramente um problema de backend e de rede, não de frontend. Causas comuns:

Cold starts. Funções serverless que têm de iniciar um ambiente de execução antes de processar o primeiro pedido após um período de inatividade.
Renderização dinâmica sem cache. Cada pedido a reexecutar consultas à base de dados e renderização no lado do servidor que poderiam ter sido colocadas em cache ou calculadas uma única vez.
Consultas lentas à base de dados. Uma única consulta sem índice ou um padrão N+1 pode adicionar centenas de milissegundos antes de o servidor sequer começar a escrever uma resposta.
Grande distância física até à origem. Um visitante em Singapura a aceder a um servidor na Virgínia paga essa viagem de ida e volta em cada pedido, independentemente da rapidez com que o próprio servidor responde.
Cadeias de redirecionamento. Cada salto (http → https → www → URL final) é uma viagem de ida e volta completa antes de a resposta real sequer começar.

Como Identificar o Que Está Realmente Lento

As verificações de desempenho do Scanverra capturam o TTFB como parte da mesma execução do Lighthouse usada para o LCP e o CLS, contra o seu URL em produção - pelo que obtém o número real de tempo de resposta do servidor, não um proxy para ele. Isso importa porque um LCP lento com um TTFB rápido aponta para correções de imagem/renderização, enquanto um LCP lento com um TTFB lento significa que corrigir o servidor tem de vir primeiro.

Para restringir para onde o tempo está realmente a ir, verifique a repartição de tempos do lado do servidor do seu fornecedor de alojamento ou APM (a maioria das plataformas reporta separadamente o tempo gasto na inicialização de funções, chamadas à base de dados e serialização da resposta) em vez de adivinhar a partir do exterior.

Como Corrigir

1. Coloque em cache o que não precisa de ser regenerado por pedido

Qualquer coisa que seja igual para todos os visitantes - ou para todos os visitantes num determinado segmento - é candidata a cache. Defina um tempo de vida de cache explícito no edge da CDN em vez de deixar cada pedido chegar à sua origem:

Coloque em cache no edge, mas revalide em segundo plano para o conteúdo não ficar desatualizadotypescript

1Cache-Control: public, max-age=60, stale-while-revalidate=300

2. Aproxime a sua origem (ou pelo menos uma camada de cache) dos seus utilizadores

Faça deploy numa região próxima do seu tráfego real, ou coloque uma cache/CDN de edge à frente de uma origem distante para que a maioria dos pedidos nunca faça a longa viagem de ida e volta.

3. Corrija a consulta lenta, não o sintoma

Se o seu APM mostra o tempo de base de dados a dominar o TTFB, isso normalmente é um índice em falta, um padrão de consulta N+1, ou uma consulta a fazer mais trabalho do que a página realmente precisa - analise a consulta específica antes de recorrer à cache como solução paliativa.

4. Reduza a frequência de cold starts em funções serverless

Mantenha funções quentes para rotas sensíveis à latência, minimize o código e as dependências que têm de ser inicializados antes de o handler ser executado, e considere um servidor persistente para padrões de tráfego em que os cold starts acontecem constantemente.

5. Elimine cadeias de redirecionamento

Cada salto entre o URL que um utilizador pede e o URL que realmente serve o conteúdo é uma viagem de ida e volta completa adicionada ao TTFB antes de a renderização poder começar - aponte ligações e URLs canónicos diretamente para o destino final.

Como o Scanverra Deteta Problemas de TTFB

O TTFB é capturado diretamente da mesma passagem real do Lighthouse que o Scanverra executa para cada verificação de desempenho - tanto num perfil desktop como num viewport mobile de 375px - pelo que é medido contra a resposta real do seu servidor em produção, não simulado.