Estratégias de Cache no Frontend: Cache HTTP e Cache de Service Worker

No mundo do desenvolvimento web, otimizar o desempenho do site é primordial. Um site lento pode levar a usuários frustrados, taxas de rejeição mais altas e, em última análise, a um impacto negativo nos seus negócios. O cache, uma técnica para armazenar e reutilizar recursos previamente recuperados, desempenha um papel vital na melhoria da velocidade do site e na redução da carga do servidor. Este artigo oferece uma visão abrangente de duas estratégias-chave de cache no frontend: cache HTTP e cache de Service Worker.

Entendendo os Fundamentos do Cache

O cache envolve o armazenamento de cópias de recursos, como HTML, CSS, JavaScript, imagens e outros ativos, mais perto do usuário. Quando um usuário solicita um recurso, o navegador ou um intermediário de cache primeiro verifica se uma cópia em cache está disponível. Se estiver (um "cache hit"), o recurso é servido do cache, evitando uma viagem ao servidor de origem. Isso reduz significativamente a latência e melhora os tempos de carregamento.

Existem vários níveis de cache, incluindo cache do navegador, cache de proxy e cache do lado do servidor. Este artigo foca no cache do frontend, especificamente em como aproveitar o cache HTTP integrado do navegador e o mais avançado cache de Service Worker.

Cache HTTP: Aproveitando os Recursos do Navegador

O cache HTTP é o mecanismo integrado do navegador para armazenar e recuperar recursos. É controlado por cabeçalhos HTTP enviados pelo servidor na resposta a uma solicitação. Esses cabeçalhos fornecem instruções ao navegador sobre por quanto tempo armazenar um recurso em cache e sob quais condições ele deve ser considerado válido.

Principais Cabeçalhos de Cache HTTP

• Cache-Control: Este é o cabeçalho mais importante para controlar o cache HTTP. Ele permite que você especifique várias diretivas, como:
• max-age=segundos: Especifica o tempo máximo que um recurso é considerado novo. Após esse tempo, o navegador deve revalidar o cache com o servidor. Exemplo: Cache-Control: max-age=3600 (cache por 1 hora).
• s-maxage=segundos: Semelhante ao max-age, mas se aplica especificamente a caches compartilhados como CDNs. Exemplo: Cache-Control: max-age=3600, s-maxage=86400 (cache por 1 hora no navegador, 1 dia em uma CDN).
• public: Indica que a resposta pode ser armazenada em cache por qualquer cache, incluindo caches compartilhados.
• private: Indica que a resposta só pode ser armazenada em cache pelo navegador e não por caches compartilhados. Útil para dados específicos do usuário.
• no-cache: Força o navegador a revalidar o cache com o servidor antes de usá-lo, mesmo que ainda esteja novo.
• no-store: Impede o navegador de armazenar a resposta em cache.
• Expires: Um cabeçalho mais antigo que especifica uma data e hora absolutas quando o recurso expira. O Cache-Control geralmente substitui o Expires se ambos estiverem presentes. Exemplo: Expires: Wed, 21 Oct 2024 07:28:00 GMT
• ETag: Um identificador único para uma versão específica de um recurso. O navegador envia o ETag no cabeçalho da solicitação If-None-Match durante a revalidação. Se o recurso não mudou, o servidor retorna uma resposta 304 Not Modified, indicando que o navegador pode usar a versão em cache.
• Last-Modified: Indica a última vez que o recurso foi modificado. O navegador envia a data Last-Modified no cabeçalho da solicitação If-Modified-Since durante a revalidação. Semelhante ao ETag, o servidor pode retornar uma resposta 304 Not Modified se o recurso não tiver mudado.

Exemplos Práticos de Cache HTTP

Exemplo 1: Cache de ativos estáticos (imagens, CSS, JavaScript):

Para ativos estáticos que raramente mudam, você pode definir um valor max-age longo:

            Cache-Control: public, max-age=31536000  

            

              
                Copy
              
            
          

Isso informa ao navegador para armazenar o recurso em cache por um ano (31.536.000 segundos) e que ele pode ser armazenado por qualquer cache (public).

Exemplo 2: Cache de conteúdo dinâmico com revalidação:

Para conteúdo dinâmico que muda com mais frequência, você pode usar no-cache junto com ETag ou Last-Modified para revalidação:

            Cache-Control: no-cache, must-revalidate
ETag: "unique-etag-value"

            

              
                Copy
              
            
          

Isso força o navegador a revalidar o cache com o servidor antes de usá-lo. O servidor pode então usar o ETag para determinar se o recurso mudou e retornar uma resposta 304 Not Modified se não tiver mudado.

Exemplo 3: Servindo ativos versionados:

Uma prática comum é incluir um número de versão no nome do arquivo do ativo (por exemplo, style.v1.css). Quando o ativo muda, você atualiza o número da versão, forçando o navegador a baixar a nova versão. Isso permite que você armazene ativos em cache agressivamente sem se preocupar em servir conteúdo desatualizado.

Melhores Práticas para Cache HTTP

• Use uma CDN: Redes de Distribuição de Conteúdo (CDNs) distribuem o conteúdo do seu site por vários servidores geograficamente mais próximos dos usuários. Isso reduz a latência e melhora os tempos de carregamento, especialmente para usuários em diferentes partes do mundo. CDNs populares incluem Cloudflare, Akamai e Amazon CloudFront. Um site no Japão carregando imagens de um servidor na Europa se beneficiará muito de uma CDN com servidores na Ásia.
• Aproveite o cache do navegador: Configure seu servidor para enviar os cabeçalhos de cache HTTP apropriados para todos os seus recursos.
• Use técnicas de cache busting: Empregue técnicas como versionamento ou parâmetros de consulta para forçar os navegadores a baixar recursos atualizados quando eles mudam.
• Monitore o desempenho do cache: Use as ferramentas de desenvolvedor do navegador e análises do lado do servidor para monitorar as taxas de acerto do cache e identificar áreas para melhoria.

Cache de Service Worker: Controle Avançado e Capacidades Offline

Service Workers são arquivos JavaScript que rodam em segundo plano, separados da thread principal do navegador. Eles atuam como um proxy entre o navegador e a rede, permitindo que você intercepte solicitações de rede e implemente estratégias de cache avançadas.

Service Workers são uma tecnologia chave por trás dos Progressive Web Apps (PWAs), permitindo recursos como acesso offline, notificações push e sincronização em segundo plano.

Como os Service Workers Funcionam

1. Registro: O Service Worker é registrado pela sua página da web.
2. Instalação: O Service Worker é instalado no navegador. É aqui que você normalmente pré-armazena em cache os recursos essenciais.
3. Ativação: O Service Worker se torna ativo e começa a controlar as solicitações de rede para páginas dentro do seu escopo.
4. Interceptação: O Service Worker intercepta solicitações de rede e pode optar por servir recursos do cache, buscá-los na rede ou até mesmo criar uma resposta sintética.

APIs Chave do Service Worker para Cache

• API de Cache: Fornece um mecanismo para armazenar e recuperar respostas em cache. Permite criar caches nomeados e adicionar, atualizar e excluir entradas.
• API Fetch: Usada para fazer solicitações de rede a partir do Service Worker.
• addEventListener('install', ...): O manipulador de eventos que é executado quando o service worker é instalado pela primeira vez. Isso é comumente usado para pré-armazenar em cache ativos importantes.
• addEventListener('activate', ...): O manipulador de eventos que é executado quando o service worker se torna ativo. Isso é comumente usado para limpar caches antigos.
• addEventListener('fetch', ...): O manipulador de eventos que intercepta solicitações de rede. É aqui que a lógica de cache reside.

Estratégias de Cache com Service Workers

Os Service Workers permitem que você implemente várias estratégias de cache adaptadas a diferentes tipos de recursos e condições de rede. Aqui estão algumas estratégias comuns:

• Cache Primeiro (Cache First): Sempre sirva o recurso do cache se estiver disponível. Se não estiver no cache, busque-o na rede e armazene-o no cache para uso futuro. Isso é ideal para ativos estáticos que raramente mudam.
• Rede Primeiro (Network First): Sempre tente buscar o recurso da rede primeiro. Se a rede estiver disponível, sirva o recurso e atualize o cache. Se a rede não estiver disponível, sirva o recurso do cache. Isso é adequado para conteúdo dinâmico que precisa estar o mais atualizado possível.
• Cache e Depois Rede (Cache, then Network): Sirva o recurso do cache imediatamente enquanto, simultaneamente, busca a versão mais recente da rede. Atualize o cache com a nova versão quando ela chegar. Isso proporciona um carregamento inicial rápido e garante que o usuário obtenha o conteúdo mais recente eventualmente.
• Obsoleto Durante a Revalidação (Stale-While-Revalidate): Sirva o recurso do cache imediatamente. Em segundo plano, busque a versão mais recente da rede e atualize o cache. Na próxima vez que o recurso for solicitado, a versão atualizada será servida. Essa estratégia proporciona um carregamento inicial rápido e garante que o usuário sempre obtenha a versão mais recente eventualmente, sem bloquear a solicitação inicial.
• Apenas Rede (Network Only): Sempre busque o recurso da rede. Nunca use o cache. Isso é apropriado para recursos que nunca devem ser armazenados em cache, como dados sensíveis do usuário.
• Apenas Cache (Cache Only): Sempre sirva o recurso do cache. Nunca o busque na rede. Isso é útil para cenários onde você quer garantir que o recurso esteja sempre disponível offline.

Exemplos Práticos de Cache com Service Worker

Exemplo 1: Estratégia Cache Primeiro (Cache First) para ativos estáticos:

            self.addEventListener('fetch', event => {
  event.respondWith(
    caches.match(event.request)
      .then(response => {
        // Cache hit - retorna a resposta
        if (response) {
          return response;
        }

        // Não está no cache - busca na rede
        return fetch(event.request).then(
          response => {
            // Verifica se recebemos uma resposta válida
            if (!response || response.status !== 200 || response.type !== 'basic') {
              return response;
            }

            // IMPORTANTE: Clone a resposta. Uma resposta é um stream
            // e como queremos que o navegador consuma a resposta
            // assim como o cache consome a resposta, precisamos
            // cloná-la.
            const responseToCache = response.clone();

            caches.open('my-site-cache')
              .then(cache => {
                cache.put(event.request, responseToCache);
              });

            return response;
          }
        );
      })
  );
});

            

              
                Copy
              
            
          

Este trecho de código demonstra a estratégia Cache Primeiro. O Service Worker primeiro verifica se o recurso solicitado está disponível no cache. Se estiver, ele serve o recurso do cache. Se não estiver, ele busca o recurso na rede, armazena-o no cache e, em seguida, o serve ao navegador.

Exemplo 2: Estratégia Obsoleto Durante a Revalidação (Stale-While-Revalidate) para conteúdo dinâmico:

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

            

              
                Copy
              
            
          

Este trecho de código demonstra a estratégia Obsoleto Durante a Revalidação. O Service Worker serve o recurso do cache imediatamente. Em segundo plano, ele busca a versão mais recente da rede e atualiza o cache. Na próxima vez que o recurso for solicitado, a versão atualizada será servida.

Melhores Práticas para Cache com Service Worker

• Use uma biblioteca de estratégia de cache: Bibliotecas como o Workbox simplificam o desenvolvimento de Service Workers, fornecendo estratégias de cache pré-construídas e utilitários. Isso pode economizar tempo e esforço e garantir que sua lógica de cache seja robusta e confiável.
• Gerencie as versões do cache: Ao atualizar seu Service Worker, você precisa invalidar o cache antigo e criar um novo. Isso evita servir recursos desatualizados. Use o evento activate para limpar caches antigos.
• Lide com erros de forma elegante: Implemente o tratamento de erros para lidar elegantemente com falhas de rede e perdas de cache. Forneça conteúdo de fallback ou informe ao usuário que o recurso não está disponível.
• Teste exaustivamente: Teste sua lógica de cache do Service Worker em diferentes condições de rede e ambientes de navegador para garantir que funcione como esperado. Use as ferramentas de desenvolvedor do navegador para inspecionar o cache e monitorar as solicitações de rede.
• Considere a experiência do usuário: Projete sua estratégia de cache com a experiência do usuário em mente. Forneça feedback ao usuário quando um recurso está sendo buscado da rede ou do cache. Evite servir conteúdo obsoleto por muito tempo.

Comparando Cache HTTP e Cache de Service Worker

Embora tanto o cache HTTP quanto o cache de Service Worker visem melhorar o desempenho do site, eles diferem em suas capacidades e casos de uso.

Considerações Globais para Cache

Ao implementar estratégias de cache para um público global, considere o seguinte:

• Condições de rede: Usuários em diferentes regiões podem experimentar velocidades e confiabilidade de rede variadas. Adapte sua estratégia de cache para acomodar essas diferenças. Por exemplo, usuários em áreas com acesso à internet não confiável se beneficiarão muito de um suporte offline robusto.
• Cobertura da CDN: Escolha uma CDN com uma rede global de servidores para garantir que seu conteúdo seja entregue rapidamente aos usuários em todas as regiões. Verifique se a CDN possui Pontos de Presença (PoPs) em regiões críticas para o seu público.
• Privacidade de dados: Esteja ciente das regulamentações de privacidade de dados em diferentes países ao armazenar em cache dados específicos do usuário. Certifique-se de cumprir leis como GDPR e CCPA.
• Idioma e localização: Considere armazenar em cache versões localizadas do seu site para fornecer uma melhor experiência do usuário para usuários em diferentes idiomas e regiões.
• Invalidação de cache: Implemente uma estratégia confiável de invalidação de cache para garantir que os usuários sempre obtenham o conteúdo mais recente, mesmo quando ele muda com frequência. Preste atenção especial às atualizações de conteúdo localizado.

Conclusão

O cache no frontend é uma técnica essencial para otimizar o desempenho do site e melhorar a experiência do usuário. Ao aproveitar o cache HTTP e o cache de Service Worker, você pode reduzir significativamente os tempos de carregamento, diminuir a carga do servidor e fornecer acesso offline ao conteúdo do seu site. Considere cuidadosamente as necessidades específicas do seu site e seu público-alvo ao escolher e implementar estratégias de cache. Ao adotar as melhores práticas e monitorar continuamente o desempenho do seu cache, você pode garantir que seu site ofereça uma experiência rápida e confiável para usuários em todo o mundo.