Data di pubblicazione: 31 lug 2025
A partire da Chrome 139, partecipa a una nuova prova dell'origine per i worker condivisi con durata prolungata. La prova aggiunge una nuova opzione extendedLifetime: true per consentire ai worker condivisi di rimanere attivi anche dopo l'ultimo scaricamento del documento.
Il caso d'uso della funzionalità di durata estesa
Molti siti vogliono eseguire alcune operazioni quando l'utente esce dalla pagina. Ad esempio, la scrittura nell'archivio o l'invio di dati ai server per salvare lo stato o registrare le analisi.
La piattaforma web fornisce alcune API per gestire alcuni dei casi d'uso più semplici, ma ognuna presenta limitazioni:
- Le API JavaScript sincrone, come le scritture
localStorage, vengono eseguite fino al completamento prima di scaricare la pagina corrente. - L'
fetch APIha una serie di opzioni comekeepalivee, più recentemente,fetchLater, che consentono di inviare richieste per un breve periodo dopo lo scaricamento del documento.
Tuttavia, queste coprono solo il lavoro sincrono, ad eccezione della richiesta fetch finale. Non consentono l'utilizzo di API asincrone come IndexedDB, Compression Streams o Web Crypto per l'hashing o la crittografia. Molte API, in particolare quelle più recenti, sono asincrone per evitare di bloccare il thread principale, quindi l'impossibilità di utilizzarle durante l'unload è restrittiva.
L'alternativa è utilizzare i service worker, che non sono legati ai cicli di vita delle singole pagine. Tuttavia, si tratta di una soluzione piuttosto pesante, con requisiti di ciclo di vita e gestione più complessi per gli sviluppatori, per non parlare di requisiti aggiuntivi di processo e memoria per gli utenti. Inoltre, non corrispondono al caso d'uso principale dei service worker (fungere da proxy per le richieste di rete). L'utilizzo di service worker completi solo per il caso d'uso del completamento di alcune operazioni durante il caricamento della pagina sembra eccessivo.
La soluzione proposta
L'API SharedWorker è un'API più leggera utilizzata per scaricare il lavoro dal thread principale. Tuttavia, al momento non sopravvivono alla durata dell'origine (quando l'ultima pagina di quell'origine viene scaricata). Chrome propone di aggiungere una nuova opzione all'API SharedWorker per consentire ai worker condivisi di sopravvivere alla distruzione dei documenti per un breve periodo di tempo.
Lo standard HTML incoraggia già le implementazioni a mantenere attivi i service worker per un breve periodo di tempo dopo lo scaricamento del documento, in modo che la navigazione tra pagine della stessa origine non distrugga e poi ricrei il service worker condiviso. La proposta di estensione della durata prevede che, anche se l'utente non naviga verso una destinazione della stessa origine, lo user agent mantenga attivo il service worker condiviso per un determinato periodo di tempo, in modo che il lavoro asincrono possa essere completato.
La proposta è di consentire ai worker condivisi di rimanere attivi dopo l'ultimo scaricamento del documento, per lo stesso periodo di tempo in cui i worker del server possono rimanere inattivi, ovvero 30 secondi per Chrome. Tieni presente che per i worker condivisi si tratta di una durata massima dopo lo scaricamento, anziché di un tempo di inattività. ovvero il limite di 30 secondi inizia dallo scaricamento, non dal tempo di inattività. Il lavoro iniziato e non ancora completato entro il periodo di tempo verrà annullato.
Attivare la durata estesa
La funzionalità può essere attivata sui siti per gli utenti registrandosi a una prova dell'origine per i worker condivisi con durata estesa. In alternativa, gli sviluppatori possono attivare la funzionalità per il proprio browser utilizzando il flag chrome://flags/#enable-experimental-web-platform-features.
Esempio di codice
Dopo aver attivato la prova o il flag della funzionalità, attiva la durata estesa nel seguente modo:
const myWorker = new SharedWorker("worker.js", { extendedLifetime: true });
Poiché i shared worker supportano anche i blob, questa funzionalità può essere attivata senza uno script separato. Ad esempio, per scrivere dati in un 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 });
});
Abbiamo anche un'applicazione di esempio qui: https://sharedworker-extendedlifetime.netlify.app/. Quando la pagina viene ricaricata (o chiusa e riaperta entro 30 secondi), il calcolo precedente è ancora disponibile.
I lavoratori condivisi sono visibili per un sito all'indirizzo chrome://inspect/#workers e a breve verrà migliorato per mostrare se è stata utilizzata l'opzione extendedLifetime. I service worker condivisi con durata estesa continueranno a essere visualizzati in questa pagina per 30 secondi dopo lo scaricamento della pagina.
Condividi il tuo feedback
Non vediamo l'ora di ricevere il tuo feedback sul percorso di origine del lavoratore condiviso con durata estesa.
La forma dell'API è in discussione su GitHub ed è disponibile una spiegazione tecnica più dettagliata.
Per fornire feedback sull'implementazione di Chrome, segnala un bug di Chromium.