I Service worker sono uno strumento efficace per consentire il funzionamento offline dei siti web e la creazione di regole di memorizzazione nella cache specializzate. Un gestore fetch
del service worker vede ogni richiesta proveniente da una pagina che controlla e può decidere se
ricevere una risposta dalla cache del service worker o persino riscrivere l'URL
per recuperare una risposta completamente diversa, ad esempio in base alle preferenze dell'utente
locali.
Tuttavia, i service worker possono avere un costo in termini di prestazioni quando una pagina viene caricata per la prima volta dopo un po' di tempo e il service worker di controllo non è attualmente in esecuzione. Poiché tutti i recuperi devono avvenire tramite il service worker, il browser deve attendere l'avvio e l'esecuzione del service worker per sapere quali contenuti caricare. Questo costo per startup può essere basso, ma significativo, per gli sviluppatori che utilizzano i service worker per migliorare le prestazioni tramite strategie di memorizzazione nella cache.
Il precaricamento di navigazione è un approccio per risolvere il problema, consentendo di effettuare richieste di navigazione sulla rete in parallelo all'avvio del service worker, ma è limitato alle richieste di navigazione iniziali e include comunque il service worker nel percorso critico. Dal lancio del precaricamento della navigazione, sono stati effettuati diversi sforzi per sviluppare una soluzione più generale per lo spazio dei problemi, inclusi i modi per non bloccare affatto alcune richieste all'avvio del service worker.
API Service Worker Static Routing
A partire da Chrome 116, l'API sperimentale Service Worker Static Routing è disponibile per testare il primo passaggio verso questa soluzione. Quando è installato un service worker, può utilizzare l'API Service Worker Static Routing per indicare in modo dichiarativo come devono essere recuperati determinati percorsi delle risorse.
Nella versione iniziale dell'API, è possibile dichiarare che i percorsi siano sempre pubblicati dalla rete, non dal service worker. Quando un URL controllato viene caricato in un secondo momento, il browser può iniziare a recuperare le risorse da quei percorsi prima che il worker del servizio abbia terminato l'avvio. In questo modo il service worker viene rimosso dai percorsi che non necessitano di un service worker.
Per utilizzare l'API, il service worker chiama event.registerRouter nell'evento install
con un insieme di regole:
self.addEventListener('install', event => {
if (event.registerRouter) {
// Go straight to the network and bypass invoking "fetch" handlers for all
// same-origin URLs that start with '/form/'.
event.registerRouter([{
condition: {
urlPattern: {pathname: '/form/*'},
},
source: 'network',
}]);
}
});
In genere, ogni regola ha due proprietà:
condition: specifica quando viene applicata la regola utilizzando l'API Pattern URL per corrispondere ai percorsi delle risorse. La proprietà può gestire un'istanzaURLPatterno l'oggetto normale equivalente compatibile con il passaggio al costruttoreURLPattern(ad esempionew URLPattern({pathname: '*.jpg'})o solo{pathname: '*.jpg'}).La flessibilità dei pattern URL implica che la regola possa associare qualcosa di semplice come qualsiasi risorsa in un percorso, a condizioni molto specifiche e dettagliate. In genere i pattern dovrebbero essere familiari agli utenti delle librerie di routing più diffuse.
source: specifica come verranno caricate le risorse corrispondenti acondition. Attualmente è supportato solo il valore'network'(ignorando il service worker per caricare la risorsa direttamente sulla rete), ma si prevede di espanderlo ad altri valori in futuro.
Casi d'uso
Come spiegato, la versione iniziale dell'API è essenzialmente un'uscita dal controllo dei service worker per alcuni percorsi. Il modo in cui questa opzione può essere utilizzata dipenderà dall'utilizzo del service worker e dal modo in cui gli utenti navigano nel sito.
Ad esempio, il tuo sito potrebbe utilizzare una strategia di tipo "cache-first" (ricorrendo alla rete), ma alcuni contenuti vengono visitati così raramente da lasciare poco o nessun valore a finire nella cache (ad esempio, contenuti archiviati o feed RSS). La limitazione di questi percorsi per il recupero dalla rete può essere impostata nel service worker, ma quest'ultimo deve comunque avviarsi ed eseguire per decidere come gestire queste richieste.
L'API di routing statico, invece, ignora completamente il service worker con alcune righe dichiarative:
self.addEventListener('install', event => {
if (event.registerRouter) {
event.registerRouter([{
condition: {
urlPattern: {pathname: '/feeds/*.xml'},
},
source: 'network',
}, {
condition: {
urlPattern: {pathname: '/archives/*'},
},
source: 'network',
}]);
}
});
Con l'evolversi dell'API Service Worker Static Routing, questa configurazione prevede una maggiore flessibilità e il supporto di più scenari, come l'esecuzione dichiarativa di un recupero di rete e di avvio dei service worker. Per ulteriori dettagli, consulta l'esplorazione esplicativa della specifica di una potenziale "forma finale" dell'API.
Prova dell'API Service Worker Static Routing
L'API Service Worker Static Routing è disponibile in Chrome a partire dalla versione 116 dietro una prova dell'origine, che consente agli sviluppatori di testare l'API sul proprio sito con utenti reali per misurarne l'effetto. Consulta la sezione "Iniziare a utilizzare le prove dell'origine" per informazioni in background sulle prove dell'origine.
Per i test locali, l'API Service Worker Static Routing può essere abilitata con un flag in corrispondenza di chrome://flags/#service-worker-static-router o eseguendo Chrome dal comando come in --enable-features=ServiceWorkerStaticRouter.
Feedback e indicazioni future
L'API Service Worker Static Routing è in fase di sviluppo e continua in fase di sviluppo. Se ti sembra che possa esserti utile, prova questa funzionalità tramite la prova dell'origine e fornisci un feedback sull'API, sull'implementazione e sulle funzionalità disponibili.