O TTFB (Time to First Byte) é o tempo entre o início da navegação e a chegada do primeiro byte da resposta HTML. Ele não é um Core Web Vital, mas é a primeira parte do LCP: nada renderiza antes de o HTML chegar. O web.dev considera bom um valor de até 0,8 segundo. Para reduzir o TTFB no WordPress, entregue HTML do cache de página ou do edge cache, adicione um object cache persistente (Redis ou Memcached) para o que não pode ir para o cache, rode uma versão do PHP com suporte e OPcache, enxugue as options em autoload e as queries lentas, e garanta que cookies e query strings não furem o cache.
O TTFB é por onde começo toda auditoria de WordPress, mesmo o Google não dando nota para ele, porque um servidor lento diminui o efeito de todas as outras correções. Uma página com 1,8 segundo de TTFB tem 0,7 segundo para baixar e renderizar o elemento LCP antes de estourar o limite de 2,5 segundos. Para entender como o TTFB se encaixa nos três Core Web Vitals, veja Core Web Vitals no WordPress: o guia completo.
O que entra no TTFB?
O TTFB é mais que tempo de servidor. Ele cobre tudo o que acontece antes do primeiro byte:
- redirecionamentos, como de
httpparahttpsou por falta da barra no final da URL - inicialização do service worker, se o site tiver um
- consulta de DNS
- conexão TCP e negociação TLS
- o caminho da requisição até o servidor, e o processamento no servidor até o primeiro byte sair
Então um servidor rápido ainda pode ter TTFB ruim nos dados de campo quando os visitantes estão longe dele, ou quando os links de campanha passam por dois redirecionamentos. O web.dev publica estes limites para o TTFB, medidos no percentil 75:
| Classificação | TTFB |
|---|---|
| Bom | ≤ 0,8 s |
| Precisa melhorar | 0,8 s a 1,8 s |
| Ruim | > 1,8 s |
São valores de referência, não fazem parte da avaliação de Core Web Vitals.
Por que o TTFB não é um Core Web Vital?
Para o Google, o TTFB é uma métrica de diagnóstico. Os sites são construídos de formas diferentes: uma página WordPress renderizada no servidor e uma aplicação renderizada no cliente podem chegar ao mesmo LCP com TTFBs bem diferentes, e um TTFB rápido seguido de uma renderização lenta continua sendo uma página lenta. Por isso o Google dá nota para o que o visitante vê (LCP, INP e CLS) e deixa o TTFB como uma forma de explicar essas métricas.
No WordPress, porém, o HTML normalmente traz tudo o que a primeira tela precisa, então o TTFB se reflete quase direto no LCP. Quando vejo um site WordPress com LCP ruim e TTFB acima de um segundo, o servidor é a primeira coisa que corrijo. O trabalho com imagens de como melhorar o LCP no WordPress vem depois.
Onde o WordPress gasta tempo antes do primeiro byte?
Numa requisição sem cache, o PHP carrega o core do WordPress, carrega todos os plugins ativos e o tema, lê todas as options em autoload da wp_options, roda as queries da página, renderiza o template e só então começa a enviar o HTML. Cada plugin soma tempo nesse processo, mesmo em páginas onde ele não faz nada visível.
| Causa | Como verificar | Correção |
|---|---|---|
| Sem cache de página | Headers de resposta como x-cache ou cf-cache-status, requisições repetidas com o mesmo TTFB | Cache de página no servidor (Nginx FastCGI cache, Varnish, LiteSpeed) ou um plugin de cache |
| Cache furado por query strings | Compare o TTFB com e sem ?utm_source=test | Ignore parâmetros de marketing como utm_*, gclid e fbclid na chave do cache |
| Cache furado por cookies | Teste como visitante anônimo depois de adicionar um produto ao carrinho | Faça bypass só dos cookies que realmente personalizam a página |
| Sem object cache persistente | O Site Health sugere um em sites maiores que não têm | Redis ou Memcached com um drop-in object-cache.php |
| Options grandes em autoload | O Site Health avisa sobre autoload grande desde o WordPress 6.6 | Pare de carregar em autoload as options que não são necessárias em toda requisição, limpe as sobras de plugins removidos |
| Queries lentas de plugin | Query Monitor, slow query log | Corrija ou troque o plugin, crie os índices que faltam |
| Chamadas externas bloqueando a renderização | Painel de chamadas da HTTP API no Query Monitor | Guarde as respostas remotas em transients, mova as chamadas para o cron |
| PHP antigo ou sem OPcache | Site Health, phpinfo() | Versão do PHP com suporte, OPcache ativo e dimensionado para o código |
| Poucos PHP workers | O TTFB sobe junto com o tráfego, as requisições entram em fila | Ajuste a quantidade de workers do PHP-FPM à memória e à CPU do servidor |
| Servidor longe dos visitantes | TTFB de campo muito pior que o TTFB medido perto do servidor | Cache do HTML na borda com uma CDN |
A linha das query strings costuma surpreender. Todo clique em anúncio chega com um gclid ou fbclid único, e muitos caches de página tratam cada um como uma URL nova. Ou seja, justamente os visitantes pelos quais você paga recebem a versão sem cache, a mais lenta da página.
Cache de página, object cache ou edge cache?
Cada um resolve uma parte diferente do TTFB. O cache de página guarda o HTML completo, então visitantes anônimos pulam o PHP e o banco de dados por inteiro. O object cache persistente mantém resultados de queries e dados calculados em memória entre uma requisição e outra, o que acelera tudo o que não pode ir para o cache de página: usuários logados, carrinho e checkout do WooCommerce, o painel. O edge cache guarda o HTML em pontos da CDN perto do visitante, o que também elimina boa parte da distância de rede.
A maioria dos sites WordPress precisa primeiro de um cache de página. Lojas e sites de membros também precisam do object cache, porque uma parte grande do tráfego deles não pode ir para o cache. Comparo os três em page cache vs object cache vs edge cache: qual você precisa.
Como medir o TTFB no WordPress?
- O PageSpeed Insights mostra o TTFB dos dados de campo do CrUX na seção de campo, ao lado dos Core Web Vitals.
- O Chrome DevTools mostra “Waiting for server response” na aba Timing da requisição do documento, no painel Network.
- Na linha de comando,
curl -o /dev/null -s -w "%{time_starttransfer}\n" https://example.com/imprime o TTFB em segundos. Rode várias vezes, e também com query string, para ver respostas com e sem cache. - O Site Health, desde o WordPress 6.1, verifica se há um cache de página detectado e informa o tempo de resposta do servidor.
- Um header de resposta
Server-Timingdeixa o servidor informar as próprias fases (PHP, banco, cache), e o DevTools mostra esses dados ao lado da requisição.
Meça de onde seus visitantes estão. Um teste feito de um data center ao lado do seu servidor diz pouco sobre um visitante numa rede móvel em outro continente. Os dados de campo cobrem isso, e por isso explico a diferença entre dados de campo e de laboratório antes de alguém começar a mexer em servidor.
Qual TTFB um site WordPress deve buscar?
Busque 0,8 segundo ou menos no percentil 75 dos dados de campo, no mobile. Uma página em cache servida da borda deve ficar bem abaixo disso. Se as páginas em cache são rápidas e o número de campo continua ruim, olhe os redirecionamentos, a taxa de acerto do cache e a fatia do tráfego que fura o cache. Se as páginas sem cache são lentas, o trabalho está no PHP, no banco de dados e nos plugins.
Ajuste de servidor muitas vezes é trabalho de quem cuida da infraestrutura. Quando o cliente precisa que a implementação seja feita, o time da WebOption cuida disso dentro do serviço de performance e segurança para WordPress.
Quer saber para onde vai o seu TTFB?
Se a resposta do seu servidor é lenta e você não sabe se o problema é a hospedagem, o cache, o banco de dados ou um plugin, eu descubro e digo o que mudar primeiro. Conheça minhas auditorias de Core Web Vitals e de performance WordPress.