--- title: API do Service Worker slug: Web/API/Service_Worker_API translation_of: Web/API/Service_Worker_API ---
{{ServiceWorkerSidebar}}
Essencialmente, um service worker se comporta como um servidor proxy situado entre uma aplicação web, o navegador e a rede (quando esta estiver disponível). Eles servem, dentre outras coisas, para possibilitar a criação de experiências offline eficientes, interceptar requisições de rede – agindo adequadamente de acordo com o status atual da conexão – e atualizar os assets que residem no servidor. Service workers também permitem o acesso às APIs de push notification e background sync.
Um service worker é um tipo especial de worker baseado em eventos, o qual é registrado para um determinado path e origem. Na prática, ele é um arquivo JavaScript que pode controlar as páginas do site ao qual ele está associado, interceptando e modificando requisições e a navegação em si. Ele também faz cache dos recursos trafegados de maneira bastante granular, visando oferecer controle total sobre como a sua aplicação se comporta em determinadas situações (o exemplo mais óbvio, naturalmente, é quando não há conexão de rede disponível).
Assim como outros tipos de worker, um service worker é executado em um contexto isolado. Dessa forma, não tem acesso ao DOM e roda em uma thread completamente separada, sendo incapaz de realizar operações blocantes. Service workers foram projetados para ser totalmente assíncronos; como consequência disso, não permitem o acesso a APIs como XHR síncrono e localStorage.
Por questões de segurança, service workers funcionam apenas em sites servidos via HTTPS. A possibilidade de modificar requisições em um domínio desprotegido contra ataques do tipo man-in-the-middle seria desastrosa. No Firefox, é vetado o acesso à API de service workers para sites abertos no Modo de navegação privativa.
Nota: Os service workers superaram tentativas anteriores de resolver problemas semelhantes, como o AppCache. Há uma explicação simples para eles terem sido bem-sucedidos: Service workers não tentam adivinhar o que você está tentando fazer e, muito menos, deixam de funcionar caso não tenham adivinhado corretamente. Pelo contrário, você tem o controle milimétrico de tudo.
Nota: Service workers fazem uso intenso de promessas, uma vez que eles têm de esperar por respostas assíncronas para, após retornadas, poderem executar a ação apropriada (de sucesso ou erro). A arquitetura de promessas é ideal para esse tipo de cenário.
O registro inicial de um service worker é feito através do método {{domxref("ServiceWorkerContainer.register()")}}. Se bem-sucedido, seu service worker será descarregado no cliente e então ocorrerá a tentativa de instalação/ativação para as URLs acessadas pelo usuário sob a origem registrada ou, caso deseje, apenas dentro de um subconjunto limitado por você.
Nesse estágio, seu service worker seguirá o seguinte ciclo de vida:
Quando o usuário acessa pela primeira vez um site ou página controlado por um service worker, ele é descarregado imediatamente.
Após isso, serão feitos novos downloads em intervalos de aproximadamente 24 horas. O download pode ocorrer mais frequentemente, mas ele precisa ser feito a cada 24 horas para prevenir que scripts ruins sejam um problema por períodos muito extensos.
A tentativa de instalação é feita sempre que o arquivo descarregado é identificado como novo – seja por diferir dos service workers pré-existentes (é feita uma comparação binária nessa etapa) ou por ser o primeiro descoberto para a página ou site em questão.
Na primeira vez que um service worker é disponibilizado, é feita a tentativa de instalação. Se bem-sucedida, ele é ativado.
Se, por outro lado, já existe um service worker pré-instalado para uma página ou site e for disponibilizada uma nova versão, ela será descarregada, mas não imediatamente ativada. Isso é chamado de worker em espera. Só será efetuada a ativação da versão atualizada quando não houver mais páginas utilizando a anterior. Após isso, ele passa a ser o worker ativo. Caso necessário, é possível pular a etapa de espera com o método {{domxref("ServiceWorkerGlobalScope.skipWaiting()")}}. Em seguida, o novo worker ativo pode reivindicar as páginas existentes usando {{domxref("Clients.claim()")}}.
Você pode adicionar um listener para o evento {{domxref("InstallEvent")}}. Uma ação padrão, quando esse evento é disparado, é preparar o seu service worker para ser utilizado (por exemplo: criado um cache usando a API de storage nativa e armazenando nela os assets que você quer que permaneçam disponíveis caso a aplicação fique offline).
Há também o evento activate
. O momento em que ele é disparado é geralmente o ideal para limpar caches antigos e outras coisas associadas com a versão anterior do seu service worker.
Seu service worker pode responder a requisições usando o {{domxref("FetchEvent")}}. Você pode manipular a resposta a essas requisições da maneira que quiser, através do método {{domxref("FetchEvent.respondWith")}}.
Nota: Como oninstall e
onactivate
podem demorar a serem concluídos, a especificação de service workers disponibiliza um método waitUntil. Ele recebe como parâmetro uma promessa, notificando o navegador que há trabalho em andamento até que aquela promessa seja resolvida. O navegador, portanto, não deverá encerrar o service worker durante esse período de espera.
Para um tutorial completo, mostrando como construir seu primeiro exemplo do zero, leia Usando Service Workers.
No futuro, service workers serão capazes de fazer várias outras coisas úteis para a plataforma web, deixando-a mais próxima de apps nativos em.
É interessante mencionar que outras especificações podem e irão passar a usar o contexto de service workers, por exemplo:
install
e activate
disparados no {{domxref("ServiceWorkerGlobalScope")}}, como parte do ciclo de vida do service worker. Isso garante que qualquer evento funcional (como o {{domxref("FetchEvent")}}) não seja despachado para o {{domxref("ServiceWorker")}} até que ele conclua as ações em andamento, como por exemplo: atualizar esquemas de banco de dados, apagar caches defasados, etc.FetchEvent
representa uma ação de descarregamento que é despachada no {{domxref("ServiceWorkerGlobalScope")}} de um {{domxref("ServiceWorker")}}. Ele contém informações sobre a requisição e a resposta resultante, além de disponibilizar o método {{domxref("FetchEvent.respondWith", "FetchEvent.respondWith()")}}, o qual nos permite devolver uma resposta customizada para a página que está sendo controlada.InstallEvent
representa uma ação de instalação que é despachada no {{domxref("ServiceWorkerGlobalScope")}} de um {{domxref("ServiceWorker")}}. Como deriva do {{domxref("ExtendableEvent")}}, ele assegura que eventos funcionais, como o {{domxref("FetchEvent")}}, não sejam despachados durante a instalação. NotificationEvent
representa um evento de click em uma notificação que é despachado no {{domxref("ServiceWorkerGlobalScope")}} de um {{domxref("ServiceWorker")}}.ServiceWorker
.ServiceWorker
.A interface SyncEvent representa uma ação de sincronização que é despachada no {{domxref("ServiceWorkerGlobalScope")}} de um ServiceWorker.
Especificação | Status | Comentário |
---|---|---|
{{SpecName('Service Workers')}} | {{Spec2('Service Workers')}} | Initial definition. |
{{ CompatibilityTable() }}
Recurso | Chrome | Edge | Firefox (Gecko) | Internet Explorer | Opera | Safari (WebKit) |
---|---|---|---|---|---|---|
Suporte básico | {{CompatChrome(40)}} | {{CompatNo}}[1] | {{ CompatGeckoDesktop("44.0") }}[2] | {{ CompatNo() }} | 24 | {{ CompatNo() }}[3] |
Eventos install/activate | {{ CompatChrome(40) }} | {{CompatNo}}[1] | {{ CompatGeckoDesktop("44.0") }}[2] | {{ CompatNo() }} | {{ CompatVersionUnknown() }} | {{ CompatNo() }} |
Evento fetch/request/respondWith() |
{{CompatChrome(40)}} | {{CompatNo}}[1] | {{ CompatGeckoDesktop("44.0") }}[2] | {{ CompatNo() }} | {{ CompatNo() }} | {{ CompatNo() }} |
caches/cache |
{{CompatChrome(42)}} |
{{CompatNo}}[1] | {{ CompatGeckoDesktop("39.0") }}[2] | {{ CompatNo() }} | {{ CompatNo() }} | {{ CompatNo() }} |
{{domxref("ServiceWorkerMessageEvent")}} defasado em favor {{domxref("MessageEvent")}} |
{{CompatChrome(57)}} |
{{ CompatNo() }} | {{ CompatGeckoDesktop("55.0") }}[2] | {{ CompatNo() }} | {{ CompatNo() }} | {{ CompatNo() }} |
NavigationPreloadManager |
{{CompatChrome(59)}} | {{ CompatNo() }} | {{ CompatNo() }} | {{CompatOpera(46)}} | {{ CompatNo() }} |
Recursos | Android Webview | Chrome for Android | Edge | Firefox Mobile (Gecko) | IE Phone | Opera Mobile | Safari Mobile |
---|---|---|---|---|---|---|---|
Suporte básico | {{ CompatNo() }} | {{CompatChrome(40)}} | {{CompatNo}}[1] | {{ CompatGeckoMobile("44.0") }} | {{ CompatNo() }} | {{ CompatVersionUnknown() }} | {{ CompatNo() }}[3] |
Eventos install/activate | {{ CompatNo() }} | {{CompatChrome(40)}} | {{CompatNo}}[1] | {{ CompatGeckoMobile("44.0") }} | {{ CompatNo() }} | {{ CompatVersionUnknown() }} | {{ CompatNo() }} |
Evento fetch/request/respondWith() |
{{ CompatNo() }} | {{CompatChrome(40)}} | {{CompatNo}}[1] | {{ CompatGeckoMobile("44.0") }} | {{ CompatNo() }} | {{ CompatNo() }} | {{ CompatNo() }} |
caches/cache | {{ CompatNo() }} | {{CompatChrome(40)}} | {{CompatNo}}[1] | {{ CompatGeckoMobile("39.0") }} | {{ CompatNo() }} | {{ CompatNo() }} | {{ CompatNo() }} |
{{domxref("ServiceWorkerMessageEvent")}} defasado em favor de {{domxref("MessageEvent")}} | {{ CompatNo() }} |
{{CompatChrome(57)}} |
{{ CompatNo() }} | {{ CompatGeckoMobile("55.0") }} | {{ CompatNo() }} | {{ CompatNo() }} | {{ CompatNo() }} |
NavigationPreloadManager |
{{ CompatNo() }} | {{CompatChrome(59)}} | {{ CompatNo() }} | {{ CompatNo() }} | {{ CompatNo() }} | {{CompatOperaMobile(46)}} | {{ CompatNo() }} |
[1] Esse recurso ainda não é suportado, apesar de já estar em desenvolvimento.
[2] Service workers (e Push) foram desabilitados no Firefox, nas versões 45 & 52 Extended Support Releases (ESR.)
[3] Esse recurso ainda não é suportado, apesar de já estar em desenvolvimento.