# TTFB no WordPress: Como reduzir em 6 frentes 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.
TTFB no WordPress: onde o tempo se perde e como agir
Frente Sintoma típico Ação corretiva
HospedagemTTFB alto até no cache hitMigrar para origem gerenciada
PHPTempo de servidor acima de 400 msSubir para PHP 8.3 + OPcache
Cache de páginaRápido logado, lento para o botCachear visitante anônimo
CDNLatência alta fora do BrasilBorda com PoP em São Paulo
BancoQueries lentas em lojaObject cache com Redis
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

Por que o TTFB do WordPress continua alto mesmo com plugin de cache ativo?

Porque o plugin entrega HTML pronto só para quem repete a visita, enquanto o Googlebot bate em URLs no cache miss e processa todo o PHP do zero. Se a origem roda PHP 7.4 sem OPcache, o TTFB no cache miss passa de 1 s mesmo com o WP Rocket ativo. O cache mascara o número no seu navegador e esconde o problema dos dados de campo do Chrome UX Report.

É possível reduzir o TTFB sem trocar de hospedagem?

Sim, até certo ponto: subir o PHP para a versão 8.3, ativar o OPcache e ligar o object cache com Redis cortam o tempo de servidor sem migrar. Esses ajustes costumam derrubar o TTFB de 20% a 40% no mesmo hardware. Mas se a hospedagem compartilhada está saturada e o TTFB segue acima de 800 ms no cache miss, o teto é a origem, e aí trocar de plano vira a única saída real.

Qual a diferença entre TTFB e LCP no WordPress?

O TTFB mede o tempo até o primeiro byte do servidor; o LCP mede quando o maior elemento visível termina de carregar na tela. O TTFB é um componente do LCP: um TTFB de 1.000 ms já consome quase metade do orçamento de 2,5 s que o web.dev define como LCP bom. Reduzir o TTFB é o primeiro passo para o LCP entrar na faixa verde dos Core Web Vitals.

Quanto custa reduzir o TTFB com o bundle da FULL?

No plano PRO da FULL, são R$849 ao ano para até dez sites, o que dá R$85 por site, com o WP Rocket e o pacote de performance já incluídos. Comprar WP Rocket, um plugin de object cache e licenças avulsas por site custa mais e ainda exige configurar cada peça separada. O bundle ativa cache, OPcache e CDN no mesmo painel, evitando o conflito de configuração que sozinho infla o TTFB.

O que o Googlebot enxerga de TTFB quando a página não está em cache?

O Googlebot enxerga o TTFB de origem, ou seja, o tempo cheio de PHP mais banco, porque ele frequentemente requisita URLs que não estão no cache de página. Esse é o número que entra nos dados de campo e influencia o ranking, não o TTFB rápido que você vê no segundo acesso. Por isso a medição que vale é sempre a do cache miss, com o cache recém-limpo.

--- ## 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.