Entenda TTFB de uma vez por todas (sem enrolação)

18 min de leitura  ·  Guia técnico

TTFB (Time to First Byte) é o tempo que o navegador leva para receber o primeiro byte de resposta do servidor após enviar uma requisição HTTP. Um TTFB alto indica gargalos no servidor, banco de dados ou rede — e o Google usa métricas de velocidade como parte do ranking de busca. Para medir e reduzir o TTFB do seu servidor, siga estes passos:

1. Meça o TTFB atual com curl ou WebPageTest para ter uma linha de base.
2. Identifique se o gargalo está no servidor web, PHP-FPM, banco de dados ou rede.
3. Ative cache de página (FastCGI Cache ou Redis) para eliminar processamento repetido.
4. Ajuste os parâmetros do pool PHP-FPM para evitar fila de requisições.
5. Otimize consultas lentas no banco de dados e ative query cache quando aplicável.
6. Valide o resultado medindo o TTFB novamente e compare com a linha de base.

O que é TTFB e por que ele afeta diretamente o desempenho do seu site

O TTFB (Time to First Byte) representa o intervalo entre o momento em que o navegador envia uma requisição HTTP e o instante em que recebe o primeiro byte da resposta do servidor. Esse número engloba três etapas distintas: o tempo de DNS lookup, o tempo de estabelecimento de conexão TCP (incluindo handshake TLS/SSL) e o tempo de processamento no servidor antes de começar a enviar a resposta. Entender cada uma dessas etapas é fundamental para diagnosticar onde está o gargalo real.

Do ponto de vista do Core Web Vitals do Google, o TTFB é um sinal de saúde do servidor. Valores abaixo de 200ms são considerados excelentes, entre 200ms e 500ms são aceitáveis, e acima de 800ms indicam problemas sérios que podem prejudicar tanto a experiência do usuário quanto o posicionamento orgânico. Sites lentos têm taxas de rejeição maiores, o que reforça o sinal negativo para o algoritmo.

É importante não confundir TTFB com tempo total de carregamento da página. Uma página pode ter TTFB baixo e ainda demorar para carregar por causa de imagens pesadas, JavaScript bloqueante ou fontes externas. O TTFB mede exclusivamente a responsividade do servidor — e é exatamente por isso que ele é o primeiro indicador a investigar quando um site está lento.

Para sites hospedados em servidores Linux configurados para hospedagem, o TTFB é diretamente influenciado pela pilha de software: Nginx ou Apache, PHP-FPM, MariaDB/MySQL e a camada de cache. Cada componente pode ser um ponto de falha.

Pré-requisitos

• Acesso SSH ao servidor (root ou usuário com sudo) — veja como acessar servidores VPS Linux da AviraHost.
• Servidor rodando Debian 12, Ubuntu 24.04 LTS, Rocky Linux 9 ou AlmaLinux 9.
• Nginx 1.26 ou Apache 2.4 instalado e em execução.
• PHP-FPM 8.3 configurado como processador PHP.
• MariaDB 11.4 ou MySQL 8.0 como banco de dados.
• Ferramenta curl disponível no terminal (padrão na maioria das distros).
• Acesso ao WebPageTest.org ou GTmetrix para validação externa.

Como medir o TTFB real do seu servidor com curl

Antes de qualquer otimização, você precisa de uma medição precisa do tempo de resposta do servidor. O curl permite isolar o TTFB sem interferência de CDN, cache de navegador ou recursos externos da página.

Execute o comando abaixo substituindo o domínio pelo seu:

curl -o /dev/null -s -w "DNS: %{time_namelookup}s\nConexão TCP: %{time_connect}s\nHandshake TLS: %{time_appconnect}s\nTTFB: %{time_starttransfer}s\nTotal: %{time_total}s\n" https://seudominio.com

Ao rodar este comando, você verá uma saída semelhante a esta:

DNS: 0.012s
Conexão TCP: 0.034s
Handshake TLS: 0.089s
TTFB: 0.423s
Total: 0.431s

Neste exemplo, o TTFB de 423ms está na faixa aceitável, mas próximo do limite. O handshake TLS consumiu 89ms — se esse valor for alto, considere usar OCSP Stapling e sessões TLS reutilizáveis. Para obter uma média mais confiável, execute o comando três vezes e calcule a média, pois a primeira requisição pode incluir overhead de conexão fria.

Para medir sem HTTPS (útil para isolar o TLS como causa):

curl -o /dev/null -s -w "TTFB: %{time_starttransfer}s\n" http://seudominio.com

Se o TTFB sem HTTPS for significativamente menor, o handshake TLS é parte do problema. Se ambos forem altos, o gargalo está no processamento do servidor.

Diagnóstico: identificando onde está o gargalo de TTFB

O diagnóstico de latência do servidor exige separar as camadas da aplicação. Um TTFB alto pode ter origens distintas, e tratar o sintoma errado não resolve o problema. Siga esta sequência de investigação:

1. Verifique os logs de acesso do Nginx: adicione $request_time e $upstream_response_time ao formato de log para ver quanto tempo cada requisição levou no servidor e quanto tempo o PHP-FPM demorou para responder.
2. Monitore o uso de CPU e memória: use top ou htop para verificar se o servidor está saturado. Um servidor com CPU a 100% vai enfileirar requisições e aumentar o TTFB drasticamente.
3. Verifique o slow query log do banco de dados: consultas lentas são uma das causas mais comuns de TTFB alto em aplicações WordPress e PHP.
4. Cheque o status do PHP-FPM: um pool esgotado é silencioso nos logs padrão, mas devastador para o TTFB.

Para ativar o log de tempo de resposta no Nginx, edite o arquivo de configuração principal:

nano /etc/nginx/nginx.conf

Adicione ou modifique o bloco log_format:

log_format detailed '$remote_addr - $remote_user [$time_local] '
                    '"$request" $status $body_bytes_sent '
                    'rt=$request_time uct=$upstream_connect_time '
                    'uht=$upstream_header_time urt=$upstream_response_time';

access_log /var/log/nginx/access.log detailed;

Após recarregar o Nginx (nginx -s reload), analise o log:

tail -f /var/log/nginx/access.log | grep -E "urt=[0-9.]+"

Valores de urt (upstream response time) acima de 0.5s indicam que o PHP-FPM ou o banco de dados está lento. Valores de rt muito maiores que urt indicam overhead no próprio Nginx ou na rede.

Ajustando PHP-FPM para reduzir TTFB em aplicações PHP

O PHP-FPM é frequentemente o maior responsável por TTFB alto em sites WordPress, Laravel e outras aplicações PHP. Quando o pool de workers está esgotado, novas requisições ficam aguardando na fila — e cada milissegundo de espera aparece diretamente no TTFB.

Localize o arquivo de pool do PHP-FPM. No Debian 12 e Ubuntu 24.04 com PHP 8.3:

nano /etc/php/8.3/fpm/pool.d/www.conf

Ajuste os parâmetros conforme a memória disponível no servidor:

; Modo dinâmico — recomendado para a maioria dos casos
pm = dynamic

; Número máximo de processos filhos
; Regra geral: (RAM disponível para PHP) / (memória média por processo)
; Ex: 2GB para PHP / 50MB por processo = 40 workers
pm.max_children = 40

; Processos iniciados junto com o servidor
pm.start_servers = 10

; Mínimo de processos ociosos mantidos
pm.min_spare_servers = 5

; Máximo de processos ociosos mantidos
pm.max_spare_servers = 20

; Reinicia workers após X requisições (evita memory leaks)
pm.max_requests = 500

Para verificar a memória média consumida por cada processo PHP-FPM em execução:

ps --no-headers -o "rss,cmd" -C php-fpm8.3 | awk '{ sum+=$1 } END { printf "Média: %.0f MB\n", sum/NR/1024 }'

Média: 48 MB

Após ajustar, reinicie o PHP-FPM:

systemctl restart php8.3-fpm

Para monitorar o status do pool em tempo real, ative o endpoint de status no arquivo de pool:

pm.status_path = /status

E configure o Nginx para expor esse endpoint apenas localmente:

location /status {
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    include fastcgi_params;
    allow 127.0.0.1;
    deny all;
}

Acesse com curl http://127.0.0.1/status e observe o campo listen queue. Se ele for maior que zero com frequência, você precisa aumentar pm.max_children.

Cache de página com Nginx FastCGI Cache para TTFB abaixo de 50ms

O cache de página é a intervenção mais impactante para reduzir TTFB, pois elimina completamente o processamento PHP e as consultas ao banco de dados para requisições repetidas. Com Nginx FastCGI Cache configurado corretamente, o servidor entrega HTML pré-gerado diretamente da memória ou disco, reduzindo o TTFB para menos de 50ms em muitos casos.

Adicione a configuração de cache no bloco http do Nginx (fora do bloco server):

fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=WORDPRESS:100m inactive=60m max_size=1g;
fastcgi_cache_key "$scheme$request_method$host$request_uri";

Dentro do bloco server do seu site, adicione as regras de cache:

set $skip_cache 0;

# Não cachear requisições POST
if ($request_method = POST) { set $skip_cache 1; }

# Não cachear URLs com query string
if ($query_string != "") { set $skip_cache 1; }

# Não cachear páginas administrativas do WordPress
if ($request_uri ~* "/wp-admin/|/xmlrpc.php|wp-.*.php|/feed/|index.php|sitemap") {
    set $skip_cache 1;
}

# Não cachear usuários logados ou com carrinho ativo
if ($http_cookie ~* "comment_author|wordpress_[a-f0-9]+|wp-postpass|wordpress_no_cache|wordpress_logged_in|woocommerce_cart_hash") {
    set $skip_cache 1;
}

location ~ \.php$ {
    fastcgi_pass unix:/run/php/php8.3-fpm.sock;
    fastcgi_index index.php;
    include fastcgi_params;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;

    fastcgi_cache WORDPRESS;
    fastcgi_cache_valid 200 60m;
    fastcgi_cache_bypass $skip_cache;
    fastcgi_no_cache $skip_cache;

    add_header X-FastCGI-Cache $upstream_cache_status;
}

Após recarregar o Nginx, faça duas requisições ao seu site e verifique o header de cache:

curl -I https://seudominio.com | grep X-FastCGI-Cache

X-FastCGI-Cache: MISS   # primeira requisição — gerou o cache
X-FastCGI-Cache: HIT    # segunda requisição — serviu do cache

Na segunda requisição com HIT, meça o TTFB novamente com curl. É comum ver valores entre 10ms e 50ms — uma redução de 90% ou mais em relação ao TTFB sem cache.

Otimizando o banco de dados para reduzir latência de resposta

Consultas lentas ao banco de dados são uma causa silenciosa de latência de resposta do servidor. Mesmo com PHP-FPM bem configurado, se cada requisição dispara queries que demoram 300ms, o TTFB nunca vai ser bom. Ative o slow query log no MariaDB 11.4 para identificar os culpados:

nano /etc/mysql/mariadb.conf.d/50-server.cnf

Adicione ou descomente as linhas:

slow_query_log = 1
slow_query_log_file = /var/log/mysql/slow.log
long_query_time = 0.5
log_queries_not_using_indexes = 1

Reinicie o MariaDB:

systemctl restart mariadb

Após alguns minutos de tráfego, analise as queries mais lentas:

mysqldumpslow -s t -t 10 /var/log/mysql/slow.log

Para cada query lenta identificada, use EXPLAIN no cliente MySQL para verificar se está usando índices:

EXPLAIN SELECT * FROM wp_posts WHERE post_status = 'publish' ORDER BY post_date DESC LIMIT 10;

Se a coluna type mostrar ALL (full table scan), adicione um índice composto:

ALTER TABLE wp_posts ADD INDEX idx_status_date (post_status, post_date);

Além dos índices, ajuste os parâmetros de buffer do MariaDB no mesmo arquivo de configuração:

innodb_buffer_pool_size = 512M    # 50-70% da RAM disponível para banco de dados
innodb_log_file_size = 128M
query_cache_type = 0              # desative query cache no MariaDB 10.4+ (deprecated)
innodb_flush_log_at_trx_commit = 2  # melhora performance em troca de durabilidade mínima

Problemas comuns e como resolver

Sintoma: TTFB alto apenas na primeira requisição, normal nas seguintes

Causa: O PHP-FPM está configurado com pm = ondemand, que mata processos ociosos e precisa inicializá-los novamente a cada nova requisição após um período de inatividade. Isso causa um "cold start" que pode adicionar 200ms a 500ms ao TTFB.
Solução: Mude para pm = dynamic e configure pm.min_spare_servers com pelo menos 2-5 processos sempre ativos. Isso garante que sempre haverá workers prontos para responder sem overhead de inicialização.

Sintoma: TTFB consistentemente alto mesmo com cache ativo

Causa: O cache pode estar sendo invalidado com frequência por plugins, cron jobs ou requisições com cookies que ativam a regra $skip_cache = 1. Outra causa comum é o diretório de cache cheio ou com permissões incorretas.
Solução: Verifique se o header X-FastCGI-Cache está retornando HIT ou BYPASS. Se for BYPASS, revise as condições de skip_cache. Verifique o espaço em disco com df -h /var/cache/nginx e as permissões com ls -la /var/cache/nginx. O diretório deve pertencer ao usuário www-data (Debian/Ubuntu) ou nginx (Rocky/AlmaLinux).

Sintoma: TTFB alto apenas para usuários geograficamente distantes

Causa: A latência de rede (RTT — Round Trip Time) entre o usuário e o servidor é alta. Isso não é um problema de configuração do servidor em si, mas de distância física. Um servidor no Brasil terá TTFB naturalmente mais alto para usuários na Europa ou Ásia.
Solução: Implemente uma CDN (Content Delivery Network) para servir conteúdo estático a partir de pontos de presença próximos aos usuários. Para conteúdo dinâmico, considere usar um servidor em região mais próxima do público-alvo. Verifique o RTT com ping seudominio.com a partir de diferentes localizações usando ferramentas como o WebPageTest com múltiplas localizações de teste.

Sintoma: TTFB aumenta progressivamente ao longo do dia

Causa: Memory leak em processos PHP-FPM ou no banco de dados. Processos que consomem memória progressivamente forçam o sistema operacional a usar swap, o que degrada drasticamente a performance de I/O e aumenta o TTFB.
Solução: Configure pm.max_requests = 500 no pool do PHP-FPM para reiniciar workers após 500 requisições, prevenindo acúmulo de memória. Monitore o uso de memória com free -h e vmstat 1 10. Se o swap estiver sendo usado, o servidor precisa de mais RAM ou de otimização de plugins/código.

Perguntas frequentes sobre TTFB

O que é TTFB e por que ele importa para SEO?

TTFB (Time to First Byte) é o tempo que o navegador leva para receber o primeiro byte de resposta do servidor após enviar uma requisição HTTP. Um TTFB alto indica lentidão no servidor, banco de dados ou rede, e o Google usa métricas de velocidade como parte do ranking — valores acima de 800ms são considerados ruins pelo Core Web Vitals. Sites com TTFB elevado tendem a ter maior taxa de rejeição, o que reforça o sinal negativo para o algoritmo de busca.

Qual é um valor de TTFB considerado bom?

O Google recomenda TTFB abaixo de 200ms para uma experiência excelente. Valores entre 200ms e 500ms são aceitáveis, enquanto acima de 800ms indicam problemas sérios de performance no servidor ou na aplicação. Ferramentas como WebPageTest e curl permitem medir o TTFB real do seu servidor, separando o tempo de DNS, TLS e processamento do servidor.

Como medir o TTFB do meu servidor Linux?

Você pode medir o TTFB diretamente pelo terminal com o comando curl -o /dev/null -s -w 'TTFB: %{time_starttransfer}s\n' https://seudominio.com. Ferramentas online como WebPageTest.org e GTmetrix também exibem o TTFB separado do tempo total de carregamento, permitindo identificar se o problema está no servidor ou nos recursos da página. Execute o teste pelo menos três vezes para obter uma média confiável.

PHP-FPM influencia o TTFB?

Sim, diretamente. Quando o pool de workers do PHP-FPM está esgotado, novas requisições ficam na fila aguardando um processo livre, o que aumenta o TTFB drasticamente. Ajustar pm.max_children, pm.start_servers e pm.max_spare_servers no arquivo de pool do PHP-FPM reduz esse gargalo. Monitorar o endpoint /status do PHP-FPM ajuda a identificar quando o pool está saturado.

Cache de página resolve TTFB alto?

Cache de página é uma das formas mais eficazes de reduzir TTFB, pois elimina o processamento PHP e consultas ao banco de dados para requisições repetidas. Com Nginx FastCGI Cache ou Redis como cache de objetos, o servidor entrega HTML pré-gerado em memória, reduzindo o TTFB para menos de 50ms em muitos casos. É importante configurar corretamente as regras de bypass para não cachear páginas de usuários logados ou carrinho de compras.

Conclusão

• Meça antes de otimizar: use curl com %{time_starttransfer} para ter uma linha de base real e identificar se o gargalo está no DNS, TLS, PHP-FPM ou banco de dados antes de fazer qualquer mudança.
• Implemente cache de página: Nginx FastCGI Cache é a intervenção de maior impacto — pode reduzir o TTFB de 400ms para menos de 50ms para requisições repetidas, sem necessidade de hardware adicional.
• Ajuste PHP-FPM e banco de dados: configure pm.max_children com base na memória real disponível, ative o slow query log do MariaDB e adicione índices nas colunas mais consultadas para eliminar full table scans.

Leia também

• Entenda o que é Swap no Linux: como funciona e quando usar
• Otimizar cache Redis para aplicações PHP no Ubuntu 22.04
• Guia Definitivo: Configurar Nginx como Proxy Reverso

Precisa de ajuda com performance do servidor?

Otimizar TTFB exige acesso ao servidor, conhecimento da pilha de software e tempo para diagnosticar cada camada. Um servidor VPS bem configurado com Nginx, PHP-FPM e cache adequado pode entregar TTFB consistentemente abaixo de 200ms mesmo sob carga. Confira as opções de infraestrutura da AviraHost para encontrar o plano certo para o seu projeto.

Ver planos de VPS na AviraHost