TTFB: o que é, ideal em 2026 e como reduzir

TTFB (Time to First Byte) é o tempo, em milissegundos, entre a requisição do navegador ao servidor e a chegada do primeiro byte de resposta HTTP. É a métrica que mede a velocidade do back-end antes de qualquer pixel ser renderizado, e alimenta diretamente o Largest Contentful Paint (LCP) dos Core Web Vitals.

Se você gerencia um site WordPress corporativo, já viveu esta cena: o PageSpeed Insights aponta tempo de resposta do servidor elevado, o LCP estoura o limite e o time de TI fala em “otimizar o servidor” sem apresentar um número claro. O problema é que o TTFB virou uma referência confusa. Boa parte do conteúdo na web ainda repete que o ideal é 200ms, um 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 valor ideal hoje segundo o Google, como fazer um teste confiável, o que causa TTFB alto no WordPress e, principalmente, um plano de 7 passos por prioridade para reduzir o tempo até o primeiro byte.

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 distintas:

1. 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.
2. 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 HTML.
3. Envio do primeiro byte: o tempo até o primeiro byte do HTML voltar pela rede e chegar ao navegador que fez a requisição.

É 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 visual.

Por que o TTFB importa para Core Web Vitals e conversão?

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 na tela. Reduzir o tempo até o primeiro byte é, na prática, comprar tempo para o LCP fechar dentro do limite de 2,5s. Um TTFB alto é o gargalo silencioso por trás de boa parte dos LCPs reprovados.

Há também o impacto comercial direto. Segundo o estudo Milliseconds Make Millions do Google com a Deloitte, 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 pagas 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 escondido no back-end.

Qual o TTFB ideal segundo o Google em 2026?

Aqui está a parte que mais gera confusão. O benchmark antigo de 200ms ainda circula em muitos artigos, mas o threshold oficial do web.dev é mais tolerante: o Google considera Good qualquer TTFB até 800ms. Acima de 1800ms a classificação é Poor.

Isso não significa que você deva mirar em 800ms. Significa que 800ms é o teto do que o Google classifica como aceitável, não o alvo. Um TTFB ideal abaixo de 200ms continua sendo excelente e dá uma folga enorme para o LCP fechar dentro do limite. A tabela abaixo resume as faixas oficiais, o impacto no LCP e a ação corretiva prioritária para cada cenário em WordPress:

Na experiência da Apiki 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 especificamente para WordPress.

Como fazer um TTFB test confiável?

Existem quatro formas práticas de fazer um TTFB test, da mais simples à mais técnica. Cada uma responde a uma pergunta diferente sobre o tempo de resposta do servidor:

• PageSpeed Insights (dado de campo): mostra o TTFB real de usuários coletado pelo CrUX (Chrome User Experience Report) nos últimos 28 dias. É o número que o Google de fato considera. Acesse o PageSpeed Insights e procure pela métrica “Tempo de resposta do servidor”.
• WebPageTest (diagnóstico por etapa): gera um waterfall detalhado que separa DNS, conexão TCP, handshake TLS e o tempo até o primeiro byte. Útil para descobrir em qual das três etapas do TTFB o tempo está sendo perdido.
• Chrome DevTools (laboratório): na aba Network, clique no documento principal e veja a métrica “Waiting for server response (TTFB)”. É uma medição de laboratório feita a partir da sua máquina e da sua conexão no momento do teste.
• Comando curl (teste rápido no terminal): para medir o TTFB por linha de comando, use curl -o /dev/null -s -w "%{time_starttransfer}\n" https://seusite.com.br. O valor retornado é o tempo até o primeiro byte em segundos.

Uma ressalva importante ao medir o TTFB: sempre priorize o dado de campo do PageSpeed Insights sobre o teste de laboratório. Testes locais variam conforme a sua conexão, o seu dispositivo e a sua localização geográfica, enquanto o CrUX reflete a experiência real dos seus visitantes. Se você quer entender melhor como ler o relatório, vale conferir nosso conteúdo sobre PageSpeed Insights.

O que causa um TTFB alto no WordPress?

No WordPress, o TTFB alto quase sempre vem da etapa de processamento no servidor. Antes de agir, vale entender a origem do gargalo. 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 que inflam o tempo de resposta.
• 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 entregue é exatamente o mesmo.
• Ausência de object cache: sem Redis ou Memcached, consultas repetidas ao banco de dados não são reaproveitadas entre requisições, forçando reprocessamento constante.
• Queries lentas e plugins mal escritos: um único plugin que faz consultas pesadas em cada carregamento de página pode somar centenas de milissegundos ao TTFB sozinho.
• 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 começar.
• TLS mal configurado, 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 desnecessariamente.

Como reduzir o TTFB no WordPress em 7 passos?

A boa notícia é que cada causa de TTFB alto tem um contraponto técnico claro. Abaixo estão os 7 passos para reduzir o TTFB no WordPress, organizados por prioridade de impacto. Comece de cima para baixo:

1. Ative page cache em nível de servidor: com o HTML estático servido diretamente pelo Nginx (FastCGI Cache) ou equivalente, a requisição nem chega a invocar o PHP. É o ganho mais expressivo e costuma derrubar o TTFB de segundos para dezenas de milissegundos.
2. 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, cenário típico de lojas WooCommerce onde o page cache não se aplica.
3. Migre para hospedagem WordPress gerenciada com PHP workers dedicados: uma infraestrutura ajustada combina todas as camadas por padrão, com workers exclusivos que eliminam a fila de requisições da hospedagem compartilhada.
4. Coloque uma CDN com edge cache na frente: 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.
5. Habilite HTTP/3 e TLS 1.3: protocolos modernos reduzem drasticamente o overhead da conexão e do handshake seguro. Entenda os benefícios no nosso conteúdo sobre HTTP/2 e suas evoluções.
6. Audite e remova plugins com queries pesadas: instale o Query Monitor, identifique os plugins que geram as consultas mais lentas em cada page load e substitua ou remova os que somam mais peso ao TTFB.
7. Otimize o MySQL: crie índices nas tabelas mais consultadas, mantenha a versão do banco atualizada, ajuste o my.cnf conforme a memória disponível e limpe o autoload da wp_options, que carrega em toda requisição.

Perguntas frequentes sobre TTFB

Qual a diferença entre TTFB e LCP?

O TTFB mede o tempo até o primeiro byte da resposta chegar ao navegador, ou seja, a velocidade do back-end. O LCP (Largest Contentful Paint) mede quando o maior elemento visível da tela termina de renderizar. O TTFB acontece primeiro e alimenta o LCP: se o TTFB é alto, o LCP herda esse atraso antes mesmo de começar a pintar pixels.

TTFB alto afeta o ranking no Google diretamente?

Não de forma direta. O TTFB não é um fator de ranking isolado, mas é uma métrica de suporte que alimenta o LCP, e o LCP faz parte dos Core Web Vitals, que são sinais de experiência usados pelo Google. Na prática, um TTFB alto tende a reprovar o LCP, e isso pode impactar o posicionamento em cenários competitivos.

CDN reduz o TTFB?

Sim, quando configurada com edge cache. Uma CDN que serve o HTML a partir do nó mais próximo do usuário reduz a latência de rede e o tempo de processamento, porque a resposta já sai pronta da borda. Sem edge cache, a CDN acelera apenas assets estáticos como imagens e não reduz o TTFB do documento principal.

Qual TTFB é considerado bom para WordPress?

Segundo o web.dev, o Google classifica como Good qualquer TTFB até 800ms. Porém, para um site WordPress bem configurado, o alvo prático deve ficar abaixo de 200ms de campo. Esse valor é totalmente viável com page cache em nível de servidor, object cache Redis e CDN com edge cache.

Como medir o TTFB pelo terminal?

Use o comando curl -o /dev/null -s -w "%{time_starttransfer}\n" https://seusite.com.br. O valor retornado é o tempo até o primeiro byte em segundos. É um teste rápido de laboratório, útil para comparar antes e depois de uma mudança de infraestrutura, mas não substitui o dado de campo do CrUX.

Por que meu TTFB varia tanto entre medições?

Variação entre medições é normal em testes de laboratório, porque dependem da sua conexão, do horário e da carga do servidor no momento. Se a variação é grande e recorrente, geralmente indica ausência de page cache (algumas requisições pegam cache, outras não) ou disputa de recursos em hospedagem compartilhada. O dado de campo do CrUX suaviza essa variação ao usar médias de 28 dias.

Cache de plugin como WP Rocket ou W3 Total Cache resolve o TTFB?

Ajuda, mas com limitação. Plugins de cache geram o HTML estático dentro do próprio WordPress, o que ainda exige que o PHP seja invocado para servir o arquivo. O ganho maior vem do page cache em nível de servidor (Nginx FastCGI), que responde antes de o PHP entrar em ação. O ideal é combinar cache de servidor com object cache Redis, e não depender só do plugin.

Conclusão

O ponto central deste guia é que o TTFB é sintoma de arquitetura, não de falta de CPU. Um tempo até o primeiro byte alto raramente se resolve comprando mais processamento. Ele se resolve colocando cache nas camadas certas, aproximando o conteúdo do usuário com CDN edge e rodando o WordPress em uma infraestrutura pensada para ele. O alvo não é os 800ms do teto “Good” do Google: é ficar consistentemente abaixo de 200ms de campo, folga que garante um LCP saudável e sustenta suas conversões.

Se o seu diagnóstico mostra TTFB alto, LCP reprovado e um time de TI sem clareza sobre onde está o gargalo, esse é exatamente o problema que resolvemos aqui na Apiki. Nossa hospedagem WordPress gerenciada já entrega page cache em nível de servidor, object cache Redis, HTTP/3 e CDN com edge cache pré-configurados, com TTFB de campo abaixo de 200ms em projetos corporativos. Fale com o nosso time e transforme o tempo de resposta do servidor de gargalo em vantagem competitiva.