Não julgue por sensação.

Abra as ferramentas de desenvolvedor no navegador, vá em Network, recarregue a página e veja o Timing da requisição HTML principal.

Preste atenção em:

Se o lento for Content Download, pode ser que a página esteja grande demais, as imagens grandes demais ou a banda lenta.

Se o lento for Waiting for server response, esse é o problema de TTFB que este artigo trata.

Também dá para medir com um comando:

curl -o /dev/null -s -w 'dns:%{time_namelookup}\nconnect:%{time_connect}\ntls:%{time_appconnect}\nttfb:%{time_starttransfer}\ntotal:%{time_total}\n' https://example.com/

A saída pode ser:

dns:0.012
connect:0.080
tls:0.160
ttfb:2.431
total:2.620

Isso deixa claro: o que realmente está lento é o primeiro byte, não o download.

TTFB alto não significa necessariamente que o servidor está lento; também pode ser um problema de rota de rede.

Teste de pelo menos dois lugares:

curl -o /dev/null -s -w '%{time_starttransfer}\n' https://example.com/

Você pode testar de:

• Seu computador local
• O próprio VPS
• Um servidor em outra região
• O painel do Cloudflare / WebPageTest / PageSpeed Insights

Se o próprio VPS acessa rápido:

curl -o /dev/null -s -w '%{time_starttransfer}\n' http://127.0.0.1/

Mas o seu acesso local está lento, pode ser:

• Resolução DNS lenta
• Rota de rede transfronteiriça lenta
• Busca na origem do nó CDN lenta
• Instabilidade de rede no horário de pico

Se o próprio VPS também está lento, o problema provavelmente está na aplicação, no Nginx, no banco de dados ou nos recursos da máquina.

Para questões de horário de pico, veja: Por que o VPS fica lento no horário de pico.

Se você usa Cloudflare ou outro CDN, não culpe a origem de imediato.

Teste dois caminhos separadamente:

1. O usuário acessa o CDN
2. O CDN busca na origem no VPS

Se o domínio passa pelo Cloudflare, você pode testar temporariamente com o IP da origem:

curl -H 'Host: example.com' -o /dev/null -s -w 'ttfb:%{time_starttransfer} total:%{time_total}\n' http://YOUR_ORIGIN_IP/

Se a origem é rápida mas pelo Cloudflare fica lento, pode ser:

• Rota de rede lenta do nó CDN até a origem
• Regras de segurança / inspeção WAF do Cloudflare demorando
• Regras de cache que não batem
• Problemas no protocolo de origem, TLS ou configuração de redirecionamento

Se a própria origem é lenta, o CDN só está expondo a lentidão.

Para problemas de origem com Cloudflare, veja: O que fazer com Cloudflare 521 / 522 em site em VPS.

Muitas vezes você precisa saber: a lentidão está no Nginx ou na aplicação atrás do Nginx?

O log padrão do Nginx não necessariamente tem esses campos, então vale a pena adicionar temporariamente um log_format mais útil:

log_format timing '$remote_addr - $host "$request" '
                  'status=$status request_time=$request_time '
                  'upstream_response_time=$upstream_response_time '
                  'upstream_connect_time=$upstream_connect_time '
                  'upstream_header_time=$upstream_header_time';

access_log /var/log/nginx/access_timing.log timing;

Verifique a configuração:

nginx -t
systemctl reload nginx

Depois acesse a página algumas vezes e olhe de novo:

tail -f /var/log/nginx/access_timing.log

Você pode ver:

status=200 request_time=2.845 upstream_response_time=2.801 upstream_header_time=2.801

Isso significa que a maior parte do tempo é gasta na aplicação upstream.

Se for:

request_time=2.800 upstream_response_time=-

Então pode ser arquivos estáticos, o próprio Nginx processando, espera de conexão ou outros problemas de configuração.

Para erros de configuração do Nginx, veja: O que fazer com erros de configuração do Nginx no VPS.

Se você roda um site PHP como WordPress, Laravel ou Typecho, o TTFB alto costuma vir do PHP-FPM.

Primeiro veja o status do serviço:

systemctl status php8.2-fpm

Veja os logs:

journalctl -u php8.2-fpm -n 100 --no-pager

Ajuste o número da versão conforme o seu sistema, por exemplo php8.1-fpm, php8.3-fpm.

Preste atenção nestes sinais:

server reached pm.max_children setting
child exited on signal
slow request
pool www seems busy

Se você vir pm.max_children no máximo, significa que não há workers PHP suficientes ou que requisições individuais estão lentas demais.

Você pode ver o número de processos:

ps aux | grep php-fpm | wc -l

Também pode ativar o slowlog do PHP-FPM:

request_slowlog_timeout = 5s
slowlog = /var/log/php-fpm/www-slow.log

Depois recarregue o PHP-FPM.

Se o seu site WordPress está lento, continue lendo: O que fazer quando o WordPress está lento no VPS.

Se a página consulta o banco de dados toda vez, um banco um pouco lento já faz o TTFB subir direto.

No MySQL / MariaDB, primeiro veja se o log de consultas lentas está ativado:

SHOW VARIABLES LIKE 'slow_query_log';
SHOW VARIABLES LIKE 'long_query_time';

Você pode ativá-lo temporariamente assim:

SET GLOBAL slow_query_log = 'ON';
SET GLOBAL long_query_time = 1;

Depois veja o local do log de consultas lentas:

SHOW VARIABLES LIKE 'slow_query_log_file';

Problemas comuns:

• Falta de índices
• Consultas duplicadas de plugins ou temas
• A página inicial consulta dados demais de uma vez
• Banco de dados e aplicação em regiões diferentes
• Pool de conexões do banco insuficiente
• Tabelas grandes demais sem paginação

Se você não quer analisar SQL agora, pelo menos veja se o banco está sob pressão:

top
iotop -o
mysqladmin processlist

O banco não conectar ou não iniciar é outro problema; veja: O que fazer quando o MySQL / MariaDB não conecta no VPS.

Muitos sites pequenos têm TTFB alto não porque a máquina é fraca, mas porque o cache não está bem configurado.

Você pode olhar primeiro os cabeçalhos de resposta:

curl -I https://example.com/

Preste atenção nestes:

cache-control
cf-cache-status
x-cache
server-timing

Se você usa Cloudflare mas as páginas HTML sempre mostram:

cf-cache-status: DYNAMIC

Isso significa que o Cloudflare não está fazendo cache do HTML e busca na origem toda vez.

Isso é normal para o painel administrativo, carrinho de compras e página de login; mas se forem páginas de conteúdo puro, páginas de blog ou páginas de documentação, você pode considerar fazer cache.

O Nginx também pode usar fastcgi_cache ou proxy_cache, mas com cuidado:

• Não faça cache de usuários logados
• Não faça cache do painel administrativo
• Não faça cache sem critério de páginas com cookies de estado do usuário
• Não faça cache de envios de formulário, pagamento ou comentário

Fazer o cache errado dá mais problema do que não fazer.

Muita gente olha o top, vê que a CPU não está alta e acha que a máquina está bem.

Mas o TTFB alto pode travar em:

• I/O de disco
• iowait
• Recuperação de memória
• Oscilação de swap
• Fila de workers do PHP-FPM
• Espera de locks do banco de dados

Veja a carga do sistema:

uptime

Veja CPU, memória, iowait:

vmstat 1

Veja o I/O de disco:

iostat -xz 1

Veja os processos:

htop

Se wa estiver alto, ou o util do disco ficar perto de 100% por muito tempo, pode ser que as requisições estejam todas esperando o disco.

Nesse caso, veja: O que fazer quando o I/O de disco do VPS está muito alto.

O TTFB é medido do início da requisição até o primeiro byte, e às vezes DNS, conexão e TLS já estão lentos antes disso.

Com curl você pode separar:

curl -o /dev/null -s -w 'dns:%{time_namelookup}\nconnect:%{time_connect}\ntls:%{time_appconnect}\nttfb:%{time_starttransfer}\ntotal:%{time_total}\n' https://example.com/

Se só o dns já leva 0,8 segundos, não é o PHP que está lento.

Se tls estiver alto, pode ser:

• Problemas na cadeia de certificados
• Vários redirecionamentos HTTPS
• Modo SSL inadequado entre origem e CDN
• Configuração anormal de HTTP/2 / HTTP/3

Verifique a cadeia de redirecionamentos:

curl -IL https://example.com/

Se aparecerem redirecionamentos de ida e volta como http -> https -> www -> sem www -> https, o TTFB também vai parecer ruim.

Para loops de redirecionamento HTTPS, veja: O que fazer com loop de redirecionamento HTTPS em site em VPS.

TTFB normal na página inicial não significa que os endpoints estejam normais.

O que realmente está lento em muitos sites é:

• /api/search
• /wp-admin/admin-ajax.php
• /api/orders
• /graphql
• Endpoint de login
• Páginas de listagem do painel administrativo

Teste cada um separadamente:

curl -o /dev/null -s -w 'ttfb:%{time_starttransfer} total:%{time_total}\n' https://example.com/api/search

Se só um endpoint está lento, não otimize o site inteiro às cegas. Verifique esse endpoint diretamente:

• Se consulta o banco demais
• Se chama APIs externas
• Se não tem cache
• Se há espera de lock
• Se está sendo limitado por rate limit ou inspecionado pelo WAF

Vi um site em que a página inicial era rápida, mas o endpoint de busca tinha TTFB de 6 segundos, e no fim cada busca fazia uma requisição em tempo real a uma API de terceiros. Por mais caro que seja o VPS para o qual você migrar, você só vai transformar 6 segundos em 5,8 segundos.

Você pode seguir esta ordem:

# 1. 拆开 DNS、连接、TLS、TTFB、总耗时
curl -o /dev/null -s -w 'dns:%{time_namelookup}\nconnect:%{time_connect}\ntls:%{time_appconnect}\nttfb:%{time_starttransfer}\ntotal:%{time_total}\n' https://example.com/

# 2. 在 VPS 本机测源站
curl -o /dev/null -s -w 'ttfb:%{time_starttransfer} total:%{time_total}\n' http://127.0.0.1/

# 3. 绕过 CDN 测源站 IP
curl -H 'Host: example.com' -o /dev/null -s -w 'ttfb:%{time_starttransfer} total:%{time_total}\n' http://YOUR_ORIGIN_IP/

# 4. 看 Nginx 访问时间字段
 tail -f /var/log/nginx/access_timing.log

# 5. 看应用日志
journalctl -u php8.2-fpm -n 100 --no-pager

# 6. 看系统资源
vmstat 1
iostat -xz 1

Depois julgue pelos resultados:

TTFB alto pode, claro, significar que a máquina é fraca demais, mas essa não é a primeira conclusão.

Casos em que faz sentido fazer upgrade da máquina:

• CPU no máximo por muito tempo
• Memória insuficiente causando swap frequente
• I/O de disco no máximo por muito tempo
• Banco de dados já otimizado mas com recursos insuficientes
• Workers do PHP-FPM ainda na fila após configuração razoável

Casos em que o upgrade não resolve:

• Um plugin escrevendo SQL lento
• Chamar uma API externa a cada requisição
• Cloudflare não fazendo cache de conteúdo estático
• Configuração errada do proxy reverso do Nginx
• Cadeia de redirecionamentos confusa
• Banco de dados sem índices

Fazer upgrade do VPS às vezes só empurra o problema para o mês seguinte. O que você realmente deve fazer é primeiro identificar em qual camada está a lentidão.

Se você está diagnosticando o TTFB do seu site, aqui estão alguns artigos para continuar lendo:

• O que fazer quando o WordPress está lento no VPS
• O que fazer com 502 / 504 Bad Gateway no VPS
• O que fazer com erros de configuração do Nginx no VPS
• O que fazer quando o I/O de disco do VPS está muito alto
• O que fazer com Cloudflare 521 / 522 em site em VPS

Por fim, o critério mais prático: se em curl o time_starttransfer estiver alto mas o time_total não for muito maior que ele, foque no backend que gera a página; se o time_starttransfer não estiver alto mas o time_total estiver, foque no tamanho do download, imagens, banda e recursos do frontend. Separe essas duas coisas primeiro e você evita a maior parte dos desvios.