Quais os benefícios em usar Web Worker e Service Worker na sua aplicação

Publicado por Leonardo Risch e Lucas Rinaldi no dia dev

Error Fonte

Durante os dias 26 e 27 de agosto, estivemos no evento BrazilJS - o maior evento sobre JavaScript do mundo - sediado em Porto Alegre (RS). Durante os dois dias, mais de 1500 pessoas participaram das discussões sobre o passado e o futuro do JavaScript e seus desdobramentos.

Um dos debates chamou nossa atenção: as vantagens e benefícios no uso de Service Workers e Web Workers. Nos próximos parágrafos, vamos explicar um pouco o que é e o que aprendemos de novo sobre a tecnologia.

Mas o que é Service Worker?

Service Worker é um worker onde podemos interceptar as requests de recurso e cache de uma página web, modificando-as para suportar determinadas interações, como quando a internet não está disponível (offline).

Um Service Worker roda assincronamente ao worker JavaScript que carrega a página. Com isso, ele não tem acesso ao DOM e nem ao local storage.

Aqui tem um vídeo muito explicativo que pode facilitar o entendimento de como o Service Worker funciona “por baixo dos panos”.


Jake Archibald e sua talk sobre como migrar um site para carregamento instantâneo offline

Na primeira talk do BrazilJS, um dos desenvolvedores do Google Chrome Jake Archibald começou falando sobre a velocidade de internet Lie-Fi - quando a mesma flutua de 4g para offline e o mobile nunca sabe se está conectado ou não. Archibald abriu a palestra com a seguinte reflexão:

“We should avoid treating online/offline as binary states.” - Jake Archibald

Segundo Jake, para mitigar problemas de velocidade em países que não possuem boas conexões de internet, podemos seguir o conceito offline-first. Funciona assim: o aplicativo assume que não tem conexão com a rede e faz uso somente de conteúdo local (e.g. cache, IndexedDB). A internet entra como um Progressive enhancement para aqueles que possuem o status de conexão bem sucedida.

Em seguida, Archibald exemplificou o funcionamento do Service Worker, apresentando um caso de uso onde se aplicaria bem o uso deste worker: um site totalmente online que gostaria de permitir aos usuários acesso offline para determinado conteúdo.

O modelo que o Jake utilizou, mostrou o funcionamento do Service Worker interceptando a requisição para uma página, consultando o cache e deixando como fallback caso a requisição da página não consiga ser concluída por falta de rede.

Durante a BrazilJS ficou claro que 2016 foi do offline-first e dos progressive web-apps. A cereja do bolo, porém, ficou por conta de uma demonstração de Web Streams. porém ainda faltou a cereja do bolo. Ainda no começo do ano, Jake havia dito que 2016 seria o ano dos web streams.

Web Streams

Archibald explica que ao replicar o modelo de single-page app shell a uma aplicação real e utilizada no dia-a-dia percebeu gargalos de performance devido ao carregamento de conteúdo dinamicamente.

Unindo Service Workers e Streams, Jake demonstrou como um single-page progressive web-app pode carregar em menos tempo que uma página HTML renderizada no servidor. Verifique no GIF abaixo a comparação entre tais tecnologias:

Render Performance

Comparação de performance: tempo para first-render / tempo para carregamento total do conteúdo.

Jake explicou que essas tecnologias não são bala-de-prata e levantou as seguintes questões que devem ser levadas em conta ao considerar streams e service worker para o seu app:

  1. Se o aplicativo é renderizado no servidor;
  2. Se o conteúdo inicial é carregado através da internet.
  3. E se conteúdos parciais são o suficiente para você (e.g. mostrar conteúdo above the fold).

Onde encontrar Streams?

Para quem quiser uma API madura para brincar com Streams, o conceito já é bem difundido dentro da plataforma Node.js. A comunidade possui materiais ricos sobre o assunto, como o Streams Handbook.

Já para a Web, a partir da versão 52 do Google Chrome a ReadableStream API estará disponível no Stable Channel. E caso queiram ler sobre o futuro das Web Streams a especificação está ativa e sendo desenvolvida.

A apresentação no geral foi muito positiva e instigou bastante a pensar onde, no nosso modelo de negócio, poderíamos usar esta estratégia e melhorar a experiência dos usuários. No final, Jake também compartilhou sua página onde ele oferece uma visualização de quais browser suportam Service Workers.


E sobre Web Worker?

Web worker é um JavaScript que roda em background, independente de outros scripts, sem afetar a performance da página. Este worker não afeta as demais ações possíveis na tela e nem outros scripts de manipulação de interação, enquanto é executado em paralelo.

Portanto o Web Worker é muito interessante quando precisa-se executar algum script sem interferir a interface para o usuário. Assim, melhora-se a sua experiência com a página. Você pode ver mais informações neste link.


Nolan explicando como Web Worker e Service Worker podem ser recursos interessantes para experiência do usuário

Em sua talk, Nolan Lawson, desenvolvedor do Microsoft Edge mostrou o quão perigoso para a experiência do usuário é utilizarmos scripts que podem bloquear o DOM.

Um ponto bastante enfatizado pelo Nolan foi sobre todas as possibilidades de bloquearmos o DOM, como por exemplo:

  • IndexedDB
  • Ajax
  • Garbage collection
  • JavaScript!

Mesmo neste exemplo simples, que o Nolan utilizou, já podemos ver como afeta diretamente o que a sua página está apresentando para o usuário. Com isso, a utilização do Web Worker no exemplo apresentado mostrou como a página fluiu perfeitamente e hoje em dia o Web Worker é suportado em praticamente todos navegadores.

Service Worker apareceu novamente nesta talk, mostrando a diferença em relação ao Web Worker e para quais contextos eles são apropriados.

Web Workers e Service Workers

Com isso ficou bastante claro que são coisas totalmente distintas e que podem se complementar dependendo da necessidade.

Conclusão

Nestas talks do BrazilJS vimos como podemos proporcionar melhor experiência para nossos usuários utilizando Service Worker e Web Worker. Um grande ganho foi ver que estes workers servem para contextos bem diferentes e como podemos tirar proveito desta tecnologia, tanto explorando o conceito de offline-first quanto melhorando o carregamento de animações dentro de nossas aplicações.

Fontes


Esses aprendizados foram de muita valia e só por este motivo já valeria a pena ir ao BrazilJS. Fiquem atentos ao Ship It! pois ainda teremos mais posts relacionado ao que vimos durante os dois dias de evento!

E você, foi no evento? O que achou dessas talks? Deixe seu comentário :)

Leonardo Risch

Leonardo Risch

Full Stack Developer

Lucas Rinaldi

Lucas Rinaldi

Front-end Developer

Comentários