Otimizar o tempo para o primeiro byte

Saiba como otimizar a métrica "Tempo até o primeiro byte".

Jeremy Wagner

Barry Pollard

O Tempo até o primeiro byte (TTFB, na sigla em inglês) é uma métrica básica de desempenho na Web que precede qualquer outra métrica significativa da experiência do usuário, como Primeira exibição de conteúdo (FCP) e Maior exibição de conteúdo (LCP). Isso significa que valores de TTFB altos adicionam tempo às métricas que o seguem.

Recomendamos que seu servidor responda às solicitações de navegação com rapidez suficiente para que o 75o percentil dos usuários tenha uma FCP dentro do limite "bom". Como guia básico, a maioria dos sites precisa ter um TTFB de 0,8 segundo ou menos.

Como medir o TTFB

Antes de otimizar o TTFB, você precisa observar como isso afeta os usuários do seu site. Use os dados de campo como fonte principal para observar o TTFB, já que ele é afetado pelos redirecionamentos, enquanto as ferramentas baseadas em laboratório geralmente são medidas usando o URL final, o que elimina esse atraso extra.

O PageSpeed Insights é uma maneira simples de acessar informações de campos e laboratórios de sites públicos disponíveis no Chrome User Experience Report.

O TTFB para usuários reais é exibido na seção superior Descubra a experiência dos seus usuários reais:

Um subconjunto de TTFB é mostrado na auditoria do tempo de resposta do servidor:

Para descobrir mais maneiras de medir o TTFB no campo e no laboratório, consulte a página de métricas do TTFB.

Como entender o TTFB alto com o Server-Timing

O cabeçalho de resposta Server-Timing pode ser usado no back-end do seu aplicativo para medir processos de back-end distintos que podem contribuir para alta latência. A estrutura do valor do cabeçalho é flexível e aceita, no mínimo, um identificador definido por você. Os valores opcionais incluem um valor de duração (via dur) e uma descrição opcional legível por humanos (via desc).

O Serving-Timing pode ser usado para medir muitos processos de back-end de aplicativos, mas preste atenção especial a alguns:

• Consultas de banco de dados
• Tempo de renderização do lado do servidor, se aplicável
• Buscas de disco
• Ocorrências/ausências em cache do servidor de borda (se você 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 preferida do back-end do seu aplicativo. Em PHP, por exemplo, você pode definir o cabeçalho assim:

<?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 - $dbReadStarTime) / 1e+6;

// Set the Server-Timing header:
header('Server-Timing: db;desc="Database";dur=' . $dbReadTotalTime);
?>

Quando o 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 vai preencher 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 serão visualizados no painel de tempo da guia Rede no Chrome DevTools:

Cabeçalhos de resposta Server-Timing visualizados na guia de rede do Chrome DevTools. Aqui, o 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 chegar ao servidor de borda da CDN e, em seguida, à origem.

Depois de determinar que você tem um TTFB problemático analisando os dados disponíveis, prossiga para a correção do problema.

Formas de otimizar o TTFB

O aspecto mais desafiador da otimização do TTFB é que, embora a pilha de front-end da Web sempre seja HTML, CSS e JavaScript, as pilhas de back-end podem variar significativamente. Existem várias pilhas de back-end e produtos de banco de dados, cada um com suas próprias técnicas de otimização. Portanto, este guia vai se concentrar no que se aplica à maioria das arquiteturas, em vez de focar apenas na orientação específica da pilha.

Orientações específicas da plataforma

A plataforma que você usa para 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 a plataforma é personalizada. Consulte a documentação da sua plataforma para consultar recomendações específicas do fornecedor e complementar as recomendações mais gerais de desempenho desta postagem. A auditoria do Lighthouse para reduzir os tempos de resposta do servidor também inclui orientações limitadas específicas sobre a pilha.

Hospedagem, hospedagem, hospedagem

Antes de considerar outras abordagens de otimização, a hospedagem deve ser o primeiro ponto a ser considerado. Não há muito nessas orientações específicas que podem ser oferecidas aqui, mas a 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 pequeno site pessoal que exibe principalmente arquivos estáticos, isso provavelmente não é um problema, e algumas das técnicas de otimização a seguir ajudarão você a 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 fundamental para reduzir o TTFB no campo.

Ao escolher um provedor de hospedagem, observe os seguintes aspectos:

• Quanta memória a instância do aplicativo está alocada? Se seu aplicativo tiver memória insuficiente, ele vai se sobrecarregar e apresentar as páginas o mais rápido possível.
• O provedor de hospedagem mantém a pilha de back-end atualizada? À medida que novas versões das linguagens de back-end do aplicativo, implementações HTTP e software de banco de dados forem lançadas, o desempenho nesse software será melhorado com o tempo. É essencial fazer parceria com um provedor de hospedagem que prioriza esse tipo de manutenção crucial.
• Se você tem requisitos de aplicativo muito específicos e quer o acesso de nível mais baixo aos arquivos de configuração do servidor, pergunte se faz sentido personalizar o back-end da instância do seu aplicativo.

Há muitos provedores de hospedagem que cuidarão de tudo isso para você, mas se você começar a notar longos valores de TTFB, mesmo em provedores de hospedagem dedicados, pode ser um sinal de que você pode precisar reavaliar os recursos do seu provedor de hospedagem atual para poder oferecer a melhor experiência possível ao usuário.

Usar uma rede de fornecimento de conteúdo (CDN)

O tópico Uso da CDN é bastante usado, mas por um bom motivo: você pode ter um back-end de aplicativo muito otimizado, mas os usuários localizados longe do servidor de origem ainda podem ter TTFB alto no campo.

As CDNs resolvem o problema da proximidade do usuário no seu 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 exibirá seu conteúdo a partir de servidores de borda usando protocolos modernos, como HTTP/2 ou HTTP/3.
• O HTTP/3, em especial, resolve o problema de bloqueio de "head-of-line" presente no TCP (do qual o HTTP/2 se baseia) usando o protocolo UDP.
• Uma CDN provavelmente também fornecerá versões modernas do TLS, o que diminui a latência envolvida no tempo de negociação do TLS. O TLS 1.3, em particular, foi desenvolvido para manter a negociação de TLS o mais curta possível.
• Alguns provedores de CDN oferecem um recurso geralmente chamado de "worker de borda", que usa uma API semelhante à da API Service Worker para interceptar solicitações, gerenciar programaticamente respostas em caches de borda ou reescrever todas as respostas.
• Provedores de CDN são muito bons em otimizar a compactação. A compressão é um processo difícil de acertar por conta própria e pode levar a tempos de resposta mais lentos em certos casos com marcação gerada dinamicamente, que deve ser compactada em tempo real.
• Os provedores de CDN também armazenam automaticamente em cache as respostas compactadas dos recursos estáticos, levando à melhor combinação de proporção de compactação e tempo de resposta.

Embora a adoção de uma CDN envolva uma quantidade variável de esforço, de trivial a significativa, deve ser de alta prioridade a otimização do seu TTFB se seu site ainda não estiver usando uma.

Usou conteúdo em cache sempre que possível

As CDNs permitem que o conteúdo seja armazenado em cache em servidores de borda localizados fisicamente mais perto dos visitantes, desde que o conteúdo seja configurado com os cabeçalhos HTTP Cache-Control adequados. Embora isso não seja apropriado para conteúdo personalizado, exigir uma viagem de volta à origem pode negar muito do valor de uma CDN.

Para sites que atualizam seu conteúdo com frequência, mesmo um curto tempo de armazenamento em cache pode resultar em ganhos perceptíveis de desempenho para sites ocupados, uma vez que apenas o primeiro visitante nesse período tem latência total de volta para o servidor de origem, enquanto todos os outros visitantes podem reutilizar o recurso armazenado em cache do servidor de borda. Algumas CDNs permitem a invalidação de cache em versões do site, possibilitando o melhor dos dois mundos: longos tempos de cache, 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, apesar de serem iguais e, portanto, a versão em cache não será usada.

Os conteúdos mais antigos ou menos visitados também podem não ser armazenados 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 saiba que, com tempos de cache maiores, há uma possibilidade maior de exibir conteúdo potencialmente desatualizado.

O impacto do conteúdo armazenado em cache não afeta apenas quem usa CDNs. Talvez a infraestrutura do servidor precise gerar conteúdo de pesquisas caras no banco de dados quando o conteúdo armazenado em cache não puder ser reutilizado. Dados acessados com mais frequência ou páginas pré-armazenadas em cache geralmente têm um desempenho melhor.

Evite vários redirecionamentos de página

Um fator comum para uma alta TTFB são os redirecionamentos. Os redirecionamentos ocorrem quando uma solicitação de navegação para um documento recebe uma resposta informando ao navegador que o recurso existe em outro local. Um redirecionamento certamente pode adicionar latência indesejada a uma solicitação de navegação, mas certamente pode piorar se esse redirecionamento apontar para outro recurso que resulte em outro redirecionamento, e assim por diante. Isso pode afetar especialmente os sites que recebem um grande volume de visitantes de anúncios ou newsletters, já que eles geralmente são redirecionados por meio de serviços de análise para fins de medição. Eliminar os redirecionamentos sob seu controle direto pode ajudar a conseguir um bom TTFB.

Há dois tipos de redirecionamentos:

• Redirecionamentos de mesma origem, em que o redirecionamento ocorre inteiramente no seu site.
• Redirecionamentos de origem cruzada, em que o redirecionamento ocorre inicialmente em outra origem, como um serviço de encurtamento de URL de mídia social, antes de chegar ao seu site.

É importante se concentrar em eliminar os redirecionamentos de mesma origem, já que você terá controle direto sobre eles. Isso envolveria a verificação de links no seu site para ver se algum deles resulta em um código de resposta 302 ou 301. Muitas vezes, isso pode ser resultado da não inclusão do esquema https:// (o padrão dos navegadores é http://, que depois é redirecionado) ou porque as barras no final não são incluídas ou excluídas corretamente no URL.

Os redirecionamentos de origem cruzada são mais complicados porque geralmente estão fora do seu controle, mas tente evitar vários deles sempre que possível. Por exemplo, use vários encurtadores de links ao compartilhar links. Verifique se o URL informado 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 são os redirecionamentos HTTP para HTTPS. Uma maneira de contornar isso é usar o cabeçalho Strict-Transport-Security (HSTS), que impõe o HTTPS na primeira visita a uma origem e instrui o navegador a acessar imediatamente a origem pelo esquema HTTPS em visitas futuras.

Quando você tiver uma boa política de HSTS, poderá acelerar o processo na primeira visita a uma origem adicionando seu site à lista de pré-carregamento de HSTS.

Fazer streaming da marcação para o navegador

Os navegadores são otimizados para processar a marcação de forma eficiente quando ela é transmitida, o que significa que a marcação é tratada em partes à medida que chega do servidor. Isso é crucial no que diz respeito a grandes payloads de marcação, pois significa que o navegador pode analisar os blocos de marcação incrementalmente, em vez de esperar que toda a resposta chegue antes que a análise possa começar.

Embora os navegadores sejam ótimos para lidar com a marcação de streaming, é essencial fazer tudo o que puder para manter o fluxo fluindo para que as partes iniciais da marcação cheguem o mais rápido possível. Se o back-end está atrapalhando as coisas, isso é um problema. Devido ao grande número de pilhas de back-end, este guia não abordou cada uma delas e os problemas que podem surgir em cada uma delas.

O React, por exemplo, e outros frameworks que podem renderizar a marcação sob demanda no servidor, usaram 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 marcação de streaming durante a renderização. Isso significa que você não precisa esperar que um método da API do servidor React renderize toda a resposta antes que ela seja enviada.

Outra forma de garantir que a marcação seja transmitida para o navegador rapidamente é usando a renderização estática, que gera arquivos HTML durante o tempo de compilação. 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 resultará 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 benéfica para as páginas que não exigem marcação para ser personalizada a um usuário específico.

Usar um service worker

A API Service Worker pode ter um grande impacto no TTFB para os documentos e os recursos que eles carregam. Isso acontece porque um service worker atua como um proxy entre o navegador e o servidor, mas 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 de revalidação com efeito desatualizado para recursos. Se um recurso estiver no cache do service worker, seja ele um documento ou um recurso que o documento exige, a estratégia de inatividade durante a revalidação atenderá primeiro a esse recurso do cache, depois fará o download desse recurso em segundo plano e o exibirá do cache para interações futuras.
  • Se você tiver recursos de documento que não mudam com muita frequência, usar uma estratégia de inatividade durante a revalidação pode tornar o TTFB de uma página quase instantâneo. No entanto, isso não funcionará muito bem se seu site enviar marcações geradas dinamicamente, como uma marcação que muda dependendo da autenticação do usuário. Nesses casos, convém sempre acessar a rede primeiro para que o documento esteja o mais atualizado possível.
  • Se o documento carregar recursos não críticos que mudam com certa frequência, mas buscar o recurso desatualizado não vai afetar muito a experiência do usuário, como selecionar imagens ou outros recursos não críticos, o TTFB para esses recursos pode ser bastante reduzido com uma estratégia de revalidação desatualizada.
• Use uma arquitetura de service worker de streaming, se possível. Essa arquitetura de service worker usa uma abordagem em que partes de um recurso de documento são armazenadas no cache do service worker e combinadas com partes parciais de conteúdo durante a solicitação de navegação. O efeito resultante do uso desse padrão de service worker é que sua navegação será bastante rápida, enquanto payloads menores de HTML são baixados da rede. Embora esse padrão de service worker não funcione para todos os sites, os tempos de TTFB para recursos de documentos podem ser praticamente instantâneos para sites que podem usá-lo.
• Use o modelo de shell do app para aplicativos renderizados pelo cliente. Esse modelo é ideal para SPAs em que o "shell" da página pode ser entregue instantaneamente a partir do 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 críticos de renderização

Não importa quão bem o back-end do seu aplicativo esteja otimizado, ainda pode haver uma quantidade significativa de trabalho que o servidor precisa fazer para preparar uma resposta, incluindo trabalho caro (mas necessário) no banco de dados que atrasa a chegada da resposta de navegação o mais rápido possível. O possível efeito disso é que alguns recursos críticos de renderização subsequentes poderão 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 inicial 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 de renderização para iniciar o download da página enquanto a marcação está sendo preparada. Para navegadores compatíveis, o efeito pode ser a renderização de documentos (CSS) mais rápida e a disponibilidade mais rápida da funcionalidade principal da página (JavaScript).

Conclusão

Como há muitas combinações de pilhas de aplicativos de back-end, não há um 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 explorar para tentar fazer as coisas funcionarem um pouco mais rápido no lado do servidor.

Assim como na otimização de todas as métricas, a abordagem é muito semelhante: meça seu TTFB no campo, use as ferramentas do laboratório para detalhar as causas e, em seguida, aplique as otimizações sempre que possível. Nem todas as técnicas aqui são viáveis para a sua situação, mas algumas serão. Como sempre, você precisará ficar de olho nos dados de campo e fazer os ajustes necessários para garantir a experiência do usuário mais rápida possível.

Imagem principal de Taylor Vick (link em inglês), retirada do Unsplash.