O TTFB é o tempo entre a requisição e o primeiro byte do servidor, e reduzi-lo exige atacar hospedagem, PHP e cache antes de qualquer plugin. Segundo o web.dev (2024), um TTFB bom fica abaixo de 0,8 s (800 ms). Acima de 1.000 ms, o LCP estoura e o crawler penaliza. Comece medindo a origem, não o cache.

O TTFB no WordPress mede quanto o servidor demora para devolver o primeiro byte de uma página, e ele é o piso de toda métrica de velocidade: nenhum truque de front-end compensa uma origem lenta. Um valor saudável fica abaixo de 800 ms, mas em hospedagem compartilhada com PHP antigo é comum ver 1.500 ms ou mais. Este tutorial mostra como medir e reduzir o TTFB em seis frentes técnicas, da hospedagem ao banco de dados, com os mesmos diagnósticos que a gente aplica no suporte da FULL. Para o contexto completo de métricas, vale ler também os conteúdos de performance WordPress da FULL.

Primeiros passos: O que o TTFB realmente mede

O TTFB soma três tempos antes de qualquer pixel aparecer: resolução de DNS e roteamento até a CDN, processamento do servidor com PHP mais banco, e o envio do primeiro byte. Em 2026, o número que pesa é o tempo de servidor: ele costuma passar de 70% do TTFB total num site sem cache de origem.

Medir a frente errada faz você otimizar imagem enquanto o gargalo está no PHP. Por isso o diagnóstico começa separando rede de processamento antes de mexer em qualquer plugin.

A regra de leitura da tabela: comece de cima. Se o tempo de resposta está alto mesmo em uma página cacheada, o problema é a origem, e nenhum plugin resolve. Esse é o erro número um que aparece nos tickets da FULL.

Por que o TTFB continua alto mesmo com plugin de cache

Um TTFB que só cai no cache hit e dispara no cache miss é o sintoma mais comum de origem fraca: o plugin entrega HTML pronto para o visitante repetido, mas o Googlebot bate em URLs fora do cache. PHP 7.4 sem OPcache, com um tema de dezenas de queries por requisição, produz TTFB acima de 1 s mesmo com o WP Rocket ativo.

O cache mascara o número no seu navegador e esconde o problema do mecanismo de busca, porque a primeira visita ainda processa tudo do zero.

A solução começa por enxergar o estado real. Rode o PageSpeed Insights e olhe o campo “Response time” do servidor, não só a nota. No suporte, a gente vê site com cache marcando tempo excelente no teste manual e péssimo nos dados de campo, porque o Chrome UX Report agrega visitas reais sem cache. Antes de instalar mais um plugin, confirme se o gargalo é o WordPress e não a camada de cache de página dando falso positivo.

Frente 1: Hospedagem define o piso do TTFB

A hospedagem é o teto e o piso do TTFB porque o tempo de servidor nasce nela: em hospedagem compartilhada saturada, o PHP-FPM divide poucos workers entre dezenas de sites e o TTFB sobe em rajada nos picos. Migrar para origem gerenciada costuma derrubar o tempo de resposta de 1.200 ms para abaixo de 400 ms.

A origem compete por TTFB; a CDN só acelera a borda. Esse ganho de migração aparece sem tocar uma linha de código, segundo benchmarks públicos de provedores gerenciados.

Aqui entra um detalhe de produção que documentação nenhuma traz: em PHP-FPM limitado a poucos workers, o TTFB explode quando o crawler do Google requisita várias URLs não cacheadas em paralelo. Aumentar o pm.max_children sem RAM disponível só troca tempo de resposta alto por erro 502. A correção honesta é dimensionar a origem, não forçar o pool. Se você avalia trocar de plano, o comparativo de versões de PHP no WordPress separa o que é hospedagem do que é configuração de runtime.

Frente 2: PHP 8.3 e opcache cortam o tempo de servidor

Subir o PHP é a otimização de maior retorno por minuto investido: a passagem de PHP 7.4 para PHP 8.3 costuma reduzir o tempo de processamento entre 20% e 40% no mesmo hardware, e o OPcache evita recompilar scripts a cada requisição. Isso entra direto no TTFB.

Num site sem OPcache, cada page load reinterpreta milhares de linhas de PHP. É o tipo de ganho que aparece no número do servidor antes mesmo de mexer no cache.

O OPcache guarda o bytecode compilado na memória, então o segundo acesso a qualquer arquivo PHP pula a etapa de parsing. Confirme a versão em Ferramentas → Saúde do site e o status do OPcache via phpinfo(). Boa parte dos sites lentos que chegam no suporte da FULL ainda roda PHP 7.x por inércia do painel da hospedagem. A configuração padrão de muitos provedores deixa o OPcache desligado, e ativá-lo é uma das poucas mudanças que melhora o tempo de servidor sem efeito colateral conhecido.

Frente 3: Cache de página para o visitante anônimo

O cache de página resolve o TTFB para quem importa no SEO: o visitante anônimo e o crawler, que recebem HTML estático sem passar pelo PHP. Com cache bem configurado, o TTFB de uma página cacheada cai para a faixa de 100 a 300 ms, porque o servidor só lê um arquivo do disco.

O risco é cachear o que não deve: carrinho do WooCommerce e área logada precisam de exclusão explícita para não vazar sessão de um usuário para outro.

Passo a passo: Configurar cache de página sem quebrar a loja

Passo 1: ative o cache para visitantes anônimos

Comece pelo essencial. Ative o cache de página no plugin de cache do WordPress escolhido, mantendo o padrão de não cachear usuários logados. Isso já cobre a maior parte do tráfego de busca, que chega deslogado.

Passo 2: exclua carrinho, checkout e conta

Adicione as páginas dinâmicas à lista de exclusão. No WooCommerce, cachear o carrinho sem exclusão faz um cliente ver o carrinho de outro usuário. Exclua cart, checkout e my-account antes de subir para produção.

Passo 3: valide o TTFB no cache miss

Limpe o cache e meça a primeira visita. Esse é o número que o Googlebot enxerga. Se o TTFB no cache miss continua acima de 800 ms, o problema voltou para a origem, não para o plugin.

Frente 4: CDN reduz a latência de borda do TTFB

A CDN ataca a parte do TTFB que vem da distância física entre usuário e servidor: para um visitante em Recife acessando um servidor em Virginia, a latência de rede sozinha pode somar 200 ms ao TTFB. Uma borda com ponto de presença em São Paulo serve o HTML a poucos milissegundos do usuário brasileiro.

A CDN não conserta origem lenta, mas elimina a latência geográfica que infla o número de rede.

O Cloudflare e o LiteSpeed cobrem cenários diferentes: o Cloudflare entrega cache de borda e DNS rápido em rede global, enquanto o LiteSpeed integra o cache no nível do servidor quando a hospedagem usa esse stack. De acordo com a telemetria pública do Cloudflare, que monitora a latência global de requisições, o Brasil tem PoPs em São Paulo, Rio de Janeiro e Fortaleza, o que reduz o salto de rede. Para a montagem prática, o guia de como configurar uma CDN no WordPress cobre o apontamento de DNS sem derrubar o site.

Frente 5: Banco de dados e object cache

O banco de dados vira o gargalo do TTFB em sites dinâmicos: cada requisição do WooCommerce pode disparar dezenas de queries, e sem reuso elas processam de novo a cada visita. O Redis Object Cache guarda o resultado dessas queries na memória e corta o tempo de servidor onde o cache de página não se aplica.

Em catálogos grandes, esse reuso é o que separa um TTFB de 400 ms de um de 1.200 ms em lojas e sites de associação.

Sem Redis, o WordPress usa object cache em disco, que não persiste entre requisições e força o banco a responder cada chamada do zero. Ativar o cache de objeto com Redis resolve isso na maioria dos cenários com banco pesado. Use o guia de otimização do developer.WordPress.org para identificar plugins que abusam de queries; a documentação oficial lista os padrões que mais inflam o tempo de resposta. O object cache só compensa quando o gargalo é mesmo o banco, não a hospedagem.

Frente 6: Meça com as ferramentas certas

Medir o TTFB com a ferramenta errada leva a otimizar o lugar errado: o PageSpeed Insights mostra o tempo de campo agregado, o GTmetrix faz uma medição sintética de um PoP, e o Query Monitor revela quais queries inflam o servidor. Cada um vê uma fatia diferente do TTFB.

Use os três juntos. Confiar só na nota de uma ferramenta esconde de qual frente o problema vem.

O Query Monitor é o que mais ajuda no diagnóstico de origem: ele lista cada query, o tempo de cada uma e o plugin que a disparou, expondo o que aparece como TTFB alto sem causa visível. Em ambientes que a gente acompanha, um único plugin mal escrito costuma responder por metade do tempo de banco. Combine essa medição com os Core Web Vitals do WordPress e com a relação entre TTFB e LCP no WordPress, já que um TTFB alto empurra o LCP para a zona vermelha de forma direta.

Acelere o WordPress com o bundle da FULL

Reduzir o TTFB com ferramentas avulsas custa caro quando você soma WP Rocket, um plugin de object cache e a licença de cada extra por site. No plano PRO da FULL, por R$849 ao ano para até dez sites, sai a R$85 por site com o WP Rocket e o pacote de performance incluídos, ativados em um clique. A gente vê no suporte que juntar cache, OPcache e CDN no mesmo painel evita o conflito de configuração que sozinho já infla o TTFB. Compare os planos em FULL.services/planos e ative o WP Rocket pela FULL sem licença separada.

Legenda: o gráfico comprova que o ganho de TTFB aparece no tempo de servidor, não no front-end.

Perguntas frequentes sobre TTFB no WordPress

Próximos passos para domar o TTFB do seu site

Domar o TTFB do WordPress é uma sequência clara: medir a origem, subir o PHP, ativar cache de página, plugar a CDN e só então afinar o banco. A ordem importa porque cada frente esconde a anterior, e atacar fora de ordem faz você otimizar o sintoma errado. Comece pelo PageSpeed Insights no cache miss, confirme se o gargalo é a hospedagem e siga frente por frente até o TTFB cair abaixo de 800 ms de forma consistente, inclusive para o crawler.

Para continuar aprendendo, o guia Acelere o WordPress da FULL reúne os tutoriais de performance em uma trilha única, e o FULL Academy organiza todo o material por nível. Com a origem saudável e o cache certo, o TTFB deixa de ser o gargalo e o site passa a competir por velocidade real de página.