Reduza a parcela de duração do cache do Time to First Byte.

Reduza a duração do cache do Time to First Byte

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

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

• Espera + Redirecionamento (ou duração da espera)
• Worker + Cache (ou duração do cache)
• DNS (ou duração do DNS)
• Conexão (ou duração da conexão)
• Requisição (ou duração da requisição)

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

Nota: geralmente a parte de duração do cache do Time to First Byte não é um gargalo. Continue lendo se a) você usa um service worker, ou b) você é um entusiasta de pagespeed como eu!

Geralmente, a subparte de duração do cache do Time to First Byte não é um gargalo e ocorre entre 10 e 20 ms. Ao usar um service worker, um tempo aceitável é abaixo de 60 ms.

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 em sites que usam service workers.

Veja como os service workers afetam o TTFB:

Atrasam o TTFB devido ao tempo de inicialização do service worker: O valor workerStart representa o tempo que um service worker leva para iniciar caso exista um 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 encerrado, isso pode adicionar um atraso ao tempo de resposta inicial e aumentar o TTFB.

Aceleram o TTFB através do cache: Ao usar uma estratégia de cache como o stale-while-revalidate, um service worker pode servir o conteúdo diretamente do cache, se disponível. Isso resulta em um TTFB quase instantâneo para recursos acessados com frequência, já que o navegador não precisa esperar por uma resposta do servidor. Essa estratégia funciona melhor para conteúdos atualizados com pouca frequência, em vez de conteúdos gerados dinamicamente que exigem 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 básica de página a partir do cache e carrega o conteúdo dinamicamente depois) pode reduzir o TTFB dessa estrutura base para quase zero.

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

Os service workers são ruins para o pagespeed? Não, geralmente não são ruins. Embora os service workers possam inicialmente aumentar o TTFB devido ao tempo de inicialização, sua capacidade de interceptar requisições de rede, gerenciar o cache e fornecer suporte offline pode levar a grandes 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 o seu service worker usa determina como ele equilibra velocidade e atualização. Cada estratégia tem diferentes implicações para a subparte de duração do cache do TTFB:

Cache-First (Cache com fallback para a rede)

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

Melhor para: recursos estáticos, imagens, fontes e conteúdos que mudam 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 o cache)

O service worker sempre tenta a rede primeiro. Se a requisição de rede falhar (ex: 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údos atualizados com frequência e páginas onde a atualização é crítica.

Stale-While-Revalidate

O service worker retorna a versão em cache imediatamente (TTFB rápido) enquanto busca simultaneamente uma versão atualizada na rede em segundo plano. A versão atualizada substitui a cópia em cache para a próxima visita. Esse costuma ser o melhor equilíbrio entre velocidade e atualização.

Melhor para: conteúdos que mudam regularmente, mas não exigem precisão em tempo real, como artigos de notícias, posts 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

Enquanto a subparte de duração do cache do TTFB mede especificamente o tempo gasto nas buscas no cache do navegador e do service worker, cabeçalhos Cache-Control adequados determinam se o navegador precisa contatar 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

# Recursos 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 faça cache"; significa "sempre verifique primeiro".
• no-store: o navegador não deve armazenar a resposta em cache de forma alguma. Use isso para conteúdos sensíveis ou altamente dinâmicos.
• 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 arquivo com hash de conteúdo (ex: style.a1b2c3.css) para recursos estáticos.
• public: permite que a resposta seja armazenada por caches compartilhados (CDN, proxy). Use private para conteúdos específicos do usuário.

Ao usar uma CDN como a Cloudflare, você também pode configurar regras de edge caching. Veja nosso guia sobre como configurar a Cloudflare para desempenho 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 sai dela. Quando o usuário clica no 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 do bfcache mostram um TTFB de 0 milissegundos nos dados de RUM porque nenhuma requisiçã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 do IndexedDB abertas quando a página for ocultada.
• Não mantenha conexões ativas de WebSocket ou WebRTC (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á os 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 produto em e-commerces, páginas de resultados de busca), o bfcache pode melhorar drasticamente o TTFB percebido para grande parte das navegações.

Como medir a subparte de duração do cache do Time to First Byte

Você pode medir a subparte de duração do cache do Time to First Byte com este snippet:

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

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

  // calcule a duração do cache
  const cacheDuration = dnsStart - waitEnd;

  // registre 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 alta duração do cache

Para descobrir o impacto que os usuários reais experimentam devido à duração do cache, você precisará usar uma ferramenta de RUM como o CoreDash. O Real User Monitoring permitirá que você rastreie os Core Web Vitals com grande detalhe.

No CoreDash, basta navegar até "Time to First Byte" e visualizar os detalhes da divisão. Isso mostrará a divisão do TTFB em todas as suas subpartes e dirá exatamente quanto tempo o cacheDuration leva no 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 eficientes de cache dentro do service worker (prefira o stale-while-revalidate para requisições de navegação).
• Considere fazer 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 navigation preload para permitir que a requisição de rede ocorra em paralelo com a inicialização do service worker. Isso evita que o tempo de inicialização 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 na 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 complementar: 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.
• Configurar a Cloudflare para desempenho: configure o edge caching da CDN, regras de cache e regras de página para otimizar sua estratégia de cache no nível da borda.

Subpartes do TTFB: guias completos

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

• Identificar e corrigir problemas de TTFB: o ponto de partida de diagnóstico para todas as otimizações de TTFB.
• Duração da espera: redirecionamentos, filas do navegador e otimização de HSTS.
• Duração do DNS: seleção do provedor de DNS, configuração de TTL e dns-prefetch.
• Duração da conexão: handshake TCP, otimização de TLS, HTTP/3 e preconnect.
• Duração da requisição: tempo de processamento do servidor, consultas de banco de dados e otimização de backend.