Reduza a 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 de Time to First Byte (TTFB). A duração do cache é a segunda etapa do TTFB e representa o tempo que o navegador leva consultando o cache local e eventuais service workers ativos em busca de uma resposta correspondente. A duração do cache raramente é o principal gargalo, mas entendê-la é importante para sites que usam service workers ou dependem muito de estratégias de cache no navegador.

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

• Waiting + Redirect (ou duração de espera)
• Worker + Cache (ou duração do cache)
• DNS (ou duração de DNS)
• Connection (ou duração de conexão)
• Request (ou duração da requisição)

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

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

Geralmente, a etapa 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:

Atraso no TTFB pelo tempo de inicialização do service worker: O valor de workerStart representa o tempo necessário para iniciar um service worker, caso exista um para o recurso solicitado. Esse tempo de inicialização entra no cálculo do TTFB. Se um service worker precisar ser iniciado ou reativado a partir de um estado finalizado, ele pode acrescentar um atraso ao tempo de resposta inicial e aumentar o TTFB.

Aceleração do TTFB com cache: Ao usar uma estratégia de cache como stale-while-revalidate, o service worker pode entregar conteúdo direto do cache, se disponível. Isso gera um TTFB quase instantâneo para recursos acessados com frequência, já que o navegador não precisa esperar a resposta do servidor. Essa estratégia funciona melhor com conteúdos pouco atualizados do que com conteúdo gerado dinamicamente que exige dados em tempo real.

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

Atraso no TTFB por código não otimizado: Service workers complexos e ineficientes podem deixar o processo de busca no cache mais lento e, com isso, aumentar também o TTFB.

Service workers são ruins para o pagespeed? Não (em geral), de forma alguma. Embora service workers possam aumentar o TTFB no início devido ao tempo de inicialização, a capacidade que eles têm de interceptar requisições de rede, gerenciar cache e oferecer suporte offline pode gerar melhorias expressivas de performance no longo prazo, especialmente para visitantes que retornam ao site.

Estratégias de cache com service worker

A estratégia de cache usada pelo service worker define o equilíbrio entre velocidade e dados recentes. Cada estratégia traz implicações diferentes para a etapa de duração do cache do TTFB:

Cache-first (cache com fallback para a rede)

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

Ideal para: arquivos estáticos, imagens, fontes e conteúdos que mudam raramente.

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 (por exemplo, quando o usuário está offline), a versão em cache é entregue. Essa estratégia garante conteúdo atualizado quando a rede está disponível, mas não reduz o TTFB para usuários online.

Ideal para: respostas de API, conteúdos atualizados com frequência e páginas onde dados em tempo real são críticos.

Stale-while-revalidate

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

Ideal para: conteúdos que mudam com regularidade, 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

Embora a etapa de duração do cache do TTFB meça especificamente o tempo gasto em consultas ao service worker e ao cache do navegador, cabeçalhos Cache-Control adequados determinam se o navegador precisa sequer contatar o servidor. Cabeçalhos de cache corretos podem praticamente eliminar todo o TTFB para visitantes que retornam.

Veja uma configuração recomendada de Cache-Control para diferentes tipos de recursos:

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

# Arquivos estáticos com hash no conteúdo (cache permanente)
Cache-Control: public, max-age=31536000, immutable

# Imagens sem hash no 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 armazene em cache"; significa "sempre verifique primeiro".
• no-store: o navegador não deve armazenar a resposta em cache de forma alguma. Use para conteúdos confidenciais ou altamente dinâmicos.
• max-age: o número de segundos em que a resposta pode ser entregue a partir do cache sem revalidação.
• immutable: informa ao navegador que o recurso nunca mudará. Combine com nomes de arquivo com hash no conteúdo (por exemplo, style.a1b2c3.css) para arquivos estáticos.
• public: permite que a resposta seja armazenada em 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. Consulte nosso guia sobre como configurar a Cloudflare para performance para ver instruções detalhadas.

Back/forward cache (bfcache)

O back/forward cache (bfcache) é uma otimização do navegador que armazena um snapshot completo da página na memória quando o usuário sai dela. Quando o usuário clica nos botões voltar ou avançar, a página é restaurada instantaneamente da memória, eliminando por completo o TTFB (e qualquer outra métrica de carregamento).

Páginas entregues a partir 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 a partir do snapshot em memória.

Para garantir que as páginas sejam qualificadas para o bfcache:

• Não use listeners do evento unload (prefira pagehide).
• Não use Cache-Control: no-store no documento HTML.
• Feche qualquer conexão aberta do IndexedDB quando a página for ocultada.
• Não mantenha conexões WebSocket ou WebRTC ativas (feche-as no evento pagehide).

Você pode testar a qualificação para o bfcache no Chrome DevTools, na aba Application, dentro da seção "Back/Forward Cache". O Chrome listará todos os motivos pelos quais a página não foi qualificada para o bfcache.

Em sites com padrões expressivos de navegação voltar/avançar (por exemplo, páginas de categorias e de produtos em e-commerces ou páginas de resultados de busca), o bfcache pode melhorar drasticamente o TTFB percebido em uma parcela significativa das navegações.

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

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

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

  // captura 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 duração do cache
  const cacheDuration = dnsStart - waitEnd;

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

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

Como identificar problemas de TTFB causados por alta duração do cache

Para identificar o impacto da duração do cache sentido pelos usuários reais, você precisará de uma ferramenta de RUM como o CoreDash. O Real User Monitoring permite acompanhar os Core Web Vitals com grande nível de detalhes.

No CoreDash, basta navegar até "Time to First Byte" e ver os detalhes do detalhamento. Isso exibirá a divisão do TTFB em todas as etapas e informará exatamente quanto tempo o cacheDuration leva no percentil 75.

Como minimizar o impacto do service worker no tempo de cache

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 no service worker (prefira 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 com frequência 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 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 na implementação e os service workers deixarão o site mais rápido para visitantes recorrentes. Erre e todo carregamento de página pagará o custo do boot.

Leituras complementares: guias de otimização

Guias relacionados:

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

Etapas do TTFB: guias completos

A duração do cache é uma das cinco etapas do TTFB. Conheça as outras etapas para entender o cenário completo:

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