Reduza a Subparte Cache Duration do Time to First Byte

Reduza o Cache Duration do Time to First Byte

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

Buscando otimizar o Time to First Byte? Este artigo cobre a parte de cache duration do Time to First Byte. Se você está procurando entender ou corrigir o Time to First Byte e não sabe o que significa o cache duration, por favor leia o que é o Time to First Byte e corrija e identifique problemas de Time to First Byte antes de começar com este artigo.

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

Normalmente, a subparte cache duration do Time to First Byte não é um gargalo e ocorrerá entre 10 e 20 ms. Ao usar um service worker, um tempo aceitável é abaixo de 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 sites que usam Service Workers.

Veja como os service workers afetam o TTFB:

Desaceleram o TTFB devido ao Tempo de Inicialização do Service Worker: O valor workerStart representa o tempo que leva para um Service Worker iniciar, caso haja um presente para o recurso solicitado. Esse tempo de inicialização é 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 meio do cache: Ao usar uma estratégia de cache 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, pois o navegador não precisa esperar por uma resposta do servidor. Essa 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 app shell (onde um service worker entrega uma estrutura de página básica 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 em cache e, ao fazê-lo, também desacelerar o TTFB.

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

Estratégias de Cache de Service Worker

A estratégia de cache 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 Rede)

O service worker verifica o cache primeiro. Se houver uma resposta em cache, ela será retornada imediatamente. Caso contrário, a solicitação irá para a rede. Essa estratégia oferece 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 com pouca frequência.

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 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. Essa estratégia garante conteúdo atualizado 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 busca simultaneamente 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 costuma ser o melhor equilíbrio entre velocidade e frescor.

Melhor para: conteúdo que muda regularmente, mas não exige precisão em tempo real, como artigos de notícias, posts de blog e listas 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 em buscas no cache do navegador e no service worker, os cabeçalhos Cache-Control adequados determinam se o navegador precisa ou não entrar em contato com o servidor. Cabeçalhos de cache corretos podem efetivamente contornar 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 hash de conteúdo (cache para sempre)
Cache-Control: public, max-age=31536000, immutable

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

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

Principais diretivas explicadas:

• no-cache: o navegador deve revalidar com o servidor antes de usar uma cópia em cache. Isso não significa "não fazer cache"; significa "sempre verificar primeiro".
• no-store: o navegador não deve armazenar a resposta em cache de forma alguma. Use isso para conteúdo sensível ou altamente dinâmico.
• max-age: o número de segundos que a resposta pode ser servida a partir do cache sem revalidação.
• immutable: informa ao navegador que o recurso nunca mudará. Combine isso com nomes de arquivo 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 uma CDN como a Cloudflare, você também pode configurar regras de cache de borda (edge caching). Veja nosso guia sobre como configurar a Cloudflare para desempenho para obter 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 fora dela. 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 qualquer outra métrica de carregamento).

As páginas servidas do 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 de seu snapshot em memória.

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

• Não use event listeners de unload (use pagehide em vez disso).
• Não use Cache-Control: no-store no documento HTML.
• Feche quaisquer conexões IndexedDB abertas quando a página for ocultada.
• 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 categorias e produtos em e-commerce, páginas de resultados de busca), 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');

  // obter 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,
  );

  // calcular o cache duration
  const cacheDuration = dnsStart - waitEnd;

  // registrar 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 um Cache Duration Alto

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

No CoreDash, simplesmente navegue até "Time to First Byte" e visualize os detalhes do detalhamento (breakdown). Isso mostrará a você o detalhamento do TTFB em todas as suas subpartes e dirá exatamente quanto tempo o 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 cache eficientes dentro do Service Worker (prefira stale-while-revalidate para solicitações de navegação).
• Considere o pré-cache 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 o 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 inicialização do service worker seja adicionado ao TTFB.

Habilite o navigation preload em 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 de inicialização.

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 cache.
• Configure Cloudflare for Performance: configure edge caching de CDN, regras de cache e regras de página para otimizar sua estratégia de cache em nível de borda.

Subpartes do TTFB: Guias Completos

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

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