TTFB alto no WordPress: como reduzir o tempo do servidor

Tipo Performance & Velocidade

Nome do erro TTFB alto (Reduce server response time) EN: High TTFB (Reduce server response time)

Severidade Grave

Descrição TTFB alto no WordPress é quando o Time to First Byte, o tempo entre o navegador pedir a página e receber o primeiro byte de resposta do servidor, passa de 600ms. Costuma vir de hospedagem lenta, ausência de cache de página, PHP não otimizado ou queries de banco demoradas que atrasam a geração da página.

O que é o TTFB alto no WordPress?

O TTFB alto no WordPress mede que o servidor demora demais para começar a responder. O Time to First Byte soma o tempo de DNS, conexão, processamento do PHP e do banco de dados até o primeiro byte do HTML chegar ao navegador. O Google considera bom um TTFB abaixo de 600 a 800 milissegundos; acima disso, todas as métricas seguintes, inclusive o LCP, herdam esse atraso fixo. Um TTFB alto raramente é problema de front-end: ele aponta para o servidor, para a falta de cache ou para o WordPress gerando a página do zero a cada visita em vez de servir uma versão pronta.

Como identificar

O diagnóstico “Reduzir o tempo de resposta do servidor (TTFB)” aparece como oportunidade no PageSpeed Insights.
“TTFB acima de 600ms” ou “Reduce initial server response time” no relatório do Lighthouse.
O waterfall da aba Network do navegador mostra um trecho “Waiting (TTFB)” longo antes de qualquer download.
A primeira resposta demora mesmo em páginas leves, e o atraso some quando uma versão em cache é servida.

Como prevenir

Mantenha cache de página e cache de objeto ativos e monitore o TTFB após cada mudança de tema ou plugin
Use sempre uma versão de PHP suportada com OPcache habilitado
Acompanhe queries lentas e o tamanho do banco para que o servidor não volte a gerar páginas devagar

Causa

Hospedagem compartilhada sobrecarregada ou com recursos de CPU e memória insuficientes para o tráfego do site.
Ausência de cache de página, fazendo o WordPress reconstruir o HTML com PHP e banco a cada requisição.
Versão de PHP antiga ou sem OPcache, deixando a execução do código mais lenta do que o necessário.
Queries de banco lentas por tabelas inchadas, falta de índices ou plugins que consultam demais o banco.
Servidor geograficamente distante do visitante, sem CDN para servir a primeira resposta de um nó próximo.

Como resolver

Meça o TTFB real: use o PageSpeed Insights e a aba Network do navegador para confirmar o tempo de "Waiting (TTFB)". Compare uma página em cache com uma sem cache para separar servidor de aplicação.
Ative cache de página: ligue um plugin de cache de página para servir HTML pronto em vez de gerar tudo a cada visita. É a medida com maior impacto sobre o TTFB na maioria dos sites WordPress.
Atualize o PHP e ative o OPcache: rode uma versão suportada do PHP (8.x) com OPcache habilitado. Versões novas executam o mesmo código bem mais rápido e cortam tempo de processamento.
Adicione cache de objeto persistente: configure Redis ou Memcached para cachear o resultado de queries repetidas. Isso reduz o trabalho do banco em páginas dinâmicas e logadas, onde o cache de página não atua.
Coloque um CDN na frente: use um CDN com cache na borda para entregar a primeira resposta de um nó próximo ao visitante, encurtando a latência de rede que entra no TTFB.
Avalie um upgrade de hospedagem: se o TTFB seguir alto mesmo com cache, o gargalo é o servidor. Migre para uma hospedagem com mais recursos ou especializada em WordPress.

APACHE

# .htaccess - serve a copia estatica de cache antes de subir o PHP
<IfModule mod_rewrite.c>
  RewriteEngine On

  # Nao usa cache para usuarios logados ou com carrinho/comentario
  RewriteCond %{HTTP_COOKIE} (wordpress_logged_in|comment_author|woocommerce_items_in_cart) [NC]
  RewriteRule .* - [S=1]

  # Se existe um HTML ja gerado para esta URL, serve direto (sem PHP)
  RewriteCond %{REQUEST_METHOD} GET
  RewriteCond %{QUERY_STRING} =""
  RewriteCond %{DOCUMENT_ROOT}/wp-content/cache/page/%{HTTP_HOST}%{REQUEST_URI}index.html -f
  RewriteRule .* /wp-content/cache/page/%{HTTP_HOST}%{REQUEST_URI}index.html [L]
</IfModule>

Perguntas frequentes

Qual é um bom valor de TTFB no WordPress?

O Google considera bom um TTFB abaixo de 600 a 800 milissegundos com dados de campo. Acima de 600ms o PageSpeed sinaliza a oportunidade "Reduzir o tempo de resposta do servidor", porque esse atraso entra em todas as métricas seguintes, inclusive o LCP.

O que mais reduz o TTFB no WordPress?

Cache de página costuma ser a medida de maior impacto, porque serve HTML pronto em vez de gerar a página com PHP e banco a cada visita. Em segundo lugar vêm PHP atualizado com OPcache, cache de objeto e uma hospedagem com recursos adequados.

Cache de página resolve o TTFB de usuários logados?

Não. Páginas logadas, carrinho e checkout costumam ignorar o cache de página por serem personalizadas. Nelas, o TTFB depende de PHP rápido, cache de objeto (Redis ou Memcached) e queries de banco eficientes.

TTFB alto é culpa da hospedagem?

Muitas vezes sim, mas nem sempre. Se o TTFB cai bastante quando uma página é servida do cache, o gargalo é a aplicação (PHP e banco). Se segue alto mesmo em cache, o problema é o servidor ou a rede, e um upgrade ou CDN ajuda.

Um CDN melhora o TTFB?

Melhora quando o CDN cacheia a resposta na borda e a entrega de um nó próximo ao visitante, cortando a latência de rede. Para conteúdo não cacheável, o CDN reduz só a parte de rede do TTFB, não o tempo de processamento no servidor de origem.

Reduzi o TTFB no teste mas o campo ainda mostra alto. Por quê?

Os dados de campo do PageSpeed são uma média de 28 dias de usuários reais e demoram semanas para refletir as correções. Além disso, o teste de laboratório mede de um único local; o campo reúne visitantes de várias regiões e conexões.

Grave

Como corrigir o erro de JavaScript ao combinar arquivos no WP Rocket

A opção Combine JavaScript Files do WP Rocket junta todos os scripts em um único arquivo; quando dois scripts dependem de ordem ou de uma variavel global, a juncao gera erro de JavaScript e quebra menu, carrossel, slider ou formulário. A correção e excluir o arquivo conflitante do combine.

Atenção

Como corrigir o impacto de scripts de terceiros (Analytics e Pixel) no WordPress

Scripts de terceiros como Google Analytics e Facebook Pixel carregam de domínios externos no head e bloqueiam a thread principal, elevando o Total Blocking Time e o LCP. A correção adia esses scripts até a interacao e hospeda o analytics localmente.

Grave

Como corrigir CLS alto e layout shift no WordPress

CLS alto no WordPress é quando o Cumulative Layout Shift, a medida de quanto os elementos da página "pulam" durante o carregamento, fica acima de 0,1. Costuma vir de imagens e iframes sem dimensões reservadas, fontes que trocam de tamanho e anúncios ou banners injetados sem espaço fixo.

Grave

Como corrigir scripts que não carregam pelo Script Manager do Perfmatters

No Perfmatters Script Manager o JS não carrega quando um arquivo JavaScript enfileirado é marcado como Off em escopo amplo (Everywhere ou por tipo de post) sem exceção para a página que precisa dele. O script some do front-end e a funcionalidade que dependia daquele arquivo para de responder, embora o recurso continue ativo no painel.

Informativo

Como corrigir o erro ao desativar RSS Feeds no Perfmatters

O erro ao desativar RSS Feeds no Perfmatters acontece quando a opção Disable RSS Feeds, em Options, fica ativa e passa a redirecionar ou bloquear todas as URLs de feed do WordPress, derrubando integracoes que ainda dependem do RSS, como Mailchimp, FeedBurner, podcast e leitores de feed.

Grave

Como corrigir render-blocking resources no WordPress

Render-blocking resources no WordPress são arquivos de CSS e JavaScript carregados no início da página que o navegador precisa baixar e processar antes de pintar qualquer conteúdo. Costumam vir de folhas de estilo e scripts enfileirados no head por tema e plugins, que atrasam a primeira pintura e elevam o LCP.

Setores

Extensões

Integrações

Como corrigir TTFB alto no WordPress (Reduce server response time)

O que é o TTFB alto no WordPress?

Como identificar

Como prevenir

Causa

Como resolver

Perguntas frequentes

Itens relacionados

Como corrigir o erro de JavaScript ao combinar arquivos no WP Rocket

Como corrigir o impacto de scripts de terceiros (Analytics e Pixel) no WordPress

Como corrigir CLS alto e layout shift no WordPress

Como corrigir scripts que não carregam pelo Script Manager do Perfmatters

Como corrigir o erro ao desativar RSS Feeds no Perfmatters

Como corrigir render-blocking resources no WordPress

Setores

Extensões

Integrações

Extensões

Hero Sections

Seções de CTA

Login

Blog

Cabeçalhos

Seções de FAQ

Cadastro

Blog individual

Rodapés

Seções de contato

Seções de preços

Faixas

Portfólio

Seções de equipe

Números

Logotipos