Es posible que no necesites un service worker

El service worker fue presentado como una pieza clave de las aplicaciones web progresivas, pero su uso ha caído en picado por la complejidad operativa que introduce y los problemas de caché obsoleta que genera. Este artículo analiza varios casos de uso reales —el arranque instantáneo de Slack, la conservación de fragmentos de código entre despliegues, la reescritura de manifiestos de vídeo en Mux, Partytown y Mock Service Worker— y argumenta que, en la mayoría de los casos, existen alternativas más simples: caché HTTP nativo con hashes de contenido, retención de activos antiguos en el servidor, lógica server-side o mocking en Node. El autor reconoce tres capacidades que sí requieren un service worker: soporte offline, notificaciones push y sincronización en segundo plano. Fuera de esos escenarios, mantener un service worker añade una superficie de fallo difícil de revertir —como demuestra la necesidad de desplegar workers 'killswitch' y esperar días a que los clientes actualicen— sin aportar beneficios que justifiquen su complejidad.