Get to know MDN better
Esta página ha sido traducida del inglés por la comunidad. Aprende más y únete a la comunidad de MDN Web Docs.
Nota: Esta característica está disponible en Web Workers.
Los service workers actúan esencialmente como servidores proxy que se sitúan entre las aplicaciones web, el navegador y la red (cuando está disponible). Están destinados, entre otras cosas, a permitir la creación de experiencias offline efectivas, interceptar peticiones de red y realizar la acción apropiada según si la red está disponible y si hay contenidos actualizados en el servidor. También permiten el acceso a notificaciones push y APIs de sincronización en segundo plano.
Nota: Los service workers son un tipo de web worker. Consulte Web workers para información general sobre los tipos de workers y casos de uso.
Un service worker es un worker controlado por eventos, registrado para un origen y una ruta. Consiste en un archivo JavaScript que puede controlar la página web o sitio con el que está asociado, interceptando y modificando las peticiones de navegación y recursos, y almacenando en caché los recursos de manera muy granular para ofrecer un control completo sobre cómo se comporta la aplicación en ciertas situaciones (la más obvia es cuando la red no está disponible).
Los service workers se ejecutan en un contexto worker: por lo tanto, no tienen acceso al DOM y se ejecutan en un hilo distinto al JavaScript principal que alimenta la aplicación. Son no bloqueantes y están diseñados para ser completamente asíncronos. Como consecuencia, APIs como XHR síncrono y Web Storage no se pueden usar dentro de un service worker.
Los service workers no pueden importar módulos JavaScript dinámicamente, y import() lanzará un error si se invoca en el ámbito global de un service worker. Las importaciones estáticas usando la sentencia import sí están permitidas.
Los service workers solo están disponibles en contextos seguros: esto significa que su documento se sirve sobre HTTPS, aunque los navegadores también tratan http://localhost como un contexto seguro para facilitar el desarrollo local. Las conexiones HTTP son susceptibles a inyección de código malicioso mediante ataques de intermediario, y tales ataques podrían ser peores si se permitiera acceso a estas potentes APIs.
Nota: En Firefox, para realizar pruebas se pueden ejecutar service workers sobre HTTP (de forma insegura); simplemente marque la opción Habilitar Service Workers sobre HTTP (cuando la caja de herramientas esté abierta) en el menú de opciones/engranaje de las herramientas de desarrollo de Firefox.
Nota: A diferencia de intentos anteriores en esta área como AppCache, los service workers no hacen suposiciones sobre lo que se intenta hacer para luego fallar cuando esas suposiciones no son exactamente correctas. En su lugar, los service workers ofrecen un control mucho más granular.
Nota: Los service workers hacen un uso intensivo de las promesas, ya que generalmente esperarán a que lleguen las respuestas y luego responderán con una acción de éxito o fracaso. La arquitectura de promesas es ideal para esto.
Un service worker se registra primero mediante el método ServiceWorkerContainer.register(). Si tiene éxito, el service worker se descargará en el cliente e intentará la instalación/activación (ver más abajo) para las URLs accedidas por el usuario dentro de todo el origen, o un subconjunto especificado.
En este punto, el service worker seguirá el siguiente ciclo de vida:
El service worker se descarga inmediatamente cuando un usuario accede por primera vez a un sitio/página controlados por un service worker.
Después de eso, se actualiza cuando:
La instalación se intenta cuando el archivo descargado resulta ser nuevo, ya sea diferente a un service worker existente (comparado byte a byte), o el primer service worker encontrado para esta página/sitio.
Si es la primera vez que un service worker está disponible, se intenta la instalación; tras una instalación exitosa, se activa.
Si ya hay un service worker existente disponible, la nueva versión se instala en segundo plano, pero aún no se activa; en ese momento se le llama worker en espera. Solo se activa cuando ya no hay páginas cargadas que aún usen el service worker antiguo. En cuanto no quedan más páginas por cargar, el nuevo service worker se activa (convirtiéndose en el worker activo). La activación puede ocurrir antes usando ServiceWorkerGlobalScope.skipWaiting() y las páginas existentes pueden ser reclamadas por el worker activo usando Clients.claim().
Se puede escuchar el evento install; una acción estándar es preparar el service worker para su uso cuando se dispara, por ejemplo creando una caché usando la API de almacenamiento incorporada, y colocando dentro los recursos que se necesitarán para ejecutar la aplicación sin conexión.
También existe un evento activate. El momento en que se dispara este evento es generalmente un buen momento para limpiar cachés antiguas y otras cosas asociadas con la versión anterior del service worker.
El service worker puede responder a peticiones usando el evento FetchEvent. Se puede modificar la respuesta a estas peticiones de cualquier manera deseada, usando el método FetchEvent.respondWith().
Nota: Dado que los eventos install/activate pueden tardar un tiempo en completarse, la especificación de service workers proporciona un método waitUntil(). Una vez invocado en eventos install o activate con una promesa, los eventos funcionales como fetch y push esperarán hasta que la promesa se resuelva exitosamente.
Para un tutorial completo que muestra cómo construir un primer ejemplo básico, lea Uso de Service Workers.
Los service workers pueden incurrir en un costo de rendimiento innecesario: cuando una página se carga por primera vez después de un tiempo, el navegador tiene que esperar a que el service worker se inicie y ejecute para saber qué contenido cargar y si debe provenir de una caché o de la red.
Si ya se sabe de antemano de dónde deben obtenerse ciertos contenidos, se puede omitir el service worker por completo y obtener los recursos de forma inmediata. El método InstallEvent.addRoutes() se puede usar para implementar este caso de uso y más.
Los service workers también están pensados para usarse en cosas como:
En el futuro, los service workers podrán hacer varias cosas útiles para la plataforma web que la acercarán a la viabilidad de aplicaciones nativas. Resulta interesante que otras especificaciones pueden y van a empezar a hacer uso del contexto de service workers, por ejemplo:
Representa el almacenamiento para pares de objetos Request / Response que se almacenan en caché como parte del ciclo de vida del ServiceWorker.
CacheStorageRepresenta el almacenamiento para objetos Cache. Proporciona un directorio maestro de todas las cachés nombradas a las que puede acceder un ServiceWorker, y mantiene una correspondencia de nombres de cadena a los objetos Cache correspondientes.
ClientRepresenta el ámbito de un cliente de service worker. Un cliente de service worker es un documento en un contexto de navegador o un SharedWorker, controlado por un worker activo.
ClientsRepresenta un contenedor para una lista de objetos Client; la vía principal para acceder a los clientes de service worker activos en el origen actual.
ExtendableEventExtiende el tiempo de vida de los eventos install y activate despachados en el ServiceWorkerGlobalScope, como parte del ciclo de vida del service worker. Esto asegura que los eventos funcionales (como FetchEvent) no se despachan al ServiceWorker hasta que actualiza los esquemas de base de datos, elimina entradas de caché obsoletas, etc.
ExtendableMessageEventEl objeto de evento de un evento message disparado en un service worker (cuando se recibe un mensaje de canal en el ServiceWorkerGlobalScope desde otro contexto), extiende el tiempo de vida de tales eventos.
FetchEventEl parámetro pasado al controlador onfetch, FetchEvent representa una acción de fetch despachada en el ServiceWorkerGlobalScope de un ServiceWorker. Contiene información sobre la petición y la respuesta resultante, y proporciona el método FetchEvent.respondWith(), que permite proporcionar una respuesta arbitraria a la página controlada.
InstallEventEl parámetro pasado a la función controladora de un evento install, la interfaz InstallEvent representa una acción de instalación despachada en el ServiceWorkerGlobalScope de un ServiceWorker. Como hijo de ExtendableEvent, asegura que los eventos funcionales como FetchEvent no se despachan durante la instalación.
NavigationPreloadManagerProporciona métodos para gestionar la precarga de recursos con un service worker.
ServiceWorkerRepresenta un service worker. Múltiples contextos de navegación (por ejemplo, páginas, workers, etc.) pueden estar asociados con el mismo objeto ServiceWorker.
ServiceWorkerContainerProporciona un objeto que representa el service worker como una unidad global en el ecosistema de red, incluyendo servicios para registrar, dar de baja y actualizar service workers, y acceder al estado de los service workers y sus registros.
ServiceWorkerGlobalScopeRepresenta el contexto de ejecución global de un service worker.
ServiceWorkerRegistrationRepresenta un registro de service worker.
WindowClientRepresenta el ámbito de un cliente de service worker que es un documento en un contexto de navegador, controlado por un worker activo. Es un tipo especial de objeto Client, con algunos métodos y propiedades adicionales disponibles.
Devuelve el objeto CacheStorage asociado al contexto actual.
Navigator.serviceWorker y WorkerNavigator.serviceWorkerDevuelve un objeto ServiceWorkerContainer, que proporciona acceso al registro, eliminación, actualización y comunicación con los objetos ServiceWorker para el documento asociado.
| Service Workers Nightly |
This page was last modified on 15 abr 2026 by MDN contributors.
Your blueprint for a better internet.
Visit Mozilla Corporation’s not-for-profit parent, the Mozilla Foundation.
Portions of this content are ©1998–2026 by individual mozilla.org contributors. Content available under a Creative Commons license.