Disponibilização

Um aspecto importante dos Progressive Web Apps é que eles são confiáveis. eles podem carregar recursos rapidamente, mantendo os usuários engajados e fornecendo feedback imediatamente, mesmo em más condições de rede. Como isso é possível? Graças ao evento fetch do service worker.

O evento de busca

Compatibilidade com navegadores

• 40,
• 17
• 44,00
• 11,1

Origem

O evento fetch permite interceptar todas as solicitações de rede feitas pelo PWA no escopo do service worker para solicitações de mesma origem e entre origens. Além da navegação e das solicitações de recursos, a busca em um service worker instalado permite que as visitas à página após o primeiro carregamento de um site sejam renderizadas sem chamadas de rede.

O gerenciador fetch recebe todas as solicitações de um app, incluindo URLs e cabeçalhos HTTP, e permite que o desenvolvedor do app decida como processá-las.

Seu service worker pode encaminhar uma solicitação para a rede, responder com uma resposta previamente armazenada em cache ou criar uma nova resposta. A escolha é sua. Veja um exemplo simples:

self.addEventListener("fetch", event => {
    console.log(`URL requested: ${event.request.url}`);
});

Cuidado : embora seja possível ter mais de um manipulador de eventos de busca por service worker, apenas um pode responder por solicitação. Por exemplo, você pode ter diferentes manipuladores que agirão em padrões de URL diferentes. Elas são executadas na ordem em que foram registradas, até que um deles chame respondWith().

Como responder a uma solicitação

Quando uma solicitação chega ao service worker, é possível fazer duas coisas: Você pode ignorá-lo, o que permite que ele vá para a rede, ou você pode responder a ele. Responder a solicitações de dentro do service worker é uma forma de escolher o que e como ele é retornado ao PWA, mesmo quando o usuário está off-line.

Para responder a uma solicitação recebida, chame event.respondWith() de dentro de um manipulador de eventos fetch, desta forma:

// fetch event handler in your service worker file
self.addEventListener("fetch", event => {
    const response = .... // a response or a Promise of response
    event.respondWith(response);
});

Chame respondWith() de forma síncrona e retorne um objeto Response. No entanto, não será possível chamar respondWith() depois que o manipulador de eventos de busca for concluído, como em uma chamada assíncrona. Se você precisar aguardar a resposta completa, transmita uma promessa ao respondWith() que será resolvida com uma resposta.

Como criar respostas

Graças à API Fetch, é possível criar respostas HTTP no código JavaScript. Essas respostas podem ser armazenadas em cache usando a API Cache Storage e retornadas como se vierem de um servidor da Web.

Para gerar uma resposta, crie um objeto Response, definindo o corpo e as opções dele, como status e cabeçalhos:

const simpleResponse = new Response("Body of the HTTP response");

const options = {
   status: 200,
   headers: {
    'Content-type': 'text/html'
   }
};
const htmlResponse = new Response("<b>HTML</b> content", options)

Aviso: tenha cuidado extra ao criar respostas com um código de buggy do service worker que pode levar a casos específicos e problemas difíceis de depurar, como a impossibilidade de o navegador carregar o documento HTML que renderiza seu PWA. Durante a depuração, você sempre pode usar o botão "Atualizar" do navegador com a tecla Shift pressionada, o que ignora o service worker. ou use o DevTools do service worker em navegadores compatíveis, como veremos em Ferramentas e depuração.

Como responder usando o cache

Agora que você sabe como disponibilizar respostas HTTP de um service worker, é hora de usar a interface de armazenamento em cache para armazenar recursos no dispositivo.

Você pode usar a API de armazenamento em cache para verificar se a solicitação recebida do PWA está disponível no cache e, se estiver, responda a respondWith() com ela. Para fazer isso, primeiro você precisa pesquisar no cache. A função match(), disponível na interface caches de nível superior, pesquisa todos os armazenamentos na sua origem ou em um único objeto de cache aberto.

A função match() recebe uma solicitação HTTP ou um URL como argumento e retorna uma promessa que é resolvida com a resposta associada à chave correspondente.

// Global search on all caches in the current origin
caches.match(urlOrRequest).then(response => {
   console.log(response ? response : "It's not in the cache");
});

// Cache-specific search
caches.open("pwa-assets").then(cache => {
  cache.match(urlOrRequest).then(response => {
    console.log(response ? response : "It's not in the cache");
  });
});

Ao usar match() com respondWith(), a promessa de correspondência vai ser resolvida com o item encontrado ou sem nada. Ela só será rejeitada se houver um problema que tenha impedido a conclusão da operação de pesquisa. Para gerar um erro se nenhum resultado for encontrado, inspecione os resultados antes de retornar uma resposta para respondWith().

Estratégias de armazenamento em cache

Veicular arquivos somente a partir do cache do navegador não se enquadra em todos os casos de uso. Por exemplo, o usuário ou o navegador pode remover o cache. É por isso que você deve definir suas próprias estratégias de envio de recursos para seu PWA. Você não está restrito a uma estratégia de armazenamento em cache. É possível definir diferentes para padrões de URL diferentes. Por exemplo, é possível ter uma estratégia para os recursos mínimos de interface, outra para chamadas de API e uma terceira para URLs de dados e imagens. Para fazer isso, leia event.request.url no ServiceWorkerGlobalScope.onfetch e analise-o usando expressões regulares ou um padrão de URL. Atualmente, não havia suporte para o padrão de URL em todas as plataformas.

As estratégias mais comuns são:

Priorizar cache

Procura uma resposta em cache primeiro e volta à rede se não for encontrada.

Priorizar a rede

Solicita primeiro uma resposta da rede e, se nenhuma for retornada, verifica a resposta no cache.

Desatualizado ao revalidar

Disponibiliza uma resposta do cache, enquanto que em segundo plano solicita a versão mais recente e a salva no cache para a próxima vez que o recurso for solicitado.

Somente rede

Sempre responde com uma resposta da rede ou erros. O cache nunca é consultado.

Somente cache

Sempre responde com uma resposta do cache ou erros. A rede nunca será consultada. Os recursos que serão veiculados com essa estratégia precisam ser adicionados ao cache antes de serem solicitados.

Armazenar em cache primeiro

Usando essa estratégia, o service worker procura a solicitação correspondente no cache e retorna a Resposta correspondente se ela estiver armazenada. Caso contrário, ele recupera a resposta da rede (opcionalmente, atualizando o cache para chamadas futuras). Se não houver uma resposta de cache ou de rede, a solicitação apresentará um erro. Como costuma ser mais rápido veicular recursos sem acessar a rede, essa estratégia prioriza a performance em vez da atualização.

Observação : lembre-se de que a interface de armazenamento em cache não retorna um objeto de resposta. A referência será undefined se a solicitação não for armazenada em cache.

self.addEventListener("fetch", event => {
   event.respondWith(
     caches.match(event.request)
     .then(cachedResponse => {
       // It can update the cache to serve updated content on the next request
         return cachedResponse || fetch(event.request);
     }
   )
  )
});

Rede em primeiro lugar

Essa estratégia é o espelho da estratégia Cache First. ele verifica se a solicitação pode ser atendida pela rede e, se não puder, tenta recuperá-la do cache. Como o cache primeiro. Se não houver uma resposta de rede nem de cache, a solicitação apresentará um erro. Receber a resposta da rede geralmente é mais lenta do que recebê-la do cache. Essa estratégia prioriza o conteúdo atualizado em vez do desempenho.

self.addEventListener("fetch", event => {
   event.respondWith(
     fetch(event.request)
     .catch(error => {
       return caches.match(event.request) ;
     })
   );
});

Desatualizado durante a revalidação

A estratégia desatualizada durante a revalidação retorna imediatamente uma resposta armazenada em cache e, em seguida, verifica se há uma atualização na rede, substituindo a resposta armazenada em cache, caso ela seja encontrada. Essa estratégia sempre faz uma solicitação de rede, porque mesmo que um recurso armazenado em cache seja encontrado, ela tentará atualizar o que estava no cache com o que foi recebido da rede para usar a versão atualizada na próxima solicitação. Portanto, essa estratégia oferece uma maneira de você se beneficiar da exibição rápida da estratégia de cache primeiro e atualizar o cache em segundo plano.

Observação : com essa estratégia, os recursos são atualizados em segundo plano. Isso significa que seus usuários não vão receber a nova versão dos recursos até a próxima solicitação desse caminho. Nesse momento, a estratégia verificará novamente se existe uma nova versão e o ciclo será repetido.

self.addEventListener('fetch', event => {
  event.respondWith(
    caches.match(event.request).then(cachedResponse => {
        const networkFetch = fetch(event.request).then(response => {
          // update the cache with a clone of the network response
          const responseClone = response.clone()
          caches.open(url.searchParams.get('name')).then(cache => {
            cache.put(event.request, responseClone)
          })
          return response
        }).catch(function (reason) {
          console.error('ServiceWorker fetch failed: ', reason)
        })
        // prioritize cached response over network
        return cachedResponse || networkFetch
      }
    )
  )
})

Cuidado : o corpo da resposta é um ReadableStream que só pode ser consumido uma vez. Isso significa que, se você chamar fetch() para entregar a resposta ao PWA porque o recurso não foi armazenado em cache, não será possível reutilizar a mesma resposta para atualizá-lo no cache. É necessário chamar Response.clone() para usá-la duas vezes.

Somente rede

A estratégia "Somente rede" é semelhante a como os navegadores se comportam sem um service worker ou a API Cache Storage. As solicitações só retornarão um recurso se ele puder ser buscado na rede. Isso geralmente é útil para recursos como solicitações de API somente on-line.

Somente cache

A estratégia de somente cache garante que as solicitações nunca cheguem à rede. todas as solicitações recebidas serão respondidas com um item de cache pré-preenchido. O código a seguir usa o manipulador de eventos fetch com o método match do armazenamento em cache para responder apenas ao cache:

self.addEventListener("fetch", event => {
   event.respondWith(caches.match(event.request));
});

Observação : com a estratégia somente cache, você armazena seus recursos em cache antes que precise deles, geralmente no manipulador de eventos install do service worker. Como essa estratégia nunca vai para a rede, esses recursos serão atualizados somente quando você atualizar o service worker e um novo evento install for disparado.

Estratégias personalizadas

As estratégias de armazenamento em cache acima são comuns, mas você é responsável pelo service worker e como as solicitações são tratadas. Se nenhum desses recursos funcionar para suas necessidades, crie suas próprias opções.

Por exemplo, é possível usar uma estratégia que prioriza a rede com um tempo limite para priorizar o conteúdo atualizado, mas somente se a resposta aparecer dentro de um limite definido por você. Você também pode mesclar uma resposta em cache com uma resposta de rede e criar uma resposta complexa do service worker.

Atualizando recursos

Manter os recursos em cache do seu PWA atualizados pode ser um desafio. Embora a estratégia desatualizada durante a revalidação seja uma maneira de fazer isso, ela não é a única. No capítulo Atualização, você vai aprender diferentes técnicas para manter o conteúdo e os recursos do seu app atualizados.

Recursos

• Buscar evento no MDN
• Manual off-line (em inglês)
• Correspondência de cache no MDN