--- title: Service Worker API slug: Web/API/Service_Worker_API tags: - API - Landing - NeedsTranslation - Offline - Overview - Reference - Service Workers - TopicStub - Workers translation_of: Web/API/Service_Worker_API ---
{{ServiceWorkerSidebar}}
Los Service workers actúan esencialmente como proxy servers asentados entre las aplicaciones web, el navegador y la red (cuando está accesible). Están destinados, entre otras cosas, a permitir la creación de experiencias offline efectivas, interceptando peticiones de red y realizando la acción apropiada si la conexión de red está disponible y hay disponibles contenidos actualizados en el servidor. También permitirán el acceso a notificaciones tipo push y APIs de sincronización en segundo plano.
Un service worker es un worker manejado por eventos registrado para una fuente y una ruta. Consiste en un fichero JavaScript que controla la página web (o el sitio) con el que está asociado, interceptando y modificando la navegación y las peticiones de recursos, y cacheando los recursos de manera muy granular para ofrecer un control completo sobre cómo la aplicación debe comportarse en ciertas situaciones (la mas obvia es cuando la red no está disponible).
Un service worker se ejecuta en un contexto worker: por lo tanto no tiene acceso al DOM, y se ejecuta en un hilo distinto al JavaScript principal de la aplicación, de manera que no es bloqueante. Está diseñado para ser completamente asíncrono, por lo que APIs como el XHR asíncrono y localStorage no se pueden usar dentro de un service worker.
Los service workers solo funcionan sobre HTTPS, por razones de seguridad. Modificar las peticiones de red en abierto permitiría ataques man in the middle realmente peligrosos. En Firefox, las APIs de service worker se ocultan y no pueden ser empleadas cuando el usuario está en modo de navegación en privado.
Nota: Los Service Workers mejoran los intentos anteriores en este área tal como AppCache puesto que no hacen suposiciones sobre qué se está intentando hacer para luego tener que cortar cuando las suposiciones no son correctas; hay control granular sobre todos los aspectos.
Nota: Los Service workers hace un uso intensivo de las promesas, por lo que generalmente esperarán a que lleguen las respuestasas correspondientes, tras lo cual responderán con una acción de éxito o de fracaso. La arquitectura de promesas es ideal en este caso.
Un service worker se registra primero mediante el método {{domxref("ServiceWorkerContainer.register()")}}. Si ha habido éxito, el service worker se descargará al cliente e intentará la instalación/activación (ver más abajo) de las URLs accedidas por el usuario dentro de todo su origen de datos, o dentro de algún subconjunto especificado por el autor.
En este punto, su service worker observará el siguiente ciclo de vida:
El service worker se descaga inmediatamente cuando un usuario accede por primera vez a un sitio controlado por el mismo.
Después de esto se descarga cada 24 horas aproximadamente. Se puede descargar con más frecuencia, pero debe ser descargado cada 24 horas para prevenir que una mala programación sea molesta durante mucho tiempo.
La instalación se realiza cuando el fichero descargado es nuevo, es decir, diferente a otro service worker existente (comparado byte a byte), o si es el primero descargado para esta página/sitio.
Si es la primera vez que el service worker está disponible se intenta la instalación, y tras una instalación satisfactoria se activa.
Si ya existe un service worker disponible la nueva versión se instala en segundo plano, pero no se activa -en ese momento se llama worker in waiting. Sólo se activa cuando ya no hay más páginas cargadas que utilicen el antiguo service worker. En cuanto no hay más páginas de este estilo cargadas, el nuevo service worker se activa (pasando a ser el active worker). La activación se puede realizar antes mediante {{domxref("ServiceWorkerGlobalScope.skipWaiting()")}} y las páginas existentes se pueden llamar por el active worker usando {{domxref("Clients.claim()")}}.
Presta atención a {{domxref("InstallEvent")}}; es habitual preparar tu service worker para usarlo cuando se dispara, por ejemplo creando una caché que utilice la API incorporada de almacenamiento, y colocando los contenidos dentro de ella para poder usarlos con la aplicación offline.
También hay un evento activate
. El momento en el que este evento se activa es, en general, un bueno momento para limpiar viejas cachés y demás cosas asociadas con la versión previa de tu service worker.
Tu service worker puede responder a las peticiones usando el evento {{domxref("FetchEvent")}}. Puedes modificar la respuesta a estas peticiones de la manera que quieras, usando el método {{domxref("FetchEvent.respondWith") }}.
Nota: Dado que oninstall
/onactivate
puede tardar un poco en completarse, la especificación de service worker spec provee un método waitUntil
que, cuando es llamado oninstall
o onactivate
, pasa una promesa. Los eventos funcionales no se envían al service worker hasta que la promesa se resuelve con éxito.
Para un tutorial completo que muestra cómo construir tu primer ejemplo básico, lee Using Service Workers.
Los service workers también pueden usarse para cosas como:
En el futuro, los service workers podrán hacer una cantidad de cosas útiles para la plataforma web que estarán muy próximos a las aplicaciones nativas. Interesantement, otras especificacions pueden comenzar y lo harán a hacer uso del contexto de service worker, por ejemplo:
install
y activate
lanzados en {{domxref("ServiceWorkerGlobalScope")}} como parte del ciclo de vida del service worker. Esto asegura que cualquier evento funcional (como {{domxref("FetchEvent")}}) no se despachan al {{domxref("ServiceWorker")}} hasta que actualiza los esquemas de base de datos, borra entradas de caché antiguas, etc.FetchEvent
representa una acción de consulta (fetch) despachada en el {{domxref("ServiceWorkerGlobalScope")}} de un {{domxref("ServiceWorker")}}. Contiene información sobre la petición y respuesta resultante, y proporciona el método {{domxref("FetchEvent.respondWith", "FetchEvent.respondWith()")}}, que nos permite proporcionar una respuesta arbitraria a la página controlada.InstallEvent
representa una acctión de instalación realizada en el {{domxref("ServiceWorkerGlobalScope")}} de un {{domxref("ServiceWorker")}}. Como hijo de {{domxref("ExtendableEvent")}}, asegura que los eventos funcionales como {{domxref("FetchEvent")}} no se llevan a cabo durante la instalación. NotificationEvent
representa una notificación del evento click ejecutado en {{domxref("ServiceWorkerGlobalScope")}} de un {{domxref("ServiceWorker")}}.ServiceWorker
.El interfaz SyncEvent representa una acción sync ejecutada en el {{domxref("ServiceWorkerGlobalScope")}} de un ServiceWorker.
Specification | Status | Comment |
---|---|---|
{{SpecName('Service Workers')}} | {{Spec2('Service Workers')}} | Definición inicial. |
Feature | Chrome | Edge | Firefox (Gecko) | Internet Explorer | Opera | Safari (WebKit) |
---|---|---|---|---|---|---|
Basic support | {{CompatChrome(40.0)}} | {{CompatNo}}[1] | {{ CompatGeckoDesktop("44.0") }}[2] | {{ CompatNo() }} | 24 | {{ CompatNo() }} |
install/activate events | {{ CompatChrome(40.0) }} | {{CompatNo}}[1] | {{ CompatGeckoDesktop("44.0") }}[2] | {{ CompatNo() }} | {{ CompatVersionUnknown() }} | {{ CompatNo() }} |
fetch event/request/respondWith() |
{{CompatChrome(40.0)}} | {{CompatNo}}[1] | {{ CompatGeckoDesktop("44.0") }}[2] | {{ CompatNo() }} | {{ CompatNo() }} | {{ CompatNo() }} |
caches/cache |
{{CompatChrome(42.0)}} |
{{CompatNo}}[1] | {{ CompatGeckoDesktop("39.0") }}[2] | {{ CompatNo() }} | {{ CompatNo() }} | {{ CompatNo() }} |
{{domxref("ServiceWorkerMessageEvent")}} deprecated in favour of {{domxref("MessageEvent")}} |
{{CompatChrome(57.0)}} |
{{ CompatNo() }} | {{ CompatGeckoDesktop("55.0") }}[2] | {{ CompatNo() }} | {{ CompatNo() }} | {{ CompatNo() }} |
Feature | Android Webview | Chrome for Android | Edge | Firefox Mobile (Gecko) | IE Phone | Opera Mobile | Safari Mobile |
---|---|---|---|---|---|---|---|
Basic support | {{ CompatNo() }} | {{CompatChrome(40.0)}} | {{CompatNo}}[1] | {{ CompatGeckoMobile("44.0") }} | {{ CompatNo() }} | {{ CompatVersionUnknown() }} | {{ CompatNo() }} |
install/activate events | {{ CompatNo() }} | {{CompatChrome(40.0)}} | {{CompatNo}}[1] | {{ CompatGeckoMobile("44.0") }} | {{ CompatNo() }} | {{ CompatVersionUnknown() }} | {{ CompatNo() }} |
fetch event/request/respondWith() |
{{ CompatNo() }} | {{CompatChrome(40.0)}} | {{CompatNo}}[1] | {{ CompatGeckoMobile("44.0") }} | {{ CompatNo() }} | {{ CompatNo() }} | {{ CompatNo() }} |
caches/cache | {{ CompatNo() }} | {{CompatChrome(40.0)}} | {{CompatNo}}[1] | {{ CompatGeckoMobile("39.0") }} | {{ CompatNo() }} | {{ CompatNo() }} | {{ CompatNo() }} |
{{domxref("ServiceWorkerMessageEvent")}} deprecated in favour of {{domxref("MessageEvent")}} | {{ CompatNo() }} |
{{CompatChrome(57.0)}} |
{{ CompatNo() }} | {{ CompatGeckoMobile("55.0") }} | {{ CompatNo() }} | {{ CompatNo() }} | {{ CompatNo() }} |
[1] Esta característica aún no está soportada, aunque está ya en desarrollo.
[2] Service workers (y Push) han sido inhabilitados en Firefox 45 & 52 Extended Support Releases (ESR.)