Prova dell'origine dell'API Static Routing Service worker

Brendan Kenny

I worker di servizio sono un potente strumento per consentire ai siti web di funzionare offline e di creare regole di memorizzazione nella cache specializzate per se stessi. Un gestore fetch del servizio worker vede ogni richiesta da una pagina che controlla e può decidere se rispondere con una risposta dalla cache del servizio worker o addirittura riscrivere l'URL per recuperare un'altra risposta, ad esempio in base alle preferenze dell'utente locale.

Tuttavia, i service worker possono comportare 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 servizio worker, il browser deve attendere che il servizio worker venga avviato ed eseguito per sapere quali contenuti caricare. Questo costo di avvio può essere ridotto, ma significativo, per gli sviluppatori che utilizzano i worker di servizio per migliorare le prestazioni tramite strategie di memorizzazione nella cache.

Il precaricamento della navigazione è un approccio per risolvere il problema: consente di effettuare richieste di navigazione sulla rete in parallelo all'avvio del servizio worker, ma è limitato alle richieste di navigazione iniziali e include comunque il servizio worker nel percorso critico. Dal lancio del precaricamento della navigazione, sono stati fatti diversi tentativi per sviluppare una soluzione più generale al problema, inclusi modi per impedire del tutto il blocco di alcune richieste all'avvio del servizio worker.

L'API di routing statico di Service Worker

A partire da Chrome 116, l'API di routing statico dei service worker sperimentale è disponibile per testare il primo passaggio di una soluzione di questo tipo. Quando un servizio worker viene installato, può utilizzare l'API di routing statico del servizio worker per dichiarare in modo dichiarativo come devono essere recuperati determinati percorsi delle risorse.

Nella versione iniziale dell'API, i percorsi possono essere dichiarati come da pubblicare sempre 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 questi percorsi prima del completamento dell'avvio del servizio worker. In questo modo, il service worker viene rimosso dai percorsi che sai non richiedono un service worker.

Per utilizzare l'API, il service worker chiama event.registerRouter sull'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 si applica la regola utilizzando l'API Pattern URL per abbinare i percorsi delle risorse. La proprietà può accettare un'istanza URLPattern o un oggetto normale equivalente compatibile con il passaggio al costruttore URLPattern (ad esempio new URLPattern({pathname: '*.jpg'}) o solo {pathname: '*.jpg'}).

  La flessibilità dei pattern URL consente alla regola di associare qualcosa di semplice come qualsiasi risorsa in un percorso a condizioni molto specifiche e dettagliate. In genere, gli utenti delle librerie di routing più diffuse dovrebbero conoscere i pattern.

• source: specifica in che modo verranno caricate le risorse corrispondenti a condition. Al momento è supportato solo il valore 'network' (che consente di bypassare il service worker per caricare la risorsa direttamente sulla rete), ma in futuro è previsto di estenderlo ad altri valori.

Casi d'uso

Come spiegato, la versione iniziale dell'API è essenzialmente una via di fuga dal controllo dei worker di servizio per alcuni percorsi. L'utilizzo di questa funzionalità dipenderà dal modo in cui utilizzi il tuo service worker e da come gli utenti navigano nel tuo sito.

Un esempio potrebbe essere il caso in cui il tuo sito utilizzi una strategia cache-first (riassegnazione alla rete), ma alcuni contenuti vengono visitati così raramente che non ha molto senso che vengano memorizzati nella cache (come i contenuti archiviati o i feed RSS). La limitazione di questi percorsi da recuperare dalla rete solo può essere configurata nel servizio worker, ma il servizio worker deve comunque essere avviato ed eseguito per decidere come gestire queste richieste.

L'API di routing statico, invece, aggira 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, è previsto che questa configurazione diventi più flessibile e supporti più scenari, ad esempio la concorrenza dichiarativa di un recupero di rete e l'avvio del servizio worker. Per ulteriori dettagli, consulta l'esplorazione della specifica di una potenziale "forma finale" dell'API.

Prova dell'API di routing statico di Service Worker

L'API di routing statico di Service Worker è disponibile in Chrome a partire dalla versione 116 nell'ambito di 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 delle origini" per informazioni di base sulle prove delle origini.

Per i test locali, l'API di routing statico dei service worker può essere attivata con un chrome://flags/#service-worker-static-routeroppure eseguendo Chrome dalla riga di comando, ad esempio con --enable-features=ServiceWorkerStaticRouter.

Feedback e indicazioni future

L'API di routing statico dei service worker è in fase di sviluppo attivo e la sua forma è ancora in evoluzione. Se ritieni che possa esserti utile, provala tramite la prova di origine e fornisci un feedback sull'API, sull'implementazione e sulle funzionalità disponibili.