Saiba como otimizar a métrica de Time to First Byte.
Publicado em 19 de janeiro de 2023, última atualização em 28 de novembro de 2025
O Time to First Byte (TTFB) é uma métrica de performance fundamental da Web que precede todas as outras métricas significativas de experiência do usuário, como First Contentful Paint (FCP) e Largest Contentful Paint (LCP). Isso significa que valores altos de TTFB adicionam tempo às métricas que o seguem.
Recomendamos que o servidor responda às solicitações de navegação com rapidez suficiente para que o 75º percentil dos usuários tenha uma FCP dentro do limite "bom". Como orientação geral, a maioria dos sites deve ter um TTFB de 0,8 segundo ou menos.
Como medir o TTFB
Antes de otimizar o TTFB, é preciso observar como ele afeta os usuários do seu site. Use os dados de campo como fonte principal para observar o TTFB, já que ele é afetado por redirecionamentos, enquanto as ferramentas de laboratório geralmente são medidas usando o URL final, o que não inclui esse atraso extra.
O PageSpeed Insights é uma maneira de receber informações de campo e de laboratório para sites públicos disponíveis no Chrome User Experience Report.
O TTFB para usuários reais é mostrado na seção Descubra o que seus usuários reais estão experimentando:
Para dados de laboratório, os problemas de TTFB são mostrados no insight Latência de solicitação de documento:
Para saber mais sobre como medir o TTFB em campo e no laboratório, consulte a página de métricas do TTFB.
Entender as diferenças entre o TTFB de campo e de laboratório
O TTFB de laboratório e de campo pode ser diferente por vários motivos. Quando isso acontece, é importante entender o porquê para usar os dados de laboratório de forma eficaz e melhorar as experiências do usuário.
Quando o TTFB de laboratório é muito maior que o TTFB de campo, isso indica que o ambiente de laboratório é mais restrito do que as experiências típicas do usuário. Isso não é necessariamente um problema, já que os resultados e as recomendações do laboratório ainda são válidos, mas podem exagerar o impacto e a melhoria.
Quando o TTFB de campo é muito maior do que o TTFB de laboratório, isso indica problemas que não são aparentes na execução do laboratório, como o uso de armazenamento em cache do lado do servidor, redirecionamentos ou diferenças de rede. Nesse caso, os resultados e as recomendações do laboratório podem ser menos úteis, já que não consideram um dos principais problemas.
Para conferir se o armazenamento em cache do lado do servidor está afetando o TTFB de laboratório, teste páginas menos comuns ou use parâmetros de URL diferentes para acessar conteúdo não armazenado em cache e conferir se o TTFB está mais alinhado com o TTFB de campo. Também pode ser útil ter a capacidade de ignorar o armazenamento em cache do lado do servidor com um parâmetro de URL específico. Consulte a seção de conteúdo em cache.
Para redirecionamentos e diferenças de rede, as análises de como o tráfego está chegando ao nosso site e de onde ele vem podem ser úteis para diagnosticar se esses são problemas em potencial.
Depurar o TTFB alto no campo com o Server-Timing
O cabeçalho de resposta Server-Timing pode ser usado no back-end do aplicativo para medir processos de back-end distintos que podem contribuir para a alta latência. A estrutura do valor do cabeçalho é flexível, aceitando, no mínimo, um identificador definido por você. Os valores opcionais incluem um valor de duração (via dur), bem como uma descrição legível por humanos opcional (via desc).
O Serving-Timing pode ser usado para medir muitos processos de back-end de aplicativos, mas há alguns que merecem atenção especial:
- consultas de banco de dados
- Tempo de renderização do lado do servidor, se aplicável
- Buscas de disco
- Ocorrências em cache ou ausências no servidor de borda (se estiver usando uma CDN)
Todas as partes de uma entrada Server-Timing são separadas por dois-pontos, e várias entradas podem ser separadas por uma vírgula:
// Two metrics with descriptions and values
Server-Timing: db;desc="Database";dur=121.3, ssr;desc="Server-side Rendering";dur=212.2
O cabeçalho pode ser definido usando a linguagem de sua escolha do back-end do aplicativo. No PHP, por exemplo, é possível definir o cabeçalho da seguinte maneira:
<?php
// Get a high-resolution timestamp before
// the database query is performed:
$dbReadStartTime = hrtime(true);
// Perform a database query and get results...
// ...
// Get a high-resolution timestamp after
// the database query is performed:
$dbReadEndTime = hrtime(true);
// Get the total time, converting nanoseconds to
// milliseconds (or whatever granularity you need):
$dbReadTotalTime = ($dbReadEndTime - $dbReadStartTime) / 1e+6;
// Set the Server-Timing header:
header('Server-Timing: db;desc="Database";dur=' . $dbReadTotalTime);
?>
Quando esse cabeçalho é definido, ele mostra informações que podem ser usadas no laboratório e no campo.
No campo, qualquer página com um cabeçalho de resposta Server-Timing definido preenche a propriedade serverTiming na API Navigation Timing:
// Get the serverTiming entry for the first navigation request:
performance.getEntries('navigation')[0].serverTiming.forEach(entry => {
// Log the server timing data:
console.log(entry.name, entry.description, entry.duration);
});
No laboratório, os dados do cabeçalho de resposta Server-Timing são visualizados no painel Tempos da guia Rede no Chrome DevTools:
Aqui, Server-Timing é usado para medir se uma solicitação de um recurso atingiu o cache da CDN e quanto tempo leva para a solicitação atingir o servidor de borda da CDN e, em seguida, a origem.
Os tempos de resposta do servidor também aparecem na faixa de rede do painel Desempenho no Chrome DevTools:
Depois de determinar que você tem um TTFB problemático analisando os dados disponíveis, é possível corrigir o problema.
Maneiras de otimizar o TTFB
O aspecto mais desafiador da otimização do TTFB é que, embora a pilha de front-end da Web seja sempre HTML, CSS e JavaScript, as pilhas de back-end podem variar significativamente. Há várias pilhas de back-end e produtos de banco de dados, cada um com as próprias técnicas de otimização. Portanto, este guia se concentra no que se aplica à maioria das arquiteturas, em vez de se concentrar apenas em orientações específicas de pilha.
Orientações específicas para a plataforma
A plataforma que você usa no seu site pode afetar muito o TTFB. Por exemplo, o desempenho do WordPress é afetado pelo número e pela qualidade dos plug-ins ou pelos temas usados. Outras plataformas são afetadas de forma semelhante quando são personalizadas. Consulte a documentação da sua plataforma para receber orientações específicas do fornecedor que complementem as dicas de desempenho mais gerais deste post. O insight do Lighthouse também inclui algumas orientações limitadas específicas da pilha.
Hospedagem, hospedagem, hospedagem
Antes de considerar outras abordagens de otimização, a hospedagem deve ser a primeira coisa a ser considerada. Não há muitas orientações específicas que possam ser oferecidas aqui, mas uma regra geral é garantir que o host do seu site seja capaz de lidar com o tráfego que você envia para ele.
A hospedagem compartilhada geralmente é mais lenta. Se você estiver executando um site pessoal pequeno que exibe principalmente arquivos estáticos, isso provavelmente não será um problema. Use algumas das técnicas de otimização a seguir para reduzir o TTFB o máximo possível.
No entanto, se você estiver executando um aplicativo maior com muitos usuários que envolve personalização, consulta de banco de dados e outras operações intensivas do lado do servidor, sua escolha de hospedagem se torna essencial para reduzir o TTFB em campo.
Ao escolher um provedor de hospedagem, considere os seguintes pontos:
- Quanta memória é alocada para a instância do aplicativo? Se o aplicativo não tiver memória suficiente, ele vai ter dificuldades para exibir as páginas o mais rápido possível.
- Seu provedor de hospedagem mantém sua pilha de back-end atualizada? À medida que novas versões de linguagens de back-end de aplicativos, implementações de HTTP e software de banco de dados são lançadas, o desempenho desse software melhora com o tempo. É fundamental fazer parceria com um provedor de hospedagem que priorize esse tipo de manutenção crucial.
- Se você tiver requisitos de aplicativo muito específicos e quiser o nível mais baixo de acesso aos arquivos de configuração do servidor, pergunte se faz sentido personalizar o back-end da sua própria instância de aplicativo.
Há muitos provedores de hospedagem que cuidam dessas coisas para você, mas se você começar a observar valores longos de TTFB mesmo em provedores de hospedagem dedicados, pode ser um sinal de que você precisa reavaliar os recursos do seu provedor de hospedagem atual para oferecer a melhor experiência do usuário possível.
Usar uma rede de fornecimento de conteúdo (CDN)
O tema uso de CDN é muito comum, mas por um bom motivo: você pode ter um back-end de aplicativo muito bem otimizado, mas os usuários localizados longe do servidor de origem ainda podem ter um TTFB alto em campo.
As CDNs resolvem o problema da proximidade do usuário em relação ao servidor de origem usando uma rede distribuída de servidores que armazenam recursos em cache em servidores fisicamente mais próximos dos usuários. Esses servidores são chamados de servidores de borda.
Os provedores de CDN também podem oferecer benefícios além dos servidores de borda:
- Os provedores de CDN geralmente oferecem tempos de resolução de DNS extremamente rápidos.
- Uma CDN provavelmente disponibiliza seu conteúdo de servidores de borda usando protocolos modernos, como HTTP/2 ou HTTP/3.
- O HTTP/3, em particular, resolve o problema de bloqueio de linha do cabeçalho presente no TCP (em que o HTTP/2 se baseia) usando o protocolo UDP.
- Uma CDN provavelmente fornece versões modernas de TLS, o que reduz a latência envolvida no tempo de negociação de TLS. O TLS 1.3, em particular, foi projetado para manter a negociação de TLS o mais curta possível.
- Alguns provedores de CDN oferecem um recurso geralmente chamado de "edge worker", que usa uma API semelhante à API Service Worker para interceptar solicitações, gerenciar de forma programática as respostas em armazenamento em cache de borda ou reescrever as respostas por completo.
- Os provedores de CDN são muito bons em otimizar a compactação. É difícil acertar a compactação por conta própria, e isso pode levar a tempos de resposta mais lentos em determinados casos com marcação gerada dinamicamente, que precisa ser compactada em tempo real.
- Além disso, os provedores de CDN armazenam automaticamente em cache as respostas compactadas para recursos estáticos, o que resulta na melhor combinação de taxa de compactação e tempo de resposta.
Embora a adoção de uma CDN envolva um esforço variável, de trivial a significativo, ela deve ser uma prioridade alta para otimizar o TTFB se o site ainda não estiver usando uma.
Usar conteúdo em cache sempre que possível
As CDNs permitem que o conteúdo seja armazenado em cache em servidores de borda que estão fisicamente mais próximos dos visitantes, desde que o conteúdo esteja configurado com os cabeçalhos HTTP Cache-Control apropriados. Embora isso não seja apropriado para conteúdo personalizado, exigir uma viagem de volta à origem pode anular grande parte do valor de uma CDN.
Para sites que atualizam o conteúdo com frequência, até mesmo um tempo de armazenamento em cache curto pode resultar em ganhos de desempenho perceptíveis para sites ocupados, já que apenas o primeiro visitante durante esse tempo experimenta a latência total de volta ao servidor de origem, enquanto todos os outros visitantes podem reutilizar o recurso em cache do servidor de borda. Algumas CDNs permitem a invalidação de cache em versões do site, o que oferece o melhor dos dois mundos: tempos de cache longos, mas atualizações instantâneas quando necessário.
Mesmo quando o armazenamento em cache está configurado corretamente, isso pode ser ignorado com o uso de parâmetros de string de consulta exclusivos para medição de análise. Eles podem parecer conteúdos diferentes para a CDN, mesmo sendo iguais, e, por isso, a versão em cache não será usada.
O conteúdo mais antigo ou menos visitado também pode não ser armazenado em cache, o que pode resultar em valores de TTFB mais altos em algumas páginas do que em outras. Aumentar os tempos de armazenamento em cache pode reduzir o impacto disso, mas esteja ciente de que, com o aumento dos tempos de armazenamento em cache, há uma maior possibilidade de veicular conteúdo potencialmente desatualizado.
O impacto do conteúdo em cache não afeta apenas quem usa CDNs. A infraestrutura do servidor pode precisar gerar conteúdo de pesquisas de banco de dados caras quando o conteúdo em cache não pode ser reutilizado. Dados acessados com mais frequência ou páginas pré-armazenadas em cache geralmente têm um desempenho melhor.
Evite redirecionamentos múltiplos de página
Um fator comum que contribui para um TTFB alto são os redirecionamentos. Os redirecionamentos ocorrem quando uma solicitação de navegação para um documento recebe uma resposta que informa ao navegador que o recurso existe em outro local. Um redirecionamento pode adicionar latência indesejada a uma solicitação de navegação, mas pode piorar se esse redirecionamento apontar para outro recurso que resulte em outro redirecionamento, e assim por diante. Isso pode afetar principalmente sites que recebem grandes volumes de visitantes de anúncios ou newsletters, já que eles costumam ser redirecionados por serviços de análise para fins de medição. Eliminar os redirecionamentos sob seu controle direto pode ajudar a alcançar um bom TTFB.
Há dois tipos de redirecionamento:
- Redirecionamentos de mesma origem, em que o redirecionamento ocorre inteiramente no seu site.
- Redirecionamentos entre origens, em que o redirecionamento ocorre inicialmente em outra origem, como um serviço de encurtamento de URL de rede social, antes de chegar ao seu site.
Concentre-se em eliminar os redirecionamentos de mesma origem, já que você tem controle direto sobre isso. Isso envolve verificar os links no seu site para ver se algum deles resulta em um código de resposta 302 ou 301. Isso geralmente acontece quando o esquema https:// não é incluído (então os navegadores usam http:// como padrão, que é redirecionado) ou porque as barras finais não são incluídas ou excluídas corretamente no URL.
Os redirecionamentos entre origens são mais complicados, porque geralmente estão fora do seu controle, mas tente evitar vários redirecionamentos sempre que possível, por exemplo, usando vários encurtadores de link ao compartilhar links. Verifique se o URL fornecido aos anunciantes ou às newsletters é o URL final correto para não adicionar outro redirecionamento aos usados por esses serviços.
Outra fonte importante de tempo de redirecionamento pode vir de redirecionamentos HTTP para HTTPS. Uma maneira de contornar isso é usar o cabeçalho Strict-Transport-Security (HSTS), que aplica o HTTPS na primeira visita a uma origem e, em seguida, instrui o navegador a acessar imediatamente a origem pelo esquema HTTPS nas visitas futuras.
Depois de implementar uma boa política de HSTS, você pode acelerar as coisas na primeira visita a uma origem adicionando seu site à lista de pré-carregamento de HSTS.
Transmitir marcação para o navegador
Os navegadores são otimizados para processar a marcação de forma eficiente quando ela é transmitida, ou seja, a marcação é processada em blocos conforme chega do servidor. Isso é crucial quando se trata de grandes payloads de marcação, porque significa que o navegador pode analisar os blocos de marcação de forma incremental, em vez de esperar que toda a resposta chegue antes de começar a análise.
Embora os navegadores sejam ótimos para processar a marcação de streaming, é crucial fazer tudo o que puder para manter esse fluxo para que os bits iniciais de marcação estejam a caminho o mais rápido possível. Se o back-end estiver atrasando as coisas, isso é um problema. Como as pilhas de back-end são numerosas, não é possível abordar todas as pilhas e os problemas que podem surgir em cada uma delas neste guia.
O React, por exemplo, e outros frameworks que podem renderizar marcações sob demanda no servidor usam uma abordagem síncrona para a renderização do lado do servidor. No entanto, as versões mais recentes do React implementaram métodos de servidor para streaming de marcação (link em inglês) enquanto ela é renderizada. Isso significa que você não precisa esperar que um método da API do servidor React renderize toda a resposta antes de enviá-la.
Outra maneira de garantir que a marcação seja transmitida rapidamente para o navegador é usar a renderização estática, que gera arquivos HTML durante o tempo de build. Com o arquivo completo disponível imediatamente, os servidores da Web podem começar a enviar o arquivo imediatamente, e a natureza inerente do HTTP resulta em marcação de streaming. Embora essa abordagem não seja adequada para todas as páginas de todos os sites, como aquelas que exigem uma resposta dinâmica como parte da experiência do usuário, ela pode ser útil para páginas que não exigem que a marcação seja personalizada para um usuário específico.
Usar um service worker
A API Service Worker pode ter um grande impacto no TTFB para documentos e os recursos que eles carregam. Isso ocorre porque um service worker atua como um proxy entre o navegador e o servidor. No entanto, o impacto no TTFB do seu site depende de como você configura o service worker e se essa configuração está alinhada aos requisitos do aplicativo.
- Use uma estratégia stale-while-revalidate para recursos. Se um recurso estiver no cache do service worker, seja um documento ou um recurso que o documento exige, a estratégia stale-while-revalidate vai disponibilizar esse recurso do cache primeiro, depois vai fazer o download dele em segundo plano e o disponibilizará do cache para interações futuras.
- Se você tiver recursos de documentos que não mudam com frequência, usar uma estratégia stale-while-revalidate pode tornar o TTFB de uma página quase instantâneo. No entanto, isso não funciona tão bem se o site envia marcações geradas dinamicamente, como aquelas que mudam dependendo se o usuário está autenticado ou não. Nesses casos, é recomendável sempre acessar a rede primeiro para que o documento seja o mais recente possível.
- Se o documento carregar recursos não críticos que mudam com alguma frequência, mas a busca do recurso desatualizado não afetar muito a experiência do usuário, como imagens selecionadas ou outros recursos não críticos, o TTFB desses recursos poderá ser bastante reduzido usando uma estratégia de stale-while-revalidate.
- Use o modelo de shell do app para aplicativos renderizados pelo cliente. Esse modelo é mais adequado para SPAs em que o "shell" da página pode ser entregue instantaneamente pelo cache do service worker, e o conteúdo dinâmico da página é preenchido e renderizado mais tarde no ciclo de vida da página.
Usar 103 Early Hints para recursos essenciais para a renderização
Não importa o quanto o back-end do aplicativo esteja otimizado, o servidor ainda pode ter muito trabalho para preparar uma resposta, incluindo um trabalho de banco de dados caro (mas necessário) que atrasa a chegada da resposta de navegação. O efeito potencial disso é que alguns recursos subsequentes essenciais para a renderização podem ser atrasados, como CSS ou, em alguns casos, JavaScript que renderiza marcação no cliente.
O cabeçalho 103 Early Hints é um código de resposta antecipada que o servidor pode enviar ao navegador enquanto o back-end está ocupado preparando a marcação. Esse cabeçalho pode ser usado para indicar ao navegador que há recursos essenciais para renderização que a página precisa começar a baixar enquanto a marcação está sendo preparada. Para navegadores compatíveis, o efeito pode ser uma renderização de documentos (CSS) e um carregamento de página mais rápidos.
Uma desvantagem das 103 Early Hints é que, assim como o armazenamento em cache, elas podem mascarar o TTFB "real" de um site. Se uma infraestrutura de servidor for lenta (porque não tem capacidade suficiente ou o código precisa de otimização), isso pode ser menos óbvio quando o 103 Early Hints é usado, já que o TTFB parece rápido. Os sites que usam 103 Early Hints devem considerar medir o tempo real do servidor (por meio de Server-Timing ou finalResponseHeadersStart da API PerformanceNavigationTiming).
Conclusão
Como há muitas combinações de pilhas de aplicativos de back-end, não há um único artigo que possa abranger tudo o que você pode fazer para reduzir o TTFB do seu site. No entanto, estas são algumas opções que você pode usar para tentar acelerar um pouco as coisas no servidor.
Assim como na otimização de todas as métricas, a abordagem é bastante semelhante: meça o TTFB em campo, use ferramentas de laboratório para analisar as causas e aplique otimizações sempre que possível. Embora algumas técnicas possam não ser viáveis para sua situação, outras provavelmente são. Como sempre, você precisa ficar de olho nos dados de campo e fazer ajustes conforme necessário para garantir a experiência do usuário mais rápida possível.