initial commit

2 files changed, 837 insertions, 0 deletions

diff --git a/files/es/web/api/service_worker_api/index.html b/files/es/web/api/service_worker_api/index.html
new file mode 100644
index 0000000000..8b0b05e252
--- /dev/null
+++ b/files/es/web/api/service_worker_api/index.html
@@ -0,0 +1,311 @@
+---
+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
+---
+<div>
+<p>{{ServiceWorkerSidebar}}</p>
+
+<p class="summary">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.</p>
+</div>
+
+<h2 id="Conceptos_y_uso_de_Service_worker">Conceptos y uso de Service worker</h2>
+
+<p>Un service worker es un <a href="https://developer.mozilla.org/en-US/docs/Web/API/Worker">worker</a> 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).</p>
+
+<p>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 <a href="/en-US/docs/Web/API/XMLHttpRequest">XHR</a> asíncrono y <a href="https://developer.mozilla.org/en-US/docs/Web/Guide/API/DOM/Storage">localStorage</a> no se pueden usar dentro de un service worker.</p>
+
+<p>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 <a href="https://support.mozilla.org/en-US/kb/private-browsing-use-firefox-without-history">modo de navegación en privado</a>.</p>
+
+<div class="note">
+<p><strong>Nota</strong>: Los Service Workers mejoran los intentos anteriores en este área tal como <a href="http://alistapart.com/article/application-cache-is-a-douchebag">AppCache</a> 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.</p>
+</div>
+
+<div class="note">
+<p><strong>Nota</strong>: Los Service workers hace un uso intensivo de las <a href="/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise">promesas</a>, 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.</p>
+</div>
+
+<h3 id="Registro">Registro</h3>
+
+<p>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.</p>
+
+<h3 id="Descarga_instalación_y_activación">Descarga, instalación y activación</h3>
+
+<p>En este punto, su service worker observará el siguiente ciclo de vida:</p>
+
+<ol>
+ <li>Descarga</li>
+ <li>Instalación</li>
+ <li>Activación</li>
+</ol>
+
+<p>El service worker se descaga inmediatamente cuando un usuario accede por primera vez a un sitio controlado por el mismo.</p>
+
+<p>Después de esto se descarga cada 24 horas aproximadamente. Se puede descargar con más frecuencia, pero <strong>debe</strong> ser descargado cada 24 horas para prevenir que una mala programación sea molesta durante mucho tiempo.</p>
+
+<p>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.</p>
+
+<p>Si es la primera vez que el service worker está disponible se intenta la instalación, y tras una instalación satisfactoria se activa.</p>
+
+<p>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 <em>worker in waiting.</em> 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 <em>active worker).</em> 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()")}}.</p>
+
+<p>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.</p>
+
+<p>También hay un evento <code>activate</code>. 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.</p>
+
+<p>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") }}.</p>
+
+<div class="note">
+<p><strong>Nota</strong>: Dado que <code>oninstall</code>/<code>onactivate</code> puede tardar un poco en completarse, la especificación de service worker spec provee un método <code>waitUntil</code> que, cuando es llamado <code>oninstall</code> o <code>onactivate</code>, pasa una promesa. Los eventos funcionales no se envían al service worker hasta que la promesa se resuelve con éxito.</p>
+</div>
+
+<p>Para un tutorial completo que muestra cómo construir tu primer ejemplo básico, lee <a href="/en-US/docs/Web/API/ServiceWorker_API/Using_Service_Workers">Using Service Workers</a>.</p>
+
+<h2 id="Otras_posibilidades">Otras posibilidades</h2>
+
+<p>Los service workers también pueden usarse para cosas como:</p>
+
+<ul>
+ <li>Sincronización de datos en background</li>
+ <li>Responder a peticiones de recursos desde otros orígenes</li>
+ <li>Recibir actualizaciones centralizadas de datos costosos de calcular tales como geolocalización o giroscopio, de manera que muchas páginas puedan hacer uso de un mismo conjunto de datos</li>
+ <li>Compilación Client-side y gestión de dependencias de CoffeeScript, less, CJS/AMD modules, etc. para desarrollo</li>
+ <li>Enlace para servicios en background </li>
+ <li>Plantillas personalizadas basadas en ciertos patrones URL </li>
+ <li>Mejoras de rendimiento, por ejemplo pre-fetching de recursos que es probable que el usuario requiera en un futuro próximo, como las próximas imágenes de un album de fotos.</li>
+</ul>
+
+<p>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:</p>
+
+<ul>
+ <li><a href="https://github.com/slightlyoff/BackgroundSync">Sincronización en background</a>: Pone en marcha un service worker aunque el usuario no esté en el sitio de manera que las cachés se puedan actualizar, etc.</li>
+ <li><a href="/en-US/docs/Web/API/Push_API">Reacción a mensajes tipo push</a>: Pone en marcha un service worker para enviar a los usuarios un mensaje para notificarles de que hay disponible nuevos contenidos.</li>
+ <li>Reacción ante una fecha y hora determinados.</li>
+ <li>Creación de geo-fronteras</li>
+</ul>
+
+<h2 id="Interfaces">Interfaces</h2>
+
+<dl>
+ <dt>{{domxref("Cache") }}</dt>
+ <dd>Representa el almacenamiento para un par de objetos {{domxref("Request")}} / {{domxref("Response")}} que son cacheados como parte del ciclo de vida de {{domxref("ServiceWorker")}}.</dd>
+ <dt>{{domxref("CacheStorage") }}</dt>
+ <dd>Representa el almacenamiento de objetos {{domxref("Cache")}}. Proporciona un directorio maestro de todos los nombres de caché a los que puede acceder un {{domxref("ServiceWorker")}} y mantiene un mapa de nombres (strings) correspondientes a objetos {{domxref("Cache")}}.</dd>
+ <dt>{{domxref("Client") }}</dt>
+ <dd>Representa el ámbito de un cliente service worker. Un cliente service worker es bien un documento en un contexto de navador, bien un {{domxref("SharedWorker")}}, que está controlado por un worker activo.</dd>
+ <dt>{{domxref("Clients") }}</dt>
+ <dd>Representa un contenedor para una lista de objetos {{domxref("Client")}}; principal vía de acceso de los clientes service worker al origen actual.</dd>
+ <dt>{{domxref("ExtendableEvent") }}</dt>
+ <dd>Extiende el tiempo de vida de los eventos<code>install</code> y <code>activate</code> 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.</dd>
+ <dt>{{domxref("ExtendableMessageEvent") }}</dt>
+ <dd>Es el objeto evento de un {{event("message_(ServiceWorker)","message")}} lanzado en un service worker (cuando se recibe un mensaje en el {{domxref("ServiceWorkerGlobalScope")}} desde otro contexto) — extiende el tiempo de vida de tales eventos.</dd>
+ <dt>{{domxref("FetchEvent") }}</dt>
+ <dd>Parametro pasado en el controlador {{domxref("ServiceWorkerGlobalScope.onfetch")}}, <code>FetchEvent</code> 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.</dd>
+ <dt>{{domxref("InstallEvent") }}</dt>
+ <dd>Parámetro pasado en el controlador {{domxref("ServiceWorkerGlobalScope.oninstall", "oninstall")}}, el interfaz<code>InstallEvent</code> 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. </dd>
+ <dt>{{domxref("Navigator.serviceWorker") }}</dt>
+ <dd>Devuelve un objeto {{domxref("ServiceWorkerContainer")}}, que proporciona acceso al registro, eliminación, actualización y comunicación con los objetos {{domxref("ServiceWorker")}} para el <a href="https://html.spec.whatwg.org/multipage/browsers.html#concept-document-window">documento asociado</a>.</dd>
+ <dt>{{domxref("NotificationEvent") }}</dt>
+ <dd>Parámetro pasado en el controlador {{domxref("ServiceWorkerGlobalScope.onnotificationclick", "onnotificationclick")}}, el interfaz <code>NotificationEvent</code> representa una notificación del evento click ejecutado en  {{domxref("ServiceWorkerGlobalScope")}} de un {{domxref("ServiceWorker")}}.</dd>
+ <dt>{{domxref("ServiceWorker") }}</dt>
+ <dd>Representa un service worker. Multiples contextos de navegación (e.g. pages, workers, etc.) se pueden asociar con el mismo objeto <code>ServiceWorker</code>.</dd>
+ <dt>{{domxref("ServiceWorkerContainer") }}</dt>
+ <dd>Proporciona un objeto que representa el service worker como una unidad en el ecosistema de red, incluyendo servicios para registrar, eliminar y actualizar los service workers, y acceder al estado de los service workers y sus registros.</dd>
+ <dt>{{domxref("ServiceWorkerGlobalScope") }}</dt>
+ <dd>Representa el contexto global de ejecución de un service worker.</dd>
+ <dt>{{domxref("ServiceWorkerMessageEvent")}} {{deprecated_inline}}</dt>
+ <dd>Representa un mensaje envaido a un{{domxref("ServiceWorkerGlobalScope")}}. <strong>Observese que este interfaz está considerado obsoleto en navegadores modernos. Los mensajes de service worker no podrán utilizar el interfaz {{domxref("MessageEvent")}}, por consistencia con otras características de mensajería web.</strong></dd>
+ <dt>{{domxref("ServiceWorkerRegistration") }}</dt>
+ <dd>Representa un registro service worker.</dd>
+ <dt>{{domxref("SyncEvent")}} {{non-standard_inline}}</dt>
+ <dd>
+ <p>El interfaz SyncEvent representa una acción sync ejecutada en el {{domxref("ServiceWorkerGlobalScope")}} de un ServiceWorker. </p>
+ </dd>
+ <dt>{{domxref("SyncManager")}} {{non-standard_inline}}</dt>
+ <dd>Proporciona un interfaz para registrar y listar registros sync.</dd>
+ <dt>{{domxref("WindowClient") }}</dt>
+ <dd>Representa el ámbito de un cliente service worker que es un documento en un contexto de navegador, controlado por un worker activo. Es un tipo especial de objeto {{domxref("Client")}}, con algunos métodos y propiedades adicionales disponibles.</dd>
+</dl>
+
+<h2 id="Especificaciones">Especificaciones</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Status</th>
+   <th scope="col">Comment</th>
+  </tr>
+  <tr>
+   <td>{{SpecName('Service Workers')}}</td>
+   <td>{{Spec2('Service Workers')}}</td>
+   <td>Definición inicial.</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Compatibilidad_de_navegadores">Compatibilidad de navegadores</h2>
+
+<div>{{ CompatibilityTable() }}</div>
+
+<div id="compat-desktop">
+<table class="compat-table">
+ <tbody>
+  <tr>
+   <th>Feature</th>
+   <th>Chrome</th>
+   <th>Edge</th>
+   <th>Firefox (Gecko)</th>
+   <th>Internet Explorer</th>
+   <th>Opera</th>
+   <th>Safari (WebKit)</th>
+  </tr>
+  <tr>
+   <td>Basic support</td>
+   <td>{{CompatChrome(40.0)}}</td>
+   <td>{{CompatNo}}<sup>[1]</sup></td>
+   <td>{{ CompatGeckoDesktop("44.0") }}<sup>[2]</sup></td>
+   <td>{{ CompatNo() }}</td>
+   <td>24</td>
+   <td>{{ CompatNo() }}</td>
+  </tr>
+  <tr>
+   <td>install/activate events</td>
+   <td>{{ CompatChrome(40.0) }}</td>
+   <td>{{CompatNo}}<sup>[1]</sup></td>
+   <td>{{ CompatGeckoDesktop("44.0") }}<sup>[2]</sup></td>
+   <td>{{ CompatNo() }}</td>
+   <td>{{ CompatVersionUnknown() }}</td>
+   <td>{{ CompatNo() }}</td>
+  </tr>
+  <tr>
+   <td>fetch event/request/<br>
+    <code>respondWith()</code></td>
+   <td>{{CompatChrome(40.0)}}</td>
+   <td>{{CompatNo}}<sup>[1]</sup></td>
+   <td>{{ CompatGeckoDesktop("44.0") }}<sup>[2]</sup></td>
+   <td>{{ CompatNo() }}</td>
+   <td>{{ CompatNo() }}</td>
+   <td>{{ CompatNo() }}</td>
+  </tr>
+  <tr>
+   <td>caches/cache</td>
+   <td>
+    <p class="p1">{{CompatChrome(42.0)}}</p>
+   </td>
+   <td>{{CompatNo}}<sup>[1]</sup></td>
+   <td>{{ CompatGeckoDesktop("39.0") }}<sup>[2]</sup></td>
+   <td>{{ CompatNo() }}</td>
+   <td>{{ CompatNo() }}</td>
+   <td>{{ CompatNo() }}</td>
+  </tr>
+  <tr>
+   <td>{{domxref("ServiceWorkerMessageEvent")}} deprecated in favour of {{domxref("MessageEvent")}}</td>
+   <td>
+    <p class="p1">{{CompatChrome(57.0)}}</p>
+   </td>
+   <td>{{ CompatNo() }}</td>
+   <td>{{ CompatGeckoDesktop("55.0") }}<sup>[2]</sup></td>
+   <td>{{ CompatNo() }}</td>
+   <td>{{ CompatNo() }}</td>
+   <td>{{ CompatNo() }}</td>
+  </tr>
+ </tbody>
+</table>
+</div>
+
+<div id="compat-mobile">
+<table class="compat-table">
+ <tbody>
+  <tr>
+   <th>Feature</th>
+   <th>Android Webview</th>
+   <th>Chrome for Android</th>
+   <th>Edge</th>
+   <th>Firefox Mobile (Gecko)</th>
+   <th>IE Phone</th>
+   <th>Opera Mobile</th>
+   <th>Safari Mobile</th>
+  </tr>
+  <tr>
+   <td>Basic support</td>
+   <td>{{ CompatNo() }}</td>
+   <td>{{CompatChrome(40.0)}}</td>
+   <td>{{CompatNo}}<sup>[1]</sup></td>
+   <td>{{ CompatGeckoMobile("44.0") }}</td>
+   <td>{{ CompatNo() }}</td>
+   <td>{{ CompatVersionUnknown() }}</td>
+   <td>{{ CompatNo() }}</td>
+  </tr>
+  <tr>
+   <td> install/activate events</td>
+   <td>{{ CompatNo() }}</td>
+   <td>{{CompatChrome(40.0)}}</td>
+   <td>{{CompatNo}}<sup>[1]</sup></td>
+   <td>{{ CompatGeckoMobile("44.0") }}</td>
+   <td>{{ CompatNo() }}</td>
+   <td>{{ CompatVersionUnknown() }}</td>
+   <td>{{ CompatNo() }}</td>
+  </tr>
+  <tr>
+   <td>fetch event/request/<br>
+    <code>respondWith()</code></td>
+   <td>{{ CompatNo() }}</td>
+   <td>{{CompatChrome(40.0)}}</td>
+   <td>{{CompatNo}}<sup>[1]</sup></td>
+   <td>{{ CompatGeckoMobile("44.0") }}</td>
+   <td>{{ CompatNo() }}</td>
+   <td>{{ CompatNo() }}</td>
+   <td>{{ CompatNo() }}</td>
+  </tr>
+  <tr>
+   <td>caches/cache</td>
+   <td>{{ CompatNo() }}</td>
+   <td>{{CompatChrome(40.0)}}</td>
+   <td>{{CompatNo}}<sup>[1]</sup></td>
+   <td>{{ CompatGeckoMobile("39.0") }}</td>
+   <td>{{ CompatNo() }}</td>
+   <td>{{ CompatNo() }}</td>
+   <td>{{ CompatNo() }}</td>
+  </tr>
+  <tr>
+   <td>{{domxref("ServiceWorkerMessageEvent")}} deprecated in favour of {{domxref("MessageEvent")}}</td>
+   <td>{{ CompatNo() }}</td>
+   <td>
+    <p class="p1">{{CompatChrome(57.0)}}</p>
+   </td>
+   <td>{{ CompatNo() }}</td>
+   <td>{{ CompatGeckoMobile("55.0") }}</td>
+   <td>{{ CompatNo() }}</td>
+   <td>{{ CompatNo() }}</td>
+   <td>{{ CompatNo() }}</td>
+  </tr>
+ </tbody>
+</table>
+</div>
+
+<p>[1] Esta característica aún no está soportada, aunque está  <a href="https://developer.microsoft.com/en-us/microsoft-edge/platform/status/serviceworker/">ya en desarrollo</a>.</p>
+
+<p>[2] Service workers (y <a href="/en-US/docs/Web/API/Push_API">Push</a>) han sido inhabilitados en <a href="https://www.mozilla.org/en-US/firefox/organizations/">Firefox 45 &amp; 52 Extended Support Releases</a> (ESR.)</p>
+
+<h2 id="Ver_también">Ver también</h2>
+
+<ul>
+ <li><a href="https://serviceworke.rs">ServiceWorker Cookbook</a></li>
+ <li><a href="/en-US/docs/Web/API/ServiceWorker_API/Using_Service_Workers">Using Service Workers</a></li>
+ <li><a href="https://github.com/mdn/sw-test">Service workers basic code example</a></li>
+ <li><a href="https://jakearchibald.github.io/isserviceworkerready/">Is ServiceWorker ready?</a></li>
+ <li><a href="https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise">Promises</a></li>
+ <li><a href="/en-US/docs/Web/Guide/Performance/Using_web_workers">Using web workers</a></li>
+ <li><a href="https://www.fastly.com/blog/best-practices-for-using-the-vary-header">Best Practices for using the VARY header</a></li>
+</ul>
diff --git a/files/es/web/api/service_worker_api/using_service_workers/index.html b/files/es/web/api/service_worker_api/using_service_workers/index.html
new file mode 100644
index 0000000000..d687cddd19
--- /dev/null
+++ b/files/es/web/api/service_worker_api/using_service_workers/index.html
@@ -0,0 +1,526 @@
+---
+title: Usando Service Workers
+slug: Web/API/Service_Worker_API/Using_Service_Workers
+tags:
+  - Guía
+  - básico
+translation_of: Web/API/Service_Worker_API/Using_Service_Workers
+---
+<p>{{ServiceWorkerSidebar}}</p>
+
+<p>{{ SeeCompatTable() }}</p>
+
+<div class="summary">
+<p>Este articulo provee información sobre cómo empezar con los service workers, incluyendo su arquitectura básica, el registro de un service worker, el proceso de instalación y activación de un nuevo service worker, cómo actualizar un service worker, controlar su cache y respuestas personalizadas, todo esto en el contexto de una simple aplicación con la capacidad de trabajar offline (sin internet).</p>
+</div>
+
+<h2 id="La_premisa_de_los_service_workers">La premisa de los service workers</h2>
+
+<p>Un problema primordial que los usuarios de la web han sufrido durante años es la pérdida de conectividad. La mejor aplicación web en el mundo ofrecerá una experiencia de usuario terrible si simplemente no se puede utilizar. Han habido varios intentos de crear tecnologías para resolver este problema, como muestra nuestra página <a href="https://developer.mozilla.org/en-US/Apps/Build/Offline">offline</a>, y algunos problemas han sido solucionados. Pero el problema primordial es que todavía no hay un mecanismo de control eficiente para el almacenamiento en caché de activos y solicitudes de red personalizadas.</p>
+
+<p>El mecanismo previamente utilizado -el AppCache- parecía una buena idea porque te permitía especificar los recursos que almacenarías en caché de una forma realmente fácil. Sin embargo, AppCache presuponía lo que el desarrollador trataba de crear y fallaba demasiado cuando la aplicación no se comportaba exactamente según las suposiciones iniciales. Veáse el artículo de Jake Archibald <a href="http://alistapart.com/article/application-cache-is-a-douchebag">Application Cache is a Douchebag</a> para más información.</p>
+
+<div class="note">
+<p><strong>Nota</strong>: A partir de Firefox 44, cuando se usa <a href="/en-US/docs/Web/HTML/Using_the_application_cache">AppCache</a> para proveer soporte offline a una página se muestra un mensaje de advertencia en la consola aconsejandole al desarrollador para que  use <a href="/en-US/docs/Web/API/Service_Worker_API/Using_Service_Workers">Service workers</a> en su lugar ({{bug("1204581")}}.)</p>
+</div>
+
+<p>Los Service workers deberían finalmente solucionar estos inconvenientes. Aunque la sintaxis de Service Worker es más compleja que la de AppCache, presenta la ventaja de que puede usar JavaScript para controlar los recursos de cache con gran detalle, permitiendo gestionar los problemas asociados a  AppCache, y muchos más.</p>
+
+<p>Al utilizar un Service Worker, puedes configurar fácilmente una aplicación para que utilice primero los recursos en caché antes de obtener alguna información de la red (Comunmente conocido como <a href="/es/docs/">Offline First</a>) lo que proporciona la experiencia de uso predeterminada incluso cuando se está offline. Este paradigma se usa en aplicaciones nativas, y es una de las principales razones por las que a menudo éstas se eligen por encima de las aplicaciones web.</p>
+
+<h2 id="Setting_up_to_play_with_service_workers">Setting up to play with service workers</h2>
+
+<p>Many service workers features are now enabled by default in newer versions of supporting browsers. If however you find that demo code is not working in your installed versions, you might need to enable a pref:</p>
+
+<ul>
+ <li><strong>Firefox Nightly</strong>: Go to <code>about:config</code> and set <code>dom.serviceWorkers.enabled</code> to true; restart browser.</li>
+ <li><strong>Chrome Canary</strong>: Go to <code>chrome://flags</code> and turn on <code>experimental-web-platform-features</code>; restart browser (note that some features are now enabled by default in Chrome.)</li>
+ <li><strong>Opera</strong>: Go to <code>opera://flags</code> and enable <code>Support for ServiceWorker</code>; restart browser.</li>
+</ul>
+
+<p>You’ll also need to serve your code via HTTPS — Service workers are restricted to running across HTTPS for security reasons. GitHub is therefore a good place to host experiments, as it supports HTTPS. In order to facilitate local development, <code>localhost</code> is considered a secure origin by browsers as well.</p>
+
+<h2 id="Basic_architecture">Basic architecture</h2>
+
+<p>With service workers, the following steps are generally observed for basic set up:</p>
+
+<ol>
+ <li>The service worker URL is fetched and registered via {{domxref("serviceWorkerContainer.register()")}}.</li>
+ <li>If successful, the service worker is executed in a {{domxref("ServiceWorkerGlobalScope") }}; this is basically a special kind of worker context, running off the main script execution thread, with no DOM access.</li>
+ <li>The service worker is now ready to process events.</li>
+ <li>Installation of the worker is attempted when service worker-controlled pages are accessed subsequently. An Install event is always the first one sent to a service worker (this can be used to start the process of populating an IndexedDB, and caching site assets). This is really the same kind of procedure as installing a native or Firefox OS app — making everything available for use offline.</li>
+ <li>When the <code>oninstall</code> handler completes, the service worker is considered installed.</li>
+ <li>Next is activation. When the service worker is installed, it then receives an activate event. The primary use of <code>onactivate</code> is for cleanup of resources used in previous versions of a Service worker script.</li>
+ <li>The Service worker will now control pages, but only those opened after the <code>register()</code> is successful. i.e. a document starts life with or without a Service worker and maintains that for its lifetime. So documents will have to be reloaded to actually be controlled.</li>
+</ol>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/12636/sw-lifecycle.png" style="display: block; height: 867px; margin: 0px auto; width: 579px;"></p>
+
+<p>The below graphic shows a summary of the available service worker events:</p>
+
+<p><img alt="install, activate, message, fetch, sync, push" src="https://mdn.mozillademos.org/files/12632/sw-events.png" style="display: block; margin: 0px auto;"></p>
+
+<h3 id="Promises">Promises</h3>
+
+<p>Las promesas (<a href="/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise">Promises</a>) son un gran mecanismo para ejecutar operaciones asíncronas,  con éxito dependiente el uno del otro. Esto es fundamental para la forma en que trabajan los service workers.<br>
+ <br>
+ Promises can do a great many things, but for now, all you need to know is that if something returns a promise, you can attach <code>.then()</code> to the end and include callbacks inside it for success, failure, etc., or you can insert <code>.catch()</code> on the end if you want to include a failure callback.</p>
+
+<p>Let’s compare a traditional synchronous callback structure to its asynchronous promise equivalent.</p>
+
+<h4 id="sync">sync</h4>
+
+<pre class="brush: js">try {
+  var value = myFunction();
+  console.log(value);
+} catch(err) {
+  console.log(err);
+}</pre>
+
+<h4 id="async">async</h4>
+
+<pre class="brush: js">myFunction().then(function(value) {
+  console.log(value);
+}).catch(function(err) {
+  console.log(err);
+});</pre>
+
+<p>In the first example, we have to wait for <code>myFunction()</code> to run and return <code>value</code> before any more of the code can execute. In the second example, <code>myFunction()</code> returns a promise for <code>value</code>, then the rest of the code can carry on running. When the promise resolves, the code inside <code>then</code> will be run, asynchronously.<br>
+ <br>
+ Now for a real example — what if we wanted to load images dynamically, but we wanted to make sure the images were loaded before we tried to display them? This is a standard thing to want to do, but it can be a bit of a pain. We can use <code>.onload</code> to only display the image after it’s loaded, but what about events that start happening before we start listening to them? We could try to work around this using <code>.complete</code>, but it’s still not foolproof, and what about multiple images? And, ummm, it’s still synchronous, so blocks the main thread.<br>
+ <br>
+ Instead, we could build our own promise to handle this kind of case. (See our <a href="https://github.com/mdn/promises-test">Promises test</a> example for the source code, or <a href="https://mdn.github.io/promises-test/">look at it running live</a>.)</p>
+
+<p>{{note("A real service worker implementation would use caching and onfetch rather than the deprecated XMLHttpRequest API. Those features are not used here so that you can focus on understanding Promises.")}}</p>
+
+<pre class="brush: js">function imgLoad(url) {
+  return new Promise(function(resolve, reject) {
+    var request = new XMLHttpRequest();
+    request.open('GET', url);
+    request.responseType = 'blob';
+
+    request.onload = function() {
+      if (request.status == 200) {
+        resolve(request.response);
+      } else {
+        reject(Error('Image didn\'t load successfully; error code:' + request.statusText));
+      }
+    };
+
+    request.onerror = function() {
+      reject(Error('There was a network error.'));
+    };
+
+    request.send();
+  });
+}</pre>
+
+<p>We return a new promise using the <code>Promise()</code> constructor, which takes as an argument a callback function with <code>resolve</code> and <code>reject</code> parameters. Somewhere in the function, we need to define what happens for the promise to resolve successfully or be rejected — in this case return a 200 OK status or not — and then call <code>resolve</code> on success, or <code>reject</code> on failure. The rest of the contents of this function is fairly standard XHR stuff, so we won’t worry about that for now.</p>
+
+<p>When we come to call the <code>imgLoad()</code> function, we call it with the url to the image we want to load, as we might expect, but the rest of the code is a little different:</p>
+
+<pre class="brush: js">var body = document.querySelector('body');
+var myImage = new Image();
+
+imgLoad('myLittleVader.jpg').then(function(response) {
+  var imageURL = window.URL.createObjectURL(response);
+  myImage.src = imageURL;
+  body.appendChild(myImage);
+}, function(Error) {
+  console.log(Error);
+});</pre>
+
+<p>On to the end of the function call, we chain the promise <code>then()</code> method, which contains two functions — the first one is executed when the promise successfully resolves, and the second is called when the promise is rejected. In the resolved case, we display the image inside <code>myImage</code> and append it to the body (it’s argument is the <code>request.response</code> contained inside the promise’s <code>resolve</code> method); in the rejected case we return an error to the console.</p>
+
+<p>This all happens asynchronously.</p>
+
+<div class="note">
+<p><strong>Note</strong>: You can also chain promise calls together, for example:<br>
+ <code>myPromise().then(success, failure).then(success).catch(failure);</code></p>
+</div>
+
+<div class="note">
+<p><strong>Note</strong>: You can find a lot more out about promises by reading Jake Archibald’s excellent <a href="http://www.html5rocks.com/en/tutorials/es6/promises/">JavaScript Promises: there and back again</a>.</p>
+</div>
+
+<h2 id="Service_workers_demo">Service workers demo</h2>
+
+<p>To demonstrate just the very basics of registering and installing a service worker, we have created a simple demo called <a href="https://github.com/mdn/sw-test">sw-test</a>, which is a simple Star wars Lego image gallery. It uses a promise-powered function to read image data from a JSON object and load the images using Ajax, before displaying the images in a line down the page. We’ve kept things static and simple for now. It also registers, installs, and activates a service worker, and when more of the spec is supported by browsers it will cache all the files required so it will work offline!</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/8243/demo-screenshot.png" style="display: block; height: 410px; margin: 0px auto; width: 480px;"><br>
+ <br>
+ <br>
+ You can see the <a href="https://github.com/mdn/sw-test/">source code on GitHub</a>, and <a href="https://mdn.github.io/sw-test/">view the example live</a>. The one bit we’ll call out here is the promise (see <a href="https://github.com/mdn/sw-test/blob/gh-pages/app.js#L22-L47">app.js lines 22-47</a>), which is a modified version of what you read about above, in the <a href="https://github.com/mdn/promises-test">Promises test demo</a>. It is different in the following ways:</p>
+
+<ol>
+ <li>In the original, we only passed in a URL to an image we wanted to load. In this version, we pass in a JSON fragment containing all the data for a single image (see what they look like in <a href="https://github.com/mdn/sw-test/blob/gh-pages/image-list.js">image-list.js</a>). This is because all the data for each promise resolve has to be passed in with the promise, as it is asynchronous. If you just passed in the url, and then tried to access the other items in the JSON separately when the <code>for()</code> loop is being iterated through later on, it wouldn’t work, as the promise wouldn’t resolve at the same time as the iterations are being done (that is a synchronous process.)</li>
+ <li>We actually resolve the promise with an array, as we want to make the loaded image blob available to the resolving function later on in the code, but also the image name, credits and alt text (see <a href="https://github.com/mdn/sw-test/blob/gh-pages/app.js#L31-L34">app.js lines 31-34</a>). Promises will only resolve with a single argument, so if you want to resolve with multiple values, you need to use an array/object.</li>
+ <li>To access the resolved promise values, we then access this function as you’d then expect (see <a href="https://github.com/mdn/sw-test/blob/gh-pages/app.js#L60-L64">app.js lines 60-64</a>). This may seem a bit odd at first, but this is the way promises work.</li>
+</ol>
+
+<h2 id="Enter_service_workers">Enter service workers</h2>
+
+<p>Now let’s get on to service workers!</p>
+
+<h3 id="Registering_your_worker">Registering your worker</h3>
+
+<p>The first block of code in our app’s JavaScript file — <code>app.js</code> — is as follows. This is our entry point into using service workers.</p>
+
+<pre class="brush: js">if ('serviceWorker' in navigator) {
+  navigator.serviceWorker.register('/sw-test/sw.js', {scope: '/sw-test/'})
+  .then(function(reg) {
+    // registration worked
+    console.log('Registration succeeded. Scope is ' + reg.scope);
+  }).catch(function(error) {
+    // registration failed
+    console.log('Registration failed with ' + error);
+  });
+}</pre>
+
+<ol>
+ <li>The outer block performs a feature detection test to make sure service workers are supported before trying to register one.</li>
+ <li>Next, we use the {{domxref("ServiceWorkerContainer.register()") }} function to register the service worker for this site, which is just a JavaScript file residing inside our app (note this is the file's URL relative to the origin, not the JS file that references it.)</li>
+ <li>The <code>scope</code> parameter is optional, and can be used to specify the subset of your content that you want the service worker to control. In this case, we have specified '<code>/sw-test/'</code>, which means all content under the app's origin. If you leave it out, it will default to this value anyway, but we specified it here for illustration purposes.</li>
+ <li>The <code>.then()</code> promise function is used to chain a success case onto our promise structure.  When the promise resolves successfully, the code inside it executes.</li>
+ <li>Finally, we chain a <code>.catch()</code> function onto the end that will run if the promise is rejected.</li>
+</ol>
+
+<p>This registers a service worker, which runs in a worker context, and therefore has no DOM access. You then run code in the service worker outside of your normal pages to control their loading.<br>
+ <br>
+ A single service worker can control many pages. Each time a page within your scope is loaded, the service worker is installed against that page and operates on it. Bear in mind therefore that you need to be careful with global variables in the service worker script: each page doesn’t get its own unique worker.</p>
+
+<div class="note">
+<p><strong>Note</strong>: Your service worker functions like a proxy server, allowing you to modify requests and responses, replace them with items from its own cache, and more.</p>
+</div>
+
+<div class="note">
+<p><strong>Note</strong>: One great thing about service workers is that if you use feature detection like we’ve shown above, browsers that don’t support service workers can just use your app online in the normal expected fashion. Furthermore, if you use AppCache and SW on a page, browsers that don’t support SW but do support AppCache will use that, and browsers that support both will ignore the AppCache and let SW take over.</p>
+</div>
+
+<h4 id="Why_is_my_service_worker_failing_to_register">Why is my service worker failing to register?</h4>
+
+<p>This could be for the following reasons:</p>
+
+<ol>
+ <li>You are not running your application through HTTPS.</li>
+ <li>The path to your service worker file is not written correctly — it needs to be written relative to the origin, not your app’s root directory. In our example, the worker is at <code>https://mdn.github.io/sw-test/sw.js</code>, and the app’s root is <code>https://mdn.github.io/sw-test/</code>. But the path needs to be written as <code>/sw-test/sw.js</code>, not <code>/sw.js</code>.</li>
+ <li>The service worker being pointed to is on a different origin to that of your app. This is also not allowed.</li>
+</ol>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/12630/important-notes.png" style="display: block; height: 277px; margin: 0px auto; width: 574px;"></p>
+
+<p>Also note:</p>
+
+<ul>
+ <li>The service worker will only catch requests from clients under the service worker's scope.</li>
+ <li>The max scope for a service worker is the location of the worker.</li>
+ <li>If your server worker is active on a client being served with the <code>Service-Worker-Allowed</code> header, you can specify a list of max scopes for that worker.</li>
+ <li>In Firefox, Service Worker APIs are hidden and cannot be used when the user is in <a href="https://support.mozilla.org/en-US/kb/private-browsing-use-firefox-without-history">private browsing mode</a>.</li>
+</ul>
+
+<h3 id="Install_and_activate_populating_your_cache">Install and activate: populating your cache</h3>
+
+<p>After your service worker is registered, the browser will attempt to install then activate the service worker for your page/site.<br>
+ <br>
+ The install event is fired when an install is successfully completed. The install event is generally used to populate your browser’s offline caching capabilities with the assets you need to run your app offline. To do this, we use Service Worker’s brand new storage API — {{domxref("cache")}} — a global on the service worker that allows us to store assets delivered by responses, and keyed by their requests. This API works in a similar way to the browser’s standard cache, but it is specific to your domain. It persists until you tell it not to — again, you have full control.</p>
+
+<div class="note">
+<p><strong>Note</strong>: The Cache API is not supported in every browser. (See the {{anch("Browser support")}} section for more information.) If you want to use this now, you could consider using a polyfill like the one available in <a href="https://github.com/Polymer/topeka/blob/master/sw.js">Google's Topeka demo</a>, or perhaps store your assets in <a href="/en-US/docs/Web/API/IndexedDB_API">IndexedDB</a>.</p>
+</div>
+
+<p>Let’s start this section by looking at a code sample — this is the <a href="https://github.com/mdn/sw-test/blob/gh-pages/sw.js#L1-L18">first block you’ll find in our service worker</a>:</p>
+
+<pre class="brush: js">this.addEventListener('install', function(event) {
+  event.waitUntil(
+    caches.open('v1').then(function(cache) {
+      return cache.addAll([
+        '/sw-test/',
+        '/sw-test/index.html',
+        '/sw-test/style.css',
+        '/sw-test/app.js',
+        '/sw-test/image-list.js',
+        '/sw-test/star-wars-logo.jpg',
+        '/sw-test/gallery/',
+        '/sw-test/gallery/bountyHunters.jpg',
+        '/sw-test/gallery/myLittleVader.jpg',
+        '/sw-test/gallery/snowTroopers.jpg'
+      ]);
+    })
+  );
+});</pre>
+
+<ol>
+ <li>Here we add an <code>install</code> event listener to the service worker (hence <code>this</code>), and then chain a {{domxref("ExtendableEvent.waitUntil()") }} method onto the event — this ensures that the service worker will not install until the code inside <code>waitUntil()</code> has successfully occurred.</li>
+ <li>Inside <code>waitUntil()</code> we use the <a href="/en-US/docs/Web/API/CacheStorage/open"><code>caches.open()</code></a> method to create a new cache called <code>v1</code>, which will be version 1 of our site resources cache. This returns a promise for a created cache; once resolved, we then call a function that calls <code>addAll()</code> on the created cache, which for its parameter takes an array of origin-relative URLs to all the resources you want to cache.</li>
+ <li>If the promise is rejected, the install fails, and the worker won’t do anything. This is ok, as you can fix your code and then try again the next time registration occurs.</li>
+ <li>After a successful installation, the service worker activates. This doesn’t have much of a distinct use the first time your service worker is installed/activated, but it means more when the service worker is updated (see the {{anch("Updating your service worker") }} section later on.)</li>
+</ol>
+
+<div class="note">
+<p><strong>Note</strong>: <a href="/en-US/docs/Web/Guide/API/DOM/Storage">localStorage</a> works in a similar way to service worker cache, but it is synchronous, so not allowed in service workers.</p>
+</div>
+
+<div class="note">
+<p><strong>Note</strong>: <a href="/en-US/docs/Web/API/IndexedDB_API">IndexedDB</a> can be used inside a service worker for data storage if you require it.</p>
+</div>
+
+<h3 id="Custom_responses_to_requests">Custom responses to requests</h3>
+
+<p>Now you’ve got your site assets cached, you need to tell service workers to do something with the cached content. This is easily done with the <code>fetch</code> event.</p>
+
+<p><img alt="" src="https://mdn.mozillademos.org/files/12634/sw-fetch.png" style="display: block; margin: 0 auto;"></p>
+
+<p>A <code>fetch</code> event fires every time any resource controlled by a service worker is fetched, which includes the documents inside the specified scope, and any resources referenced in those documents (for example if <code>index.html</code> makes a cross origin request to embed an image, that still goes through its service worker.)</p>
+
+<p>You can attach a <code>fetch</code> event listener to the service worker, then call the <code>respondWith()</code> method on the event to hijack our HTTP responses and update them with your own magic.</p>
+
+<pre class="brush: js">this.addEventListener('fetch', function(event) {
+  event.respondWith(
+    // magic goes here
+  );
+});</pre>
+
+<p>We could start by simply responding with the resource whose url matches that of the network request, in each case:</p>
+
+<pre class="brush: js">this.addEventListener('fetch', function(event) {
+  event.respondWith(
+    caches.match(event.request)
+  );
+});</pre>
+
+<p><code>caches.match(event.request)</code> allows us to match each resource requested from the network with the equivalent resource available in the cache, if there is a matching one available. The matching is done via url and vary headers, just like with normal HTTP requests.</p>
+
+<p>Let’s look at a few other options we have when defining our magic (see our <a href="/en-US/docs/Web/API/Fetch_API">Fetch API documentation</a> for more information about {{domxref("Request")}} and {{domxref("Response")}} objects.)</p>
+
+<ol>
+ <li>
+  <p>The <code>{{domxref("Response.Response","Response()")}}</code> constructor allows you to create a custom response. In this case, we are just returning a simple text string:</p>
+
+  <pre class="brush: js">new Response('Hello from your friendly neighbourhood service worker!');</pre>
+ </li>
+ <li>
+  <p>This more complex <code>Response</code> below shows that you can optionally pass a set of headers in with your response, emulating standard HTTP response headers. Here we are just telling the browser what the content type of our synthetic response is:</p>
+
+  <pre class="brush: js">new Response('&lt;p&gt;Hello from your friendly neighbourhood service worker!&lt;/p&gt;', {
+  headers: { 'Content-Type': 'text/html' }
+});</pre>
+ </li>
+ <li>
+  <p>If a match wasn’t found in the cache, you could tell the browser to simply {{domxref("GlobalFetch.fetch","fetch")}} the default network request for that resource, to get the new resource from the network if it is available:</p>
+
+  <pre class="brush: js">fetch(event.request);</pre>
+ </li>
+ <li>
+  <p>If a match wasn’t found in the cache, and the network isn’t available, you could just match the request with some kind of default fallback page as a response using {{domxref("CacheStorage.match","match()")}}, like this:</p>
+
+  <pre class="brush: js">caches.match('/fallback.html');</pre>
+ </li>
+ <li>
+  <p>You can retrieve a lot of information about each request by calling parameters of the {{domxref("Request")}} object returned by the {{domxref("FetchEvent")}}:</p>
+
+  <pre class="brush: js">event.request.url
+event.request.method
+event.request.headers
+event.request.body</pre>
+ </li>
+</ol>
+
+<h2 id="Recovering_failed_requests">Recovering failed requests</h2>
+
+<p>So <code>caches.match(event.request)</code> is great when there is a match in the service worker cache, but what about cases when there isn’t a match? If we didn’t provide any kind of failure handling, our promise would resolve with <code>undefined</code> and we wouldn't get anything returned.</p>
+
+<p>Fortunately service workers’ promise-based structure makes it trivial to provide further options towards success. We could do this:</p>
+
+<pre class="brush: js">this.addEventListener('fetch', function(event) {
+  event.respondWith(
+    caches.match(event.request).then(function(response) {
+      return response || fetch(event.request);
+    })
+  );
+});</pre>
+
+<p>If the resources isn't in the cache, it is requested from the network.</p>
+
+<p>If we were being really clever, we would not only request the resource from the network; we would also save it into the cache so that later requests for that resource could be retrieved offline too! This would mean that if extra images were added to the Star Wars gallery, our app could automatically grab them and cache them. The following would do the trick:</p>
+
+<pre class="brush: js">this.addEventListener('fetch', function(event) {
+  event.respondWith(
+    caches.match(event.request).then(function(resp) {
+      return resp || fetch(event.request).then(function(response) {
+        return caches.open('v1').then(function(cache) {
+          cache.put(event.request, response.clone());
+          return response;
+        });
+      });
+    })
+  );
+});</pre>
+
+<p>Here we return the default network request with <code>return fetch(event.request)</code>, which returns a promise. When this promise is resolved, we respond by running a function that grabs our cache using <code>caches.open('v1')</code>; this also returns a promise. When that promise resolves, <code>cache.put()</code> is used to add the resource to the cache. The resource is grabbed from <code>event.request</code>, and the response is then cloned with <code>response.clone()</code> and added to the cache. The clone is put in the cache, and the original response is returned to the browser to be given to the page that called it.</p>
+
+<p>Cloning the response is necessary because request and response streams can only be read once.  In order to return the response to the browser and put it in the cache we have to clone it. So the original gets returned to the browser and the clone gets sent to the cache.  They are each read once.</p>
+
+<p>The only trouble we have now is that if the request doesn’t match anything in the cache, and the network is not available, our request will still fail. Let’s provide a default fallback so that whatever happens, the user will at least get something:</p>
+
+<pre class="brush: js">this.addEventListener('fetch', function(event) {
+  event.respondWith(
+    caches.match(event.request).then(function(resp) {
+      return resp || fetch(event.request).then(function(response) {
+        caches.open('v1').then(function(cache) {
+          cache.put(event.request, response.clone());
+        });
+        return response;
+      });
+    }).catch(function() {
+      return caches.match('/sw-test/gallery/myLittleVader.jpg');
+    })
+  );
+});</pre>
+
+<p>We have opted for this fallback image because the only updates that are likely to fail are new images, as everything else is depended on for installation in the <code>install</code> event listener we saw earlier.</p>
+
+<h2 id="Updating_your_service_worker"><a id="Updating your service worker" name="Updating your service worker">Updating your service worker</a></h2>
+
+<p>If your service worker has previously been installed, but then a new version of the worker is available on refresh or page load, the new version is installed in the background, but not yet activated. It is only activated when there are no longer any pages loaded that are still using the old service worker. As soon as there are no more such pages still loaded, the new service worker activates.</p>
+
+<p>You’ll want to update your <code>install</code> event listener in the new service worker to something like this (notice the new version number):</p>
+
+<pre class="brush: js">this.addEventListener('install', function(event) {
+  event.waitUntil(
+    caches.open('v2').then(function(cache) {
+      return cache.addAll([
+        '/sw-test/',
+        '/sw-test/index.html',
+        '/sw-test/style.css',
+        '/sw-test/app.js',
+        '/sw-test/image-list.js',
+
+        …
+
+        // include other new resources for the new version...
+      ]);
+    })
+  );
+});</pre>
+
+<p>While this happens, the previous version is still responsible for fetches. The new version is installing in the background. We are calling the new cache <code>v2</code>, so the previous <code>v1</code> cache isn't disturbed.</p>
+
+<p>When no pages are using the current version, the new worker activates and becomes responsible for fetches.</p>
+
+<h3 id="Deleting_old_caches">Deleting old caches</h3>
+
+<p>You also get an <code>activate</code> event. This is a generally used to do stuff that would have broken the previous version while it was still running, for example getting rid of old caches. This is also useful for removing data that is no longer needed to avoid filling up too much disk space — each browser has a hard limit on the amount of cache storage that a given service worker can use. The browser does its best to manage disk space, but it may delete the Cache storage for an origin.  The browser will generally delete all of the data for an origin or none of the data for an origin.</p>
+
+<p>Promises passed into <code>waitUntil()</code> will block other events until completion, so you can rest assured that your clean-up operation will have completed by the time you get your first <code>fetch</code> event on the new cache.</p>
+
+<pre class="brush: js">this.addEventListener('activate', function(event) {
+  var cacheWhitelist = ['v2'];
+
+  event.waitUntil(
+    caches.keys().then(function(keyList) {
+      return Promise.all(keyList.map(function(key) {
+        if (cacheWhitelist.indexOf(key) === -1) {
+          return caches.delete(key);
+        }
+      }));
+    })
+  );
+});</pre>
+
+<h2 id="Developer_tools">Developer tools</h2>
+
+<p>Chrome has <code>chrome://inspect/#service-workers</code>, which shows current service worker activity and storage on a device, and <code>chrome://serviceworker-internals</code>, which shows more detail and allows you to start/stop/debug the worker process. In the future they will have throttling/offline modes to simulate bad or non-existent connections, which will be a really good thing.</p>
+
+<p>Firefox has also started to implement some useful tools related to service workers:</p>
+
+<ul>
+ <li>You can navigate to <code><a href="/en-US/docs/Tools/about:debugging">about:debugging</a></code> to see what SWs are registered and update/remove them.</li>
+ <li>When testing you can get around the HTTPS restriction by checking the "Enable Service Workers over HTTP (when toolbox is open)" option in the <a href="/en-US/docs/Tools/Settings">Firefox Developer Tools settings</a>.</li>
+</ul>
+
+<div class="note">
+<p><strong>Note</strong>: You may serve your app from <code>http://localhost</code> (e.g. using <code>me@localhost:/my/app$ <strong>python -m SimpleHTTPServer</strong></code>) for local development. See <a href="https://www.w3.org/TR/service-workers/#security-considerations">Security considerations</a></p>
+</div>
+
+<h2 id="Specifications">Specifications</h2>
+
+<table class="standard-table">
+ <tbody>
+  <tr>
+   <th scope="col">Specification</th>
+   <th scope="col">Status</th>
+   <th scope="col">Comment</th>
+  </tr>
+  <tr>
+   <td>{{SpecName('Service Workers', '')}}</td>
+   <td>{{Spec2('Service Workers')}}</td>
+   <td>Initial definition.</td>
+  </tr>
+ </tbody>
+</table>
+
+<h2 id="Browser_compatibility">Browser compatibility</h2>
+
+<div>{{CompatibilityTable}}</div>
+
+<div id="compat-desktop">
+<table class="compat-table">
+ <tbody>
+  <tr>
+   <th>Feature</th>
+   <th>Chrome</th>
+   <th>Firefox (Gecko)</th>
+   <th>Internet Explorer</th>
+   <th>Opera</th>
+   <th>Safari (WebKit)</th>
+  </tr>
+  <tr>
+   <td>Basic support</td>
+   <td>{{CompatChrome(40.0)}}</td>
+   <td>{{ CompatGeckoDesktop("33.0") }}<sup>[1]</sup></td>
+   <td>{{CompatNo}}</td>
+   <td>24</td>
+   <td>{{CompatNo}}</td>
+  </tr>
+ </tbody>
+</table>
+</div>
+
+<div id="compat-mobile">
+<table class="compat-table">
+ <tbody>
+  <tr>
+   <th>Feature</th>
+   <th>Android Webview</th>
+   <th>Chrome for Android</th>
+   <th>Firefox Mobile (Gecko)</th>
+   <th>Firefox OS</th>
+   <th>IE Phone</th>
+   <th>Opera Mobile</th>
+   <th>Safari Mobile</th>
+  </tr>
+  <tr>
+   <td>Basic support</td>
+   <td>{{CompatNo}}</td>
+   <td>{{CompatChrome(40.0)}}</td>
+   <td>{{ CompatVersionUnknown }}</td>
+   <td>{{ CompatVersionUnknown }}</td>
+   <td>{{CompatNo}}</td>
+   <td>{{ CompatVersionUnknown() }}</td>
+   <td>{{CompatNo}}</td>
+  </tr>
+ </tbody>
+</table>
+</div>
+
+<p>[1] Service workers (and <a href="/en-US/docs/Web/API/Push_API">Push</a>) have been disabled in the <a href="https://www.mozilla.org/en-US/firefox/organizations/">Firefox 45 Extended Support Release</a> (ESR.)</p>
+
+<h2 id="See_also">See also</h2>
+
+<ul>
+ <li><a href="https://serviceworke.rs/">The Service Worker Cookbook</a></li>
+ <li><a href="https://jakearchibald.github.io/isserviceworkerready/">Is ServiceWorker ready?</a></li>
+ <li>Download the <a href="https://mdn.mozillademos.org/files/12638/sw101.png">Service Workers 101 cheatsheet</a>.</li>
+ <li><a href="/en-US/docs/Web/JavaScript/Reference/Global_Objects/Promise">Promises</a></li>
+ <li><a href="/en-US/docs/Web/Guide/Performance/Using_web_workers">Using web workers</a></li>
+</ul>