Acelerar o service worker com pré-carregamentos de navegação

Com a pré-carga de navegação, é possível superar o tempo de inicialização do service worker fazendo solicitações em paralelo.

Jake Archibald

Resumo

• Em algumas situações, o tempo de inicialização do service worker pode atrasar uma resposta de rede.
• Disponível nos três principais mecanismos de navegador, a pré-carga de navegação corrige isso permitindo que você faça a solicitação em paralelo com a inicialização do service worker.
• É possível distinguir solicitações de pré-carregamento de navegações regulares usando um cabeçalho e veicular conteúdo diferente.

O problema

Quando você navega até um site que usa um service worker para processar eventos de busca, o navegador pede uma resposta ao service worker. Isso envolve inicializar o service worker (se ele ainda não estiver em execução) e despachar o evento de busca.

O tempo de inicialização depende do dispositivo e das condições. Normalmente, esse tempo é de cerca de 50 ms. Em dispositivos móveis, esse tempo é de 250 ms. Em casos extremos (dispositivos lentos, CPU em dificuldades), pode ser mais de 500 ms. No entanto, como o service worker permanece ativo por um tempo determinado pelo navegador entre os eventos, esse atraso só ocorre ocasionalmente, como quando o usuário navega até seu site em uma nova guia ou em outro site.

O tempo de inicialização não é um problema se você estiver respondendo do cache, já que o benefício de ignorar a rede é maior do que o atraso na inicialização. Mas se você estiver respondendo usando a rede…

A solicitação de rede é atrasada pela inicialização do service worker.

Continuamos reduzindo o tempo de inicialização usando o cache de código no V8, pulando service workers que não têm um evento de busca, iniciando service workers especulativamente e outras otimizações. No entanto, o tempo de inicialização será sempre maior que zero.

O Facebook chamou nossa atenção para o impacto desse problema e pediu uma maneira de fazer solicitações de navegação em paralelo:

Pré-carregamento de navegação para o resgate

A pré-carga de navegação é um recurso que permite dizer: "Quando o usuário fizer uma solicitação de navegação GET, inicie a solicitação de rede enquanto o service worker está sendo inicializado".

O atraso na inicialização ainda existe, mas não bloqueia a solicitação de rede, então o usuário recebe o conteúdo mais rápido.

Confira um vídeo dele em ação, em que o service worker recebe um atraso de inicialização deliberado de 500 ms usando um loop while:

Confira a demonstração. Para aproveitar os benefícios do pré-carregamento de navegação, você precisa de um navegador compatível.

Ativar o pré-carregamento de navegação

addEventListener('activate', event => {   event.waitUntil(async function() {     // Feature-detect     if (self.registration.navigationPreload) {       // Enable navigation preloads!       await self.registration.navigationPreload.enable();     }   }()); }); 

Você pode chamar navigationPreload.enable() quando quiser ou desativar com navigationPreload.disable(). No entanto, como seu evento fetch precisa usar esse recurso, é melhor ativá-lo e desativá-lo no evento activate do service worker.

Usar a resposta pré-carregada

Agora o navegador vai fazer pré-carregamentos para navegações, mas você ainda precisa usar a resposta:

addEventListener('fetch', event => {   event.respondWith(async function() {     // Respond from the cache if we can     const cachedResponse = await caches.match(event.request);     if (cachedResponse) return cachedResponse;      // Else, use the preloaded response, if it's there     const response = await event.preloadResponse;     if (response) return response;      // Else try the network.     return fetch(event.request);   }()); }); 

event.preloadResponse é uma promessa que é resolvida com uma resposta se:

• O pré-carregamento de navegação está ativado.
• A solicitação é GET.
• A solicitação é de navegação (que os navegadores geram ao carregar páginas, incluindo iframes).

Caso contrário, event.preloadResponse ainda estará lá, mas será resolvido com undefined.

Respostas personalizadas para pré-carregamentos

Se a página precisar de dados da rede, a maneira mais rápida é solicitar no service worker e criar uma única resposta transmitida que contenha partes do cache e partes da rede.

Digamos que queremos mostrar um artigo:

addEventListener('fetch', event => {   const url = new URL(event.request.url);   const includeURL = new URL(url);   includeURL.pathname += 'include';    if (isArticleURL(url)) {     event.respondWith(async function() {       // We're going to build a single request from multiple parts.       const parts = [         // The top of the page.         caches.match('/article-top.include'),         // The primary content         fetch(includeURL)           // A fallback if the network fails.           .catch(() => caches.match('/article-offline.include')),         // The bottom of the page         caches.match('/article-bottom.include')       ];        // Merge them all together.       const {done, response} = await mergeResponses(parts);        // Wait until the stream is complete.       event.waitUntil(done);        // Return the merged response.       return response;     }());   } }); 

Acima, mergeResponses é uma pequena função que mescla os fluxos de cada solicitação. Isso significa que podemos mostrar o cabeçalho armazenado em cache enquanto o conteúdo da rede é transmitido.

Isso é mais rápido do que o modelo "app shell", porque a solicitação de rede é feita junto com a solicitação de página, e o conteúdo pode ser transmitido sem hacks importantes.

No entanto, a solicitação de includeURL será atrasada pelo tempo de inicialização do service worker. Também podemos usar a pré-carga de navegação para corrigir isso, mas, nesse caso, não queremos pré-carregar a página inteira, mas sim uma inclusão.

Para oferecer suporte a isso, um cabeçalho é enviado com cada solicitação de pré-carregamento:

Service-Worker-Navigation-Preload: true 

O servidor pode usar isso para enviar conteúdo diferente para solicitações de pré-carregamento de navegação do que faria para uma solicitação de navegação regular. Não se esqueça de adicionar um cabeçalho Vary: Service-Worker-Navigation-Preload para que os caches saibam que suas respostas são diferentes.

Agora podemos usar a solicitação de pré-carregamento:

// Try to use the preload const networkContent = Promise.resolve(event.preloadResponse)   // Else do a normal fetch   .then(r => r || fetch(includeURL))   // A fallback if the network fails.   .catch(() => caches.match('/article-offline.include'));  const parts = [   caches.match('/article-top.include'),   networkContent,   caches.match('/article-bottom') ]; 

Mudar o cabeçalho

Por padrão, o valor do cabeçalho Service-Worker-Navigation-Preload é true, mas você pode definir o que quiser:

navigator.serviceWorker.ready.then(registration => {   return registration.navigationPreload.setHeaderValue(newValue); }).then(() => {   console.log('Done!'); }); 

Por exemplo, você pode definir como o ID da última postagem armazenada em cache localmente para que o servidor retorne apenas dados mais recentes.

Como acessar o estado

É possível pesquisar o estado da pré-carga de navegação usando getState:

navigator.serviceWorker.ready.then(registration => {   return registration.navigationPreload.getState(); }).then(state => {   console.log(state.enabled); // boolean   console.log(state.headerValue); // string }); 

Agradecemos a Matt Falkenhagen e Tsuyoshi Horo pelo trabalho nesse recurso e pela ajuda com este artigo. E um grande agradecimento a todos os envolvidos no esforço de padronização.