A funcionalidade de resumo para páginas no WordPress
Por padrão, o WordPress disponibiliza a funcionalidade de resumo para os Posts. Aprenda implementar o Resumo para páginas.
TTFB (Time to First Byte) é o tempo, em milissegundos, entre a requisição do navegador ao servidor e o recebimento do primeiro byte de resposta. É a métrica que mede a velocidade de resposta do back-end antes de qualquer renderização visual começar.
Se você gerencia um site WordPress corporativo, já passou por isso: o PageSpeed Insights aponta tempo de resposta do servidor elevado, o LCP estoura e o time de TI fala em “otimizar o servidor” sem números claros. O problema é que o TTFB virou uma referência confusa. Boa parte do conteúdo na web ainda repete que o ideal é 200ms, número que ficou para trás desde que o TTFB entrou oficialmente no radar dos Core Web Vitals.
Neste guia vamos esclarecer o que é o TTFB, qual o número aceitável hoje segundo o Google, como medir e o que de fato causa um TTFB alto no WordPress.
O que é TTFB (Time to First Byte)?
TTFB é o intervalo de tempo entre o momento em que o navegador envia a requisição ao servidor e o momento em que recebe o primeiro byte da resposta. Ele mede a velocidade do back-end, não o carregamento completo da página.
Essa janela se decompõe em três etapas:
- Envio da requisição: o tempo para a requisição HTTP sair do navegador, resolver o DNS, abrir a conexão TCP e concluir o handshake TLS até chegar ao servidor.
- Processamento no servidor: o tempo que o servidor leva para interpretar a requisição, executar o código (no WordPress, isso significa rodar PHP e consultar o MySQL) e montar a resposta.
- Envio do primeiro byte: o tempo até o primeiro byte do HTML voltar pela rede e chegar ao navegador.
É importante separar o TTFB do tempo de carregamento total. O TTFB termina no primeiro byte. Depois dele ainda vêm o download do HTML, o parsing, o carregamento de CSS, JavaScript, fontes e imagens. Por isso um TTFB alto contamina toda a cadeia: nada começa a renderizar antes do primeiro byte chegar. A definição de TTFB no MDN reforça esse ponto: trata-se de uma medida de latência de resposta, não de renderização.
Por que o TTFB importa para SEO e Core Web Vitals?
O TTFB se tornou uma métrica de suporte aos Core Web Vitals em 2022, segundo a documentação oficial do web.dev sobre TTFB. Ele não é uma métrica de ranking direta, mas alimenta uma que é.
O mecanismo é simples. O Largest Contentful Paint (LCP), métrica oficial de experiência usada pelo Google, só pode acontecer depois que o navegador recebe o HTML inicial. Se o TTFB está em 1,5s, o LCP já parte de um atraso de 1,5s antes mesmo de qualquer pixel aparecer. Reduzir o TTFB é, na prática, comprar tempo para o LCP fechar dentro do limite de 2,5s.
Há também o impacto comercial. Segundo dados do Google em parceria com a Deloitte no estudo Milliseconds Make Millions, melhorias de 0,1s no tempo de carregamento móvel aumentaram as taxas de conversão em diversos setores de varejo e viagens. Para quem roda campanhas e mede CAC, isso significa que o tempo de resposta do servidor é parte da equação de conversão, não um detalhe de infraestrutura.
Qual é o TTFB ideal em 2025?
Aqui está a parte que mais gera confusão. O benchmark antigo de 200ms ainda circula, mas o threshold oficial do web.dev é mais tolerante: o Google considera Good qualquer TTFB até 800ms.
Isso não significa que você deva mirar em 800ms. Significa que 800ms é o teto do que o Google classifica como aceitável. Um TTFB abaixo de 200ms continua sendo excelente e dá folga enorme para o LCP. A tabela abaixo resume os limites e o que cada faixa costuma representar em um ambiente WordPress:
| Classificação | TTFB (ms) | Impacto no LCP | Cenário típico em WordPress |
|---|---|---|---|
| Good (Google) | ≤ 800ms | LCP saudável viável | Page cache + object cache + hospedagem gerenciada |
| Needs Improvement | 800ms – 1800ms | LCP frequentemente acima de 2,5s | Sem page cache, plugins pesados, hospedagem compartilhada |
| Poor | > 1800ms | LCP quase sempre falha | Servidor saturado, queries lentas, sem CDN |
| Excelente (benchmark Apiki) | < 200ms | LCP < 1,5s consistente | Edge cache + HTTP/3 + infraestrutura ajustada |
Na nossa experiência com clientes corporativos, sites bem configurados ficam consistentemente abaixo de 200ms no TTFB de campo. O salto de “Good” para “excelente” raramente vem de mais CPU. Vem de cache nas camadas certas e de uma infraestrutura ajustada para WordPress.
Como testar o TTFB do seu site?
Existem quatro formas práticas de medir o TTFB, da mais simples à mais técnica:
- PageSpeed Insights: mostra o dado de campo (CrUX), ou seja, o TTFB real de usuários nos últimos 28 dias. É o número que o Google de fato considera. Acesse o PageSpeed Insights e procure por “Tempo de resposta do servidor”.
- WebPageTest: gera um waterfall detalhado mostrando DNS, conexão, TLS e o tempo até o primeiro byte separadamente. Útil para descobrir em qual das três etapas o tempo está sendo perdido. Disponível no WebPageTest.
- Chrome DevTools: na aba Network, clique no documento principal e veja a métrica “Waiting for server response (TTFB)”. É a medição em laboratório, feita a partir da sua máquina.
- Comando curl: para um teste rápido por linha de comando, use
curl -o /dev/null -s -w "%{time_starttransfer}\n" https://seusite.com.br. O valor retornado é o TTFB em segundos.
Recomendamos sempre priorizar o dado de campo do PageSpeed Insights. Testes em laboratório variam conforme a sua conexão e localização, enquanto o CrUX reflete a experiência real dos seus visitantes.
O que causa um TTFB alto no WordPress?
No WordPress, o TTFB alto quase sempre vem do tempo de processamento no servidor. As causas mais comuns são:
- Hospedagem compartilhada: o número de PHP workers é limitado e disputado com outros sites no mesmo servidor, criando filas de requisição em horários de pico.
- Ausência de page cache: sem cache de página, cada visita executa todo o ciclo de PHP e consulta o MySQL do zero, mesmo quando o conteúdo não muda.
- Ausência de object cache: sem Redis ou Memcached, consultas repetidas ao banco não são reaproveitadas entre requisições.
- Queries lentas e plugins mal escritos: um único plugin que faz consultas pesadas em cada page load pode somar centenas de milissegundos ao TTFB.
- Distância geográfica do datacenter: se o servidor está em outro continente, o tempo de ida e volta da rede entra na conta antes mesmo do processamento.
- TLS handshake sem HTTP/2 ou HTTP/3: protocolos antigos exigem mais idas e voltas para estabelecer a conexão segura, inflando a primeira etapa do TTFB.
Como reduzir o TTFB no WordPress?
A boa notícia é que cada causa tem um contraponto técnico claro. Para reduzir o TTFB no WordPress:
- Implemente page cache: com o HTML estático servido diretamente pelo Nginx, a requisição nem chega a invocar o PHP. É o ganho mais expressivo e costuma derrubar o TTFB de segundos para dezenas de milissegundos.
- Ative object cache com Redis: ele guarda em memória os resultados de consultas ao banco, eliminando o reprocessamento em páginas dinâmicas e na área logada do WooCommerce.
- Otimize o banco de dados: crie índices nas tabelas mais consultadas e limpe o autoload da wp_options, que carrega em toda requisição.
- Use uma CDN com edge cache: serviços como Cloudflare e BunnyCDN entregam o conteúdo a partir do nó mais próximo do usuário, reduzindo a latência de rede. Veja como ganhar maior performance com CDN.
- Habilite HTTP/2 ou HTTP/3: protocolos modernos reduzem o overhead da conexão. Entenda os benefícios no nosso conteúdo sobre HTTP/2.
- Migre para hospedagem WordPress gerenciada: uma infraestrutura ajustada para WordPress combina todas essas camadas por padrão, com PHP workers dedicados e cache pré-configurado.
Perguntas frequentes sobre TTFB
Qual é o TTFB considerado bom pelo Google?
O Google classifica como Good qualquer TTFB igual ou inferior a 800ms, segundo o web.dev. Entre 800ms e 1800ms a classificação é Needs Improvement, e acima de 1800ms é Poor. Valores abaixo de 200ms são considerados excelentes.
O TTFB afeta o ranking no Google?
O TTFB não é uma métrica de ranking direta, mas afeta o ranking de forma indireta. Ele é uma métrica de suporte aos Core Web Vitals e influencia diretamente o LCP, que é usado pelo Google como sinal de experiência da página.
Qual a diferença entre TTFB e LCP?
O TTFB mede o tempo até o primeiro byte de resposta do servidor, ou seja, a velocidade do back-end. O LCP mede quando o maior elemento visual da página termina de renderizar. O TTFB é o ponto de partida; o LCP depende dele para fechar dentro do limite de 2,5s.
Como o WordPress impacta o TTFB?
O WordPress gera as páginas dinamicamente, executando PHP e consultando o MySQL a cada requisição. Sem cache, esse processamento entra inteiro na conta do TTFB. Por isso a configuração de cache e a qualidade da hospedagem são os fatores que mais pesam no TTFB de um site WordPress.
CDN reduz o TTFB?
Sim, quando configurada com edge cache. A CDN entrega o conteúdo a partir do servidor mais próximo do visitante e, com cache na borda, responde sem precisar acionar o servidor de origem. Isso reduz tanto a latência de rede quanto o tempo de processamento.
TTFB alto significa servidor ruim?
Nem sempre. Um TTFB alto pode vir de ausência de cache, queries lentas, plugins pesados ou distância do datacenter, mesmo em servidores potentes. Antes de trocar de hardware, vale medir onde o tempo está sendo perdido com WebPageTest ou Chrome DevTools.
Posso ter um TTFB abaixo de 100ms no WordPress?
Sim. Com page cache servido pelo Nginx, edge cache em CDN e HTTP/3, é viável manter o TTFB abaixo de 100ms para páginas em cache. A dificuldade aparece em páginas dinâmicas e logadas, onde o object cache se torna essencial.
Conclusão
O TTFB deixou de ser um detalhe avançado de performance e virou parte da equação dos Core Web Vitals. O benchmark de 200ms que circula em artigos antigos não é mais o único parâmetro: o Google aceita até 800ms como Good, mas quanto mais baixo o TTFB, mais folga o LCP tem para fechar dentro do limite.
No WordPress, a diferença entre um TTFB ruim e um excelente raramente está na potência do servidor. Está na arquitetura de cache em camadas, na otimização do banco e em uma infraestrutura ajustada para rodar WordPress em escala. Esse é exatamente o trabalho que fazemos na nossa hospedagem WordPress gerenciada, com cache pré-configurado, HTTP/3 e TTFB monitorado. Se o tempo de resposta do servidor está travando seu LCP e suas campanhas, fale com o nosso time e descubra onde está o gargalo.
Carlos 
Lara 
