Reduzir o TTFB (Time To First Byte) significa fazer o servidor começar a responder mais rápido à requisição do usuário. Em um cenário VPS, WordPress, Apache + Nginx (proxy reverso), PHP-FPM, MariaDB e CloudLinux, vou focar no que realmente dá resultado nesse cenário.
1️⃣ Identifique onde está o gargalo (passo obrigatório)
Antes de otimizar “no escuro”, confirme onde o tempo está sendo gasto:
Ferramentas úteis
- Chrome DevTools → Network → TTFB
- GTmetrix / WebPageTest
- curl
curl -o /dev/null -s -w 'TTFB: %{time_starttransfer}\n' https://seudominio.com
Se o TTFB for:
- 🔹 < 200ms → excelente
- 🔹 200–500ms → aceitável
- 🔹 > 500ms → precisa otimizar
- 🔹 > 1s → problema sério
2️⃣ Ative cache agressivo no Nginx (impacto imediato)
Se você usa Nginx como proxy reverso, esse é o ponto mais importante.
Cache FastCGI no Nginx
fastcgi_cache_path /var/cache/nginx levels=1:2 keys_zone=WORDPRESS:100m inactive=60m;
fastcgi_cache_key "$scheme$request_method$host$request_uri";
server {
set $skip_cache 0;
if ($request_method = POST) {
set $skip_cache 1;
}
if ($query_string != "") {
set $skip_cache 1;
}
location ~ \.php$ {
fastcgi_cache WORDPRESS;
fastcgi_cache_valid 200 301 302 60m;
fastcgi_cache_use_stale error timeout updating;
fastcgi_cache_bypass $skip_cache;
fastcgi_no_cache $skip_cache;
}
}
📉 Redução típica de TTFB: de 600–1200ms → 50–120ms
3️⃣ PHP-FPM bem dimensionado (evita fila de requisições)
Clique aqui e veja PHP-FPM: Como Calcular pm.max_children Corretamente
Exemplo (php-fpm.conf)
pm = dynamic pm.max_children = 200 pm.start_servers = 20 pm.min_spare_servers = 10 pm.max_spare_servers = 30 pm.max_requests = 500
⚠️ Evite pm = ondemand em sites com tráfego constante → ele aumenta o TTFB.
4️⃣ OPcache bem configurado (obrigatório para WordPress)
Sem OPcache o PHP recompila scripts a cada request.
opcache.enable=1 opcache.memory_consumption=512 opcache.interned_strings_buffer=64 opcache.max_accelerated_files=200000 opcache.validate_timestamps=0 opcache.fast_shutdown=1
📉 Redução típica: 100–300ms no TTFB
5️⃣ Banco de dados rápido = TTFB baixo
Com MariaDB 11.x, foque em buffer e I/O.
Ajustes essenciais (my.cnf)
innodb_buffer_pool_size = 6G innodb_buffer_pool_instances = 6 innodb_log_file_size = 1G innodb_flush_log_at_trx_commit = 2 innodb_io_capacity = 2000 innodb_io_capacity_max = 4000
🔍 Use:
SHOW GLOBAL STATUS LIKE 'Innodb_buffer_pool_reads';
Se esse número sobe rápido → buffer pool pequeno demais.
6️⃣ Reduza plugins e consultas no WordPress
Cada plugin:
- adiciona hooks
- executa consultas
- aumenta o tempo até o primeiro byte
Ferramentas
- Query Monitor
- New Relic APM
Remova:
- plugins de estatística internos
- plugins duplicados de cache/SEO
- page builders pesados em páginas simples
7️⃣ CloudLinux: evite throttling invisível
No CloudLinux, limites mal definidos causam TTFB instável.
Verifique LVE
lveinfo --period=5m
Aumente:
- CPU
- PMEM
- IO
Para contas WordPress de produção, valores baixos = TTFB alto.
8️⃣ Use CDN corretamente (não só para imagens)
Ative:
- HTML caching
- Full Page Cache
- HTTP/3 + QUIC
Cloudflare / Bunny / Fastly:
- TTFB cai drasticamente para visitantes distantes do servidor
9️⃣ Use HTTP/2 ou HTTP/3
Confirme:
curl -I --http2 https://seudominio.com
Se não estiver ativo:
- TTFB lógico não muda muito
- mas o TTFB percebido melhora bastante
🔟 Checklist rápido (ordem de impacto)
1️⃣ Cache no Nginx
2️⃣ PHP-FPM bem dimensionado
3️⃣ OPcache ajustado
4️⃣ Banco de dados otimizado
5️⃣ Plugins e queries do WordPress
6️⃣ CloudLinux sem throttling
7️⃣ CDN + HTTP/3
Clique aqui e consulte nossos planos de Gerenciamento de Servidor
Veja Mais: Como Usar htop, iotop e Glances para Diagnóstico Rápido de Servidores Linux
Veja Mais: Segurança no WordPress em nível de servidor
Veja Mais: Como configurar lemp com wordpress e let´s encrypt
Veja Mais: O que ninguém te conta sobre gerenciar servidores em produção
Veja Mais: Guia Completo do DirectAdmin para Administradores | Instalação, Segurança e Performance