Reduzir a subparte Cache Duration do Time to First Byte

Reduzir a Cache Duration do Time to First Byte

Este artigo faz parte do nosso guia sobre o Time to First Byte (TTFB). A cache duration é a segunda subparte do TTFB e representa o tempo que o navegador gasta verificando seu cache local e quaisquer service workers ativos para uma resposta correspondente. Embora a cache duration raramente seja o principal gargalo, entendê-la é importante para sites que usam service workers ou dependem fortemente de estratégias de caching do navegador.

O Time to First Byte (TTFB) pode ser dividido nas seguintes subpartes:

• Waiting + Redirect (ou waiting duration)
• Worker + Cache (ou cache duration)
• DNS (ou DNS duration)
• Connection (ou connection duration)
• Request (ou request duration)

Procurando otimizar o Time to First Byte? Este artigo cobre a parte de cache duration do Time to First Byte. Se você deseja entender ou corrigir o Time to First Byte e não sabe o que significa cache duration, leia o que é o Time to First Byte e corrigir e identificar problemas de Time to First Byte antes de começar este artigo.

Nota: geralmente a parte de Cache Duration do Time to First Byte não é um gargalo. Portanto, continue lendo se a) você estiver usando um service worker, ou b) você for um entusiasta de pagespeed como eu!

Geralmente, a subparte cache duration do Time to First Byte não é um gargalo e ocorrerá dentro de 10 a 20 ms. Ao usar um service worker, um tempo aceitável é inferior a 60ms.

Como os Service Workers Afetam o Time to First Byte?

Os service workers podem ter um impacto tanto positivo quanto negativo no Time to First Byte (TTFB), mas apenas para websites que usam Service Workers.

Aqui está como os service workers afetam o TTFB:

Desaceleram o TTFB por causa do Tempo de Inicialização do Service Worker: O valor workerStart representa o tempo que um Service Worker leva para inicializar, caso um esteja presente para o recurso solicitado. Este tempo de inicialização está incluído no cálculo do TTFB. Se um Service Worker precisar ser iniciado ou retomado de um estado terminado, ele pode adicionar um atraso ao tempo de resposta inicial e aumentar o TTFB.

Aceleram o TTFB por caching: Ao usar uma estratégia de caching como stale-while-revalidate, um service worker pode servir conteúdo diretamente do cache, se disponível. Isso leva a um TTFB quase instantâneo para recursos acessados com frequência, já que o navegador não precisa esperar por uma resposta do servidor. Esta estratégia funciona melhor para conteúdo atualizado com pouca frequência, em vez de conteúdo gerado dinamicamente que requer informações atualizadas.

Aceleram o TTFB com app-shell: Para aplicações renderizadas no cliente, o modelo de app shell (onde um service worker entrega uma estrutura básica de página do cache e carrega o conteúdo dinamicamente depois) pode reduzir o TTFB para essa estrutura base a quase zero.

Desaceleram o TTFB com código não otimizado: Service workers complicados e ineficientes podem retardar o processo de busca no cache e, ao fazer isso, também retardar o TTFB.

Os service workers são ruins para a pagespeed? Não (geralmente) eles não são ruins de forma alguma. Embora os Service Workers possam inicialmente aumentar o TTFB devido ao tempo de inicialização, sua capacidade de interceptar solicitações de rede, gerenciar o caching e fornecer suporte offline pode levar a melhorias sérias de performance a longo prazo, especialmente para visitantes recorrentes de um site.

Estratégias de Caching de Service Worker

A estratégia de caching que seu service worker usa determina como ele equilibra velocidade e frescor. Cada estratégia tem implicações diferentes para a subparte cache duration do TTFB:

Cache-First (Cache com fallback para a rede)

O service worker verifica o cache primeiro. Se uma resposta em cache existir, ela é retornada imediatamente. Caso contrário, a solicitação vai para a rede. Esta estratégia entrega o TTFB mais rápido para recursos em cache, mas corre o risco de servir conteúdo obsoleto.

Melhor para: ativos estáticos, imagens, fontes e conteúdo que muda infrequente.

self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.match(event.request).then((cachedResponse) => {
      if (cachedResponse) {
        return cachedResponse;
      }
      return fetch(event.request).then((networkResponse) => {
        const cache = await caches.open('v1');
        cache.put(event.request, networkResponse.clone());
        return networkResponse;
      });
    })
  );
});

Network-First (Rede com fallback para o cache)

O service worker sempre tenta a rede primeiro. Se a solicitação de rede falhar (por exemplo, o usuário está offline), a versão em cache é servida. Esta estratégia garante conteúdo fresco quando a rede está disponível, mas não reduz o TTFB para usuários online.

Melhor para: respostas de API, conteúdo atualizado com frequência e páginas onde o frescor é crítico.

Stale-While-Revalidate

O service worker retorna a versão em cache imediatamente (TTFB rápido) enquanto simultaneamente busca uma versão atualizada da rede em segundo plano. A versão atualizada substitui a cópia em cache para a próxima visita. Este é frequentemente o melhor equilíbrio entre velocidade e frescor.

Melhor para: conteúdo que muda regularmente, mas não requer precisão em tempo real, como artigos de notícias, postagens de blog e listagens de produtos.

self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.open('v1').then((cache) => {
      return cache.match(event.request).then((cachedResponse) => {
        const fetchPromise = fetch(event.request).then((networkResponse) => {
          cache.put(event.request, networkResponse.clone());
          return networkResponse;
        });
        return cachedResponse || fetchPromise;
      });
    })
  );
});

Configuração do Cabeçalho Cache-Control

Embora a subparte cache duration do TTFB meça especificamente o tempo gasto nas buscas do service worker e do cache do navegador, cabeçalhos Cache-Control adequados determinam se o navegador precisa contatar o servidor. Cabeçalhos de cache corretos podem efetivamente ignorar todo o TTFB para visitantes recorrentes.

Aqui está uma configuração recomendada de Cache-Control para diferentes tipos de recursos:

# Páginas HTML (sempre revalidar)
Cache-Control: no-cache

# Ativos estáticos com hachage de conteúdo (cache permanente)
Cache-Control: public, max-age=31536000, immutable

# Imagens sem hachage de conteúdo (cache por 1 semana)
Cache-Control: public, max-age=604800

# Respostas de API (sem caching)
Cache-Control: no-store

Explicação das principais diretrizes:

• no-cache: o navegador deve revalidar com o servidor antes de usar uma cópia em cache. Isso não significa "não armazenar em cache"; significa "sempre verifique primeiro".
• no-store: o navegador não deve armazenar a resposta em cache de forma alguma. Use para conteúdo sensível ou altamente dinâmico.
• max-age: o número de segundos que a resposta pode ser servida do cache sem revalidação.
• immutable: diz ao navegador que o recurso nunca mudará. Combine isso com nomes de arquivos com hash de conteúdo (ex: style.a1b2c3.css) para ativos estáticos.
• public: permite que a resposta seja armazenada em cache por caches compartilhados (CDN, proxy). Use private para conteúdo específico do usuário.

Ao usar um CDN como o Cloudflare, você também pode configurar regras de edge caching. Veja nosso guia sobre como configurar o Cloudflare para performance para instruções detalhadas.

Back/Forward Cache (bfcache)

O back/forward cache (bfcache) é uma otimização do navegador que armazena um snapshot completo de uma página na memória quando o usuário navega para longe. Quando o usuário pressiona o botão de voltar ou avançar, a página é restaurada instantaneamente da memória, eliminando completamente o TTFB (e todas as outras métricas de carregamento).

Páginas servidas pelo bfcache mostram um TTFB de 0 milissegundos nos dados de RUM porque nenhuma solicitação de rede é feita. O navegador simplesmente restaura a página a partir de seu snapshot na memória.

Para garantir que suas páginas sejam elegíveis para o bfcache:

• Não use event listeners de unload (use pagehide em seu lugar).
• Não use Cache-Control: no-store no documento HTML.
• Feche todas as conexões IndexedDB abertas quando a página estiver oculta.
• Não mantenha conexões WebSocket ou WebRTC ativas (feche-as no evento pagehide).

Você pode testar a elegibilidade do bfcache no Chrome DevTools na aba Application, na seção "Back/Forward Cache". O Chrome listará quaisquer motivos pelos quais a página não foi elegível para o bfcache.

Para sites com padrões significativos de navegação de voltar/avançar (ex: páginas de categoria e de produto de e-commerce, páginas de resultados de pesquisa), o bfcache pode melhorar drasticamente o TTFB percebido para uma grande parte das navegações.

Como Medir a Subparte Cache Duration do Time to First Byte

Você pode medir a subparte cache duration do Time to First Byte com este snippet:

new PerformanceObserver((entryList) => {
  const [navigationEntry] = entryList.getEntriesByType('navigation');

  \/\/ obtém os timestamps relevantes
  const activationStart = navigationEntry.activationStart || 0;
  const waitEnd = Math.max(
    (navigationEntry.workerStart || navigationEntry.fetchStart) -
    activationStart,
    0,
  );
  const dnsStart = Math.max(
    navigationEntry.domainLookupStart - activationStart,
    0,
  );

  \/\/ calcula a cache duration
  const cacheDuration = dnsStart - waitEnd;

  \/\/ loga os resultados
  console.log('%cTTFB cacheDuration', 'color: blue; font-weight: bold;');
  console.log(cacheDuration);

}).observe({
  type: 'navigation',
  buffered: true
});

Como Encontrar Problemas de TTFB Causados por uma Cache Duration Alta

Para encontrar o impacto que os usuários reais experimentam causado pela cache duration, você precisará usar uma ferramenta de RUM como o CoreDash. O Real User Monitoring permitirá que você acompanhe os Core Web Vitals em grandes detalhes.

No CoreDash, basta navegar até "Time to First Byte" e visualizar os detalhes da decomposição. Isso mostrará a decomposição do TTFB em todas as suas subpartes e dirá exatamente quanto tempo a cacheDuration leva para o 75º percentil.

Como Minimizar o Impacto do Tempo de Cache do Service Worker

Para otimizar o TTFB ao usar Service Workers:

• Minimize a complexidade dos scripts do Service Worker para reduzir o tempo de inicialização.
• Implemente estratégias de caching eficientes dentro do Service Worker (prefira stale-while-revalidate para solicitações de navegação).
• Considere o pré-caching de recursos críticos durante a instalação do Service Worker.
• Monitore e analise regularmente o impacto dos Service Workers no TTFB do seu site.
• Use navigation preload para permitir que a solicitação de rede aconteça em paralelo com a inicialização do service worker. Isso evita que o tempo de boot do service worker seja adicionado ao TTFB.

Ative o navigation preload no seu service worker com:

self.addEventListener('activate', (event) => {
  event.waitUntil(
    (async () => {
      if (self.registration.navigationPreload) {
        await self.registration.navigationPreload.enable();
      }
    })()
  );
});

Acerte a implementação e os service workers acelerarão seu site para visitantes recorrentes. Erre e cada carregamento de página pagará o custo do boot.

Leitura Adicional: Guias de Otimização

Guias relacionados:

• 103 Early Hints: comece a carregar recursos críticos antes que a resposta do servidor esteja pronta, complementando sua estratégia de caching.
• Configurar Cloudflare para Performance: configure edge caching de CDN, regras de cache e regras de página para otimizar sua estratégia de caching no nível de edge.

Subpartes do TTFB: Guias Completos

A cache duration é uma das cinco subpartes do TTFB. Explore as outras subpartes para entender o quadro completo:

• Corrigir e Identificar Problemas de TTFB: o ponto de partida de diagnóstico para toda a otimização de TTFB.
• Waiting Duration: redirecionamentos, enfileiramento do navegador e otimização de HSTS.
• DNS Duration: seleção de provedor de DNS, configuração de TTL e dns-prefetch.
• Connection Duration: TCP handshake, otimização de TLS, HTTP/3 e preconnect.
• Request Duration: tempo de processamento do servidor, consultas ao banco de dados e otimização de backend.