Test d'origine des workers partagés à durée de vie prolongée

Barry Pollard

Domenic Denicola

Publié le : 31 juillet 2025

À partir de Chrome 139, participez à un nouvel essai d'origine pour les workers partagés à durée de vie étendue. L'essai ajoute une nouvelle option extendedLifetime: true pour permettre aux workers partagés de rester actifs au-delà du dernier déchargement de document.

Cas d'utilisation de la fonctionnalité de durée de vie étendue

De nombreux sites souhaitent effectuer certaines tâches lorsque l'utilisateur quitte la page. Par exemple, écrire dans le stockage ou renvoyer des données aux serveurs pour enregistrer l'état ou enregistrer des données analytiques.

La plate-forme Web fournit quelques API pour gérer certains des cas d'utilisation les plus simples, mais chacune présente des limites :

• Les API JavaScript synchrones, telles que les écritures localStorage, sont exécutées jusqu'à la fin avant le déchargement de la page actuelle.
• fetch API propose plusieurs options, comme keepalive et, plus récemment, fetchLater, qui permettent aux requêtes d'être envoyées pendant une courte période après le déchargement du document.

Toutefois, elles ne couvrent que le travail synchrone, à l'exception de la requête fetch finale. Ils n'autorisent pas l'utilisation d'API asynchrones telles que IndexedDB, Compression Streams ou Web Crypto pour le hachage ou le chiffrement. De nombreuses API, en particulier les plus récentes, sont asynchrones pour éviter de bloquer le thread principal. Il est donc restrictif de ne pas pouvoir les utiliser lors du déchargement.

L'autre option consiste à utiliser des service workers, qui vivent en dehors des cycles de vie des pages individuelles. Toutefois, il s'agit d'une solution plutôt lourde, avec des exigences de cycle de vie et de gestion plus complexes pour les développeurs, sans parler des exigences supplémentaires en termes de processus et de mémoire pour les utilisateurs. Elles ne correspondent pas non plus au cas d'utilisation principal des service workers (servir de proxy pour les requêtes réseau). L'utilisation de service workers complets uniquement pour effectuer certaines tâches lors du déchargement de la page semble excessive.

Solution proposée

L'API SharedWorker est une API plus légère utilisée pour décharger le travail du thread principal. Toutefois, ils ne vivent actuellement pas au-delà de la durée de vie de l'origine (lorsque la dernière page de cette origine est déchargée). Chrome propose d'ajouter une nouvelle option à l'API SharedWorker pour permettre aux workers partagés de survivre à la destruction du document pendant une courte période.

La norme HTML encourage déjà les implémentations à maintenir les workers partagés actifs pendant une courte période après le déchargement du document, afin que la navigation entre les pages de même origine ne détruise pas, puis ne recrée pas le worker partagé. La proposition de durée de vie étendue suggère que, même si l'utilisateur n'accède pas à une destination de même origine, l'agent utilisateur doit maintenir le worker partagé en vie pendant un certain temps, afin que le travail asynchrone puisse être terminé.

La proposition consiste à autoriser les workers partagés à rester actifs après le déchargement du dernier document, pendant la même durée que les workers de serveur peuvent rester inactifs (30 secondes pour Chrome). Notez que pour les workers partagés, il s'agit d'une durée de vie maximale après le déchargement, plutôt que d'un temps d'inactivité. Autrement dit, la limite de 30 secondes commence à partir du déchargement, et non à partir du temps d'inactivité. Les tâches qui ont commencé et qui ne sont pas encore terminées au cours de cette période seront annulées.

Activer la durée de vie étendue

Pour activer cette fonctionnalité sur les sites pour les utilisateurs, inscrivez-vous à un test d'origine pour les workers partagés à durée de vie étendue. Les développeurs peuvent également l'activer pour leur propre navigateur à l'aide de l'indicateur chrome://flags/#enable-experimental-web-platform-features.

Exemple de code

Après avoir activé l'essai ou le flag de fonctionnalité, activez la durée de vie étendue comme suit :

const myWorker = new SharedWorker("worker.js", { extendedLifetime: true });

Comme les workers partagés sont également compatibles avec les blobs, cette fonctionnalité peut également être activée sans script distinct. Par exemple, pour écrire des données dans une IndexedDb :

const sharedWorkerScript = `
  const transaction = db.transaction("analytics", "readwrite");
  const store = transaction.objectStore("analytics");
  const request = store.get("visitCount");
  request.onsuccess = (event) => {
    const newCount = (event.target.result || 0) + 1;
    store.put(newCount, "visitCount");
  };
`;

document.addEventListener("pagehide", () => {
  const blob = new Blob([sharedWorkerScript], { type: "text/javascript" });
  const blobURL = URL.createObjectURL(blob);
  new SharedWorker(blobURL, { extendedLifetime: true });
});

Nous avons également une application exemple ici : https://sharedworker-extendedlifetime.netlify.app/. Lorsque la page est rechargée (ou fermée et rouverte dans les 30 secondes), le calcul précédent est toujours disponible.

Vous pouvez voir les collaborateurs partagés pour un site sur la page chrome://inspect/#workers. Nous allons bientôt améliorer cette page pour indiquer si l'option extendedLifetime a été utilisée. Les workers partagés à durée de vie étendue continueront également à s'afficher sur cette page pendant 30 secondes après le déchargement de la page.

Envoyer des commentaires

Nous avons hâte de recevoir vos commentaires sur l'extended lifetime shared worker origin trail.

La forme de l'API est en cours de discussion sur GitHub. Nous avons également une explication technique plus détaillée.

Pour nous faire part de vos commentaires sur l'implémentation de Chrome, signalez un bug Chromium.