I service worker sono un potente strumento per consentire ai siti web di funzionare offline e di creare autonomamente regole di memorizzazione nella cache specializzate. Un gestore fetch del service worker vede tutte le richieste provenienti da una pagina che controlla e può decidere se vuole fornire una risposta dalla cache del service worker o anche riscrivere l'URL per recuperare una risposta completamente diversa, ad esempio in base alle preferenze locali dell'utente.
Tuttavia, può essere previsto un costo delle prestazioni per i service worker quando una pagina viene caricata per la prima volta dopo un certo periodo di tempo e il service worker di controllo non è 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 di avvio può essere ridotto, ma significativo, per gli sviluppatori che utilizzano i service worker per migliorare le prestazioni attraverso strategie di memorizzazione nella cache.
Il precaricamento della 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. Da quando è stato lanciato il precaricamento della navigazione, sono stati effettuati diversi sforzi per sviluppare una soluzione più generale allo spazio dei problemi, inclusi modi per non bloccare alcune richieste all'avvio del service worker.
L'API Service Worker Static Routing
A partire da Chrome 116, è disponibile l'API sperimentale Service Worker Static Routing per testare il primo passaggio di questa soluzione. Una volta installato, un service worker può utilizzare l'API Service Worker Static Routing per indicare in modo dichiarativo come recuperare determinati percorsi delle risorse.
Nella versione iniziale dell'API, è possibile dichiarare che i percorsi vengono sempre gestiti 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 di servizio abbia terminato l'avvio. In questo modo il service worker viene rimosso dai percorsi che non richiedono un service worker.
Per utilizzare l'API, il service worker chiama event.registerRouter all'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',
}]);
}
});
Generalmente ciascuna regola ha due proprietà:
condition: consente di specificare quando si applica la regola utilizzando l'API Pattern URL per trovare corrispondenze dei percorsi delle risorse. La proprietà può prendere un'istanzaURLPatterno l'oggetto normale equivalente compatibile con la trasmissione al costruttoreURLPattern(ad esempio,new URLPattern({pathname: '*.jpg'})o solo{pathname: '*.jpg'}).La flessibilità dei pattern URL significa che la regola può associare qualcosa di semplice come qualsiasi risorsa di un percorso, a condizioni molto specifiche e dettagliate. In genere i pattern sono familiari agli utenti delle librerie di routing più diffuse.
source: specifica come verranno caricate le risorse che corrispondono acondition. Attualmente è supportato solo il valore'network'(ignorando il service worker per caricare direttamente la risorsa sulla rete), ma si prevede di espanderlo ad altri valori in futuro.
Casi d'uso
Come spiegato, la versione iniziale dell'API è essenzialmente un'alternativa al controllo dei worker di servizio per alcuni percorsi. L'utilizzo di questa funzionalità dipende da come usi il Service worker e da come gli utenti attraversano il tuo sito.
Un esempio potrebbe essere il caso in cui il tuo sito utilizza una strategia cache-first (ritornando alla rete), ma alcuni contenuti vengono visitati così raramente che registrano un valore minimo o nullo nella cache (come i contenuti archiviati o i feed RSS). La limitazione di questi percorsi per il recupero dalla rete può essere impostata solo nel service worker, ma il service worker 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'evoluzione dell'API Service Worker Static Routing, il piano prevede che questa configurazione diventi più flessibile e supporti più scenari, come la corsa dichiarativa di un recupero della rete e di un avvio del service worker. Per ulteriori dettagli, consulta l'esplorazione della spiegazione delle specifiche 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, dopo una prova dell'origine, che consente agli sviluppatori di testare l'API sul proprio sito con utenti reali per misurare l'effetto. Consulta la "Guida introduttiva alle prove dell'origine" per informazioni di base sulle prove dell'origine.
Per i test locali, l'API Service Worker Static Routing può essere abilitata con un
flag in chrome://flags/#service-worker-static-router o eseguendo Chrome
dal comando come con --enable-features=ServiceWorkerStaticRouter.
Feedback e indicazioni future
L'API Service Worker Static Routing è in fase di sviluppo attivo e ancora in fase di sviluppo. Se ti sembra che possa esserti utile, prova la funzionalità tramite la prova dell'origine e fornisci feedback su API, implementazione e funzionalità disponibili.