Estrategias Avanzadas de Service Workers: Caché y Sincronización en Segundo Plano

Los Service Workers son una tecnología potente que permite a los desarrolladores crear Aplicaciones Web Progresivas (PWA) con un rendimiento mejorado, capacidades sin conexión y una mejor experiencia de usuario. Actúan como un proxy entre la aplicación web y la red, permitiendo a los desarrolladores interceptar solicitudes de red y responder con activos en caché o iniciar tareas en segundo plano. Este artículo profundiza en estrategias avanzadas de caché de Service Workers y técnicas de sincronización en segundo plano, proporcionando ejemplos prácticos y mejores prácticas para construir aplicaciones web robustas y resilientes para una audiencia global.

Entendiendo los Service Workers

Un Service Worker es un archivo JavaScript que se ejecuta en segundo plano, separado del hilo principal del navegador. Puede interceptar solicitudes de red, almacenar recursos en caché y enviar notificaciones push, incluso cuando el usuario no está utilizando activamente la aplicación web. Esto permite tiempos de carga más rápidos, acceso sin conexión al contenido y una experiencia de usuario más atractiva.

Las características clave de los Service Workers incluyen:

• Almacenamiento en caché: Guardar activos localmente para mejorar el rendimiento y permitir el acceso sin conexión.
• Sincronización en segundo plano: Diferir tareas para que se ejecuten cuando el dispositivo tenga conectividad de red.
• Notificaciones push: Involucrar a los usuarios con actualizaciones y notificaciones oportunas.
• Intercepción de solicitudes de red: Controlar cómo se manejan las solicitudes de red.

Estrategias Avanzadas de Caché

Elegir la estrategia de caché correcta es crucial para optimizar el rendimiento de la aplicación web y garantizar una experiencia de usuario fluida. Aquí hay algunas estrategias avanzadas de caché a considerar:

1. Primero la Caché (Cache-First)

La estrategia Cache-First prioriza servir contenido desde la caché siempre que sea posible. Este enfoque es ideal para activos estáticos como imágenes, archivos CSS y archivos JavaScript que rara vez cambian.

Cómo funciona:

1. El Service Worker intercepta la solicitud de red.
2. Comprueba si el activo solicitado está disponible en la caché.
3. Si se encuentra, el activo se sirve directamente desde la caché.
4. Si no se encuentra, la solicitud se realiza a la red y la respuesta se almacena en caché para uso futuro.

Ejemplo:

            self.addEventListener('fetch', event => {
  event.respondWith(
    caches.match(event.request)
      .then(response => {
        // Acierto de caché - devolver respuesta
        if (response) {
          return response;
        }

        // No está en caché - devolver fetch
        return fetch(event.request).then(
          function(response) {
            // Comprobar si recibimos una respuesta válida
            if(!response || response.status !== 200 || response.type !== 'basic') {
              return response;
            }

            // IMPORTANTE: Clonar la respuesta. Una respuesta es un stream
            // y como queremos que tanto el navegador como la caché consuman la respuesta,
            // necesitamos clonarla para tener dos streams.
            var responseToCache = response.clone();

            caches.open(CACHE_NAME)
              .then(function(cache) {
                cache.put(event.request, responseToCache);
              });

            return response;
          }
        );
      })
    );
});

            

              
                Copy
              
            
          

2. Primero la Red (Network-First)

La estrategia Network-First prioriza la obtención de contenido de la red siempre que sea posible. Si la solicitud de red falla, el Service Worker recurre a la caché. Esta estrategia es adecuada para contenido que se actualiza con frecuencia, donde la frescura es crucial.

Cómo funciona:

1. El Service Worker intercepta la solicitud de red.
2. Intenta obtener el activo de la red.
3. Si la solicitud de red es exitosa, el activo se sirve y se almacena en caché.
4. Si la solicitud de red falla (p. ej., debido a un error de red), el Service Worker comprueba la caché.
5. Si el activo se encuentra en la caché, se sirve.
6. Si el activo no se encuentra en la caché, se muestra un mensaje de error (o se proporciona una respuesta de respaldo).

Ejemplo:

            self.addEventListener('fetch', event => {
  event.respondWith(
    fetch(event.request)
      .then(response => {
        // Comprobar si recibimos una respuesta válida
        if(!response || response.status !== 200 || response.type !== 'basic') {
          return response;
        }

        // IMPORTANTE: Clonar la respuesta. Una respuesta es un stream
        // y como queremos que tanto el navegador como la caché consuman la respuesta,
        // necesitamos clonarla para tener dos streams.
        var responseToCache = response.clone();

        caches.open(CACHE_NAME)
          .then(function(cache) {
            cache.put(event.request, responseToCache);
          });

        return response;
      })
      .catch(err => {
        // La solicitud de red falló, intentar obtenerla de la caché.
        return caches.match(event.request);
      })
  );
});

            

              
                Copy
              
            
          

3. Obsoleto Mientras se Revalida (Stale-While-Revalidate)

La estrategia Stale-While-Revalidate devuelve el contenido en caché inmediatamente mientras obtiene simultáneamente la última versión de la red. Esto proporciona una carga inicial rápida con el beneficio de actualizar la caché en segundo plano.

Cómo funciona:

1. El Service Worker intercepta la solicitud de red.
2. Devuelve inmediatamente la versión en caché del activo (si está disponible).
3. En segundo plano, obtiene la última versión del activo de la red.
4. Una vez que la solicitud de red es exitosa, la caché se actualiza con la nueva versión.

Ejemplo:

            self.addEventListener('fetch', event => {
  event.respondWith(
    caches.match(event.request)
      .then(cachedResponse => {
        // Incluso si la respuesta está en la caché, la solicitamos a la red
        // y actualizamos la caché en segundo plano.
        var fetchPromise = fetch(event.request).then(
          networkResponse => {
            caches.open(CACHE_NAME).then(cache => {
              cache.put(event.request, networkResponse.clone());
              return networkResponse;
            });
          })
        // Devolver la respuesta en caché si la tenemos, de lo contrario, devolver la respuesta de la red
        return cachedResponse || fetchPromise;
      })
  );
});

            

              
                Copy
              
            
          

4. Caché y Luego Red (Cache, then Network)

La estrategia Caché y Luego Red primero intenta servir contenido desde la caché. Simultáneamente, obtiene la última versión de la red y actualiza la caché. Esta estrategia es útil para mostrar contenido rápidamente mientras se asegura de que el usuario eventualmente reciba la información más actualizada. Es similar a Stale-While-Revalidate, pero asegura que la solicitud de red *siempre* se realice y la caché se actualice, en lugar de solo en caso de un fallo de caché.

Cómo funciona:

1. El Service Worker intercepta la solicitud de red.
2. Devuelve inmediatamente la versión en caché del activo (si está disponible).
3. Siempre obtiene la última versión del activo de la red.
4. Una vez que la solicitud de red es exitosa, la caché se actualiza con la nueva versión.

Ejemplo:

            self.addEventListener('fetch', event => {
  // Primero responder con lo que ya está en la caché
  event.respondWith(caches.match(event.request));

  // Luego actualizar la caché con la respuesta de la red. Esto activará un
  // nuevo evento 'fetch', que volverá a responder con el valor en caché
  // (inmediatamente) mientras la caché se actualiza en segundo plano.
  event.waitUntil(
    fetch(event.request).then(response =>
      caches.open(CACHE_NAME).then(cache => cache.put(event.request, response))
    )
  );
});

            

              
                Copy
              
            
          

5. Solo Red (Network Only)

Esta estrategia obliga al Service Worker a obtener siempre el recurso de la red. Si la red no está disponible, la solicitud fallará. Esto es útil para recursos que son muy dinámicos y deben estar siempre actualizados, como los feeds de datos en tiempo real.

Cómo funciona:

1. El Service Worker intercepta la solicitud de red.
2. Intenta obtener el activo de la red.
3. Si tiene éxito, se sirve el activo.
4. Si la solicitud de red falla, se lanza un error.

Ejemplo:

            self.addEventListener('fetch', event => {
  event.respondWith(fetch(event.request));
});

            

              
                Copy
              
            
          

6. Solo Caché (Cache Only)

Esta estrategia obliga al Service Worker a recuperar siempre el recurso de la caché. Si el recurso no está disponible en la caché, la solicitud fallará. Esto es adecuado para activos que se almacenan explícitamente en caché y nunca deben obtenerse de la red, como las páginas de respaldo sin conexión.

Cómo funciona:

1. El Service Worker intercepta la solicitud de red.
2. Comprueba si el activo está disponible en la caché.
3. Si se encuentra, el activo se sirve directamente desde la caché.
4. Si no se encuentra, se lanza un error.

Ejemplo:

            self.addEventListener('fetch', event => {
  event.respondWith(caches.match(event.request));
});

            

              
                Copy
              
            
          

7. Caché Dinámico

El caché dinámico implica almacenar en caché recursos que no se conocen en el momento de la instalación del Service Worker. Esto es particularmente útil para almacenar en caché respuestas de API y otro contenido dinámico. Puede usar el evento fetch para interceptar solicitudes de red y almacenar en caché las respuestas a medida que se reciben.

Ejemplo:

            self.addEventListener('fetch', event => {
  if (event.request.url.startsWith('https://api.example.com/')) {
    event.respondWith(
      caches.open('dynamic-cache').then(cache => {
        return fetch(event.request).then(response => {
          cache.put(event.request, response.clone());
          return response;
        });
      })
    );
  }
});

            

              
                Copy
              
            
          

Sincronización en Segundo Plano

La Sincronización en Segundo Plano le permite diferir tareas que requieren conectividad de red hasta que el dispositivo tenga una conexión estable. Esto es particularmente útil para escenarios donde los usuarios pueden estar sin conexión o tener conectividad intermitente, como enviar formularios, enviar mensajes o actualizar datos. Esto mejora drásticamente la experiencia del usuario en áreas con redes poco fiables (p. ej., zonas rurales en países en desarrollo).

Registrarse para la Sincronización en Segundo Plano

Para usar la Sincronización en Segundo Plano, necesita registrar su Service Worker para el evento `sync`. Esto se puede hacer en el código de su aplicación web:

            navigator.serviceWorker.ready.then(function(swRegistration) {
  return swRegistration.sync.register('my-background-sync');
});

            

              
                Copy
              
            
          

Aquí, `'my-background-sync'` es una etiqueta que identifica el evento de sincronización específico. Puede usar diferentes etiquetas para diferentes tipos de tareas en segundo plano.

Manejar el Evento de Sincronización

En su Service Worker, necesita escuchar el evento `sync` y manejar la tarea en segundo plano. Por ejemplo:

            self.addEventListener('sync', event => {
  if (event.tag === 'my-background-sync') {
    event.waitUntil(
      doSomeBackgroundTask()
    );
  }
});

            

              
                Copy
              
            
          

El método `event.waitUntil()` le dice al navegador que mantenga vivo el Service Worker hasta que la promesa se resuelva. Esto asegura que la tarea en segundo plano se complete incluso si el usuario cierra la aplicación web.

Ejemplo: Enviar un Formulario en Segundo Plano

Consideremos un ejemplo en el que un usuario envía un formulario mientras está sin conexión. Los datos del formulario se pueden almacenar localmente y el envío se puede diferir hasta que el dispositivo tenga conectividad de red.

1. Almacenar los Datos del Formulario:

Cuando el usuario envía el formulario, almacene los datos en IndexedDB:

            function submitForm(formData) {
  // Almacenar los datos del formulario en IndexedDB
  openDatabase().then(db => {
    const tx = db.transaction('submissions', 'readwrite');
    const store = tx.objectStore('submissions');
    store.add(formData);
    return tx.done;
  }).then(() => {
    // Registrarse para la sincronización en segundo plano
    return navigator.serviceWorker.ready;
  }).then(swRegistration => {
    return swRegistration.sync.register('form-submission');
  });
}

            

              
                Copy
              
            
          

2. Manejar el Evento de Sincronización:

En el Service Worker, escuche el evento `sync` y envíe los datos del formulario al servidor:

            self.addEventListener('sync', event => {
  if (event.tag === 'form-submission') {
    event.waitUntil(
      openDatabase().then(db => {
        const tx = db.transaction('submissions', 'readwrite');
        const store = tx.objectStore('submissions');
        return store.getAll();
      }).then(submissions => {
        // Enviar cada dato de formulario al servidor
        return Promise.all(submissions.map(formData => {
          return fetch('/submit-form', {
            method: 'POST',
            body: JSON.stringify(formData),
            headers: {
              'Content-Type': 'application/json'
            }
          }).then(response => {
            if (response.ok) {
              // Eliminar los datos del formulario de IndexedDB
              return openDatabase().then(db => {
                const tx = db.transaction('submissions', 'readwrite');
                const store = tx.objectStore('submissions');
                store.delete(formData.id);
                return tx.done;
              });
            }
            throw new Error('Failed to submit form');
          });
        }));
      }).catch(error => {
        console.error('Failed to submit forms:', error);
      })
    );
  }
});

            

              
                Copy
              
            
          

Mejores Prácticas para la Implementación de Service Workers

Para asegurar una implementación exitosa de Service Worker, considere las siguientes mejores prácticas:

• Mantenga el Script del Service Worker Simple: Evite la lógica compleja en el script del Service Worker para minimizar errores y asegurar un rendimiento óptimo.
• Pruebe Exhaustivamente: Pruebe su implementación de Service Worker en varios navegadores y condiciones de red para identificar y resolver posibles problemas. Use las herramientas de desarrollador del navegador (p. ej., Chrome DevTools) para inspeccionar el comportamiento del Service Worker.
• Maneje los Errores con Gracia: Implemente el manejo de errores para gestionar elegantemente los errores de red, los fallos de caché y otras situaciones inesperadas. Proporcione mensajes de error informativos al usuario.
• Use Versionado: Implemente el versionado para su Service Worker para asegurar que las actualizaciones se apliquen correctamente. Incremente el nombre de la caché o el nombre del archivo del Service Worker al hacer cambios.
• Monitoree el Rendimiento: Monitoree el rendimiento de su implementación de Service Worker para identificar áreas de mejora. Use herramientas como Lighthouse para medir métricas de rendimiento.
• Considere la Seguridad: Los Service Workers se ejecutan en un contexto seguro (HTTPS). Siempre despliegue su aplicación web sobre HTTPS para proteger los datos del usuario y prevenir ataques de intermediario (man-in-the-middle).
• Proporcione Contenido de Respaldo: Implemente contenido de respaldo para escenarios sin conexión para proporcionar una experiencia de usuario básica incluso cuando el dispositivo no está conectado a la red.

Ejemplos de Aplicaciones Globales que Usan Service Workers

• Google Maps Go: Esta versión ligera de Google Maps utiliza Service Workers para proporcionar acceso sin conexión a mapas y navegación, lo cual es particularmente beneficioso en áreas con conectividad limitada.
• PWA de Starbucks: La Aplicación Web Progresiva de Starbucks permite a los usuarios navegar por el menú, hacer pedidos y gestionar sus cuentas incluso sin conexión. Esto mejora la experiencia del usuario en áreas con un servicio celular o Wi-Fi deficiente.
• Twitter Lite: Twitter Lite utiliza Service Workers para almacenar en caché tuits e imágenes, reduciendo el uso de datos y mejorando el rendimiento en redes lentas. Esto es especialmente valioso para usuarios en países en desarrollo con planes de datos caros.
• PWA de AliExpress: La PWA de AliExpress aprovecha los Service Workers para tiempos de carga más rápidos y navegación sin conexión de catálogos de productos, mejorando la experiencia de compra para usuarios de todo el mundo.

Conclusión

Los Service Workers son una herramienta poderosa para construir aplicaciones web modernas con un rendimiento mejorado, capacidades sin conexión y una mejor experiencia de usuario. Al comprender e implementar estrategias avanzadas de caché y técnicas de sincronización en segundo plano, los desarrolladores pueden crear aplicaciones robustas y resilientes que funcionan sin problemas en diversas condiciones de red y dispositivos, creando una mejor experiencia para todos los usuarios, independientemente de su ubicación o calidad de red. A medida que las tecnologías web continúan evolucionando, los Service Workers jugarán un papel cada vez más importante en la configuración del futuro de la web.