Registrazione dei service worker

Best practice per la sincronizzazione della registrazione dei service worker.

Jeff Posnick

Servizio worker velocizzare notevolmente le visite ripetute alla tua applicazione web, ma devi per garantire che l'installazione iniziale di un service worker non riduca un l'esperienza in prima visita dell'utente.

In generale, rinviare il service worker registrazione fino al caricamento della pagina iniziale offre la migliore esperienza per gli dagli utenti, in particolare quelli che utilizzano dispositivi mobili con connessioni di rete più lente.

Boilerplate comune di registrazione

Se hai mai letto dei lavoratori dei servizi, probabilmente ti sei imbattuto in boilerplate sostanzialmente simile al seguente:

if ('serviceWorker' in navigator) {
    navigator.serviceWorker.register('/service-worker.js');
}

A volte questo testo potrebbe essere accompagnato da alcune dichiarazioni console.log(), oppure codice che rileva l'aggiornamento di una precedente registrazione dei service worker, per che invitano gli utenti ad aggiornare la pagina. Ma si tratta solo di variazioni minime solo poche righe di codice standard.

C'è qualche sfumatura in navigator.serviceWorker.register? Ci sono best practice da seguire? Non sorprende che (considerando che questo articolo non termina proprio qui), la risposta a entrambi è "sì!".

La prima visita di un utente

Consideriamo la prima visita di un utente a un'app web. Non c'è ancora alcun service worker, e il browser non ha modo di sapere in anticipo se ci sarà un servizio e il worker che viene installato alla fine.

In qualità di sviluppatore, la tua priorità dovrebbe essere assicurarti che il browser ottiene l'insieme minimo di risorse critiche necessarie per mostrare un'esperienza . Qualsiasi cosa che rallenti il recupero di queste risposte è nemico di un un'esperienza rapida e interattiva.

Ora immagina che, durante il download del codice JavaScript o delle immagini deve essere visualizzata la pagina, il browser decide di avviare un thread in background o (per brevità, supponiamo che si tratti di un filo). Supponiamo che non usi un computer desktop potente, ma piuttosto un tipo di macchina poco potente cellulare che gran parte del mondo considera come dispositivo principale. Avvio in funzione questo thread aggiuntivo aggiunge un conflitto per il tempo di CPU e la memoria che il browser altrimenti spenderebbe per il rendering di una pagina web interattiva.

È improbabile che un thread in background inattivo faccia una differenza significativa. Ma la cosa se il thread non è inattivo, ma decide che verrà avviato anche scaricare risorse dalla rete? Qualsiasi problema di CPU o memoria dovrebbe portare in secondo piano le preoccupazioni relative alla limitata larghezza di banda disponibile per molti dispositivi mobili. La larghezza di banda è preziosa, quindi non comprometterla di risorse critiche scaricando contemporaneamente le risorse secondarie.

Tutto questo vuol dire che è in corso l'avvio di un nuovo thread del service worker da scaricare e della cache di risorse in background possono contribuire al tuo obiettivo di fornire l'esperienza interattiva più breve la prima volta che un utente visita il tuo sito.

Migliorare il boilerplate

La soluzione è controllare l'avvio del service worker scegliendo quando chiamare navigator.serviceWorker.register(). Una semplice regola pratica è ritardare registrazione fino a dopo il load event si attiva su window, in questo modo:

if ('serviceWorker' in navigator) {
    window.addEventListener('load', function() {
    navigator.serviceWorker.register('/service-worker.js');
    });
}

Ma il momento giusto per avviare la registrazione del service worker può anche dipendere su cosa sta facendo la tua app web subito dopo il caricamento. Ad esempio, la conferenza Google I/O L'app web 2016 presenta una breve animazione prima di passare alla schermata principale. Il nostro team trovato che calciare la registrazione del service worker durante l'animazione potrebbe causare problemi sui dispositivi mobili di fascia bassa. Anziché offrire agli utenti un'esperienza negativa, in ritardo registrazione dei service worker fino al termine dell'animazione, quando il browser probabilmente avrà qualche secondo di inattività.

Analogamente, se la tua app web utilizza un framework che esegue una configurazione aggiuntiva dopo la pagina è stata caricata, cerca un evento specifico del framework che segnali quando il lavoro completato.

Visite successive

Finora ci siamo concentrati sull'esperienza della prima visita, ma l'impatto la registrazione ritardata del service worker riceve visite ripetute al sito? Sebbene possa sorprendere alcune persone, non dovrebbe avere alcun impatto.

Quando un service worker è registrato, passa attraverso il install e Ciclo di vita activate eventi. Una volta attivato, il service worker può gestire fetch eventi per qualsiasi le visite successive alla tua app web. Il service worker inizia prima del una richiesta per tutte le pagine che rientrano nel suo ambito, il che ha senso se si ritiene su di esso. Se il service worker esistente non era già in esecuzione prima del visita una pagina, non avrebbe la possibilità di soddisfare fetch eventi per richieste di navigazione.

Una volta che c'è un Service worker attivo, la chiamata non è importante navigator.serviceWorker.register() o, infatti, che lo chiami. Se non modifichi l'URL dello script del service worker, navigator.serviceWorker.register() è di fatto un nessuna operazione durante le visite successive. Quando chiamato è irrilevante.

Motivi per registrarsi in anticipo

Ci sono scenari in cui registrare il tuo service worker già possibile ha senso? Ti viene in mente quando il service worker utilizza clients.claim() di assumere il controllo della pagina durante la prima visita, mentre il service worker esegue runtime in modo aggressivo memorizzazione nella cache all'interno del suo gestore fetch. In questa situazione, di attivare il service worker il più rapidamente possibile, per cercare popolare le sue cache di runtime con risorse che potrebbero tornare utili in seguito. Se la tua applicazione web rientra in questa categoria, vale la pena fare un passo indietro per assicurati che il gestore install del tuo service worker non richieda risorse che lottano per la larghezza di banda con le richieste della pagina principale.

Eseguire test

Un ottimo modo per simulare una prima visita è aprire la tua app web in un Chrome Navigazione in incognito finestra, e osservare il traffico di rete nella DevTools. Come Web sviluppatore, probabilmente ricarichi un'istanza locale della tua applicazione web a decine e decine di volte al giorno. Ma rivedendo il sito quando c'è già con un service worker e cache completamente compilate, l'esperienza non sarà la stessa che un nuovo utente può ricevere ed è facile ignorare un potenziale problema.

Ecco un esempio che illustra la differenza che i tempi di registrazione potrebbero fare. Entrambi gli screenshot vengono acquisiti durante la visita di un esempio app in Modalità di navigazione in incognito che utilizza la limitazione della rete per simulare una connessione lenta.

Lo screenshot riportato sopra mostra il traffico di rete al momento della modifica dell'esempio eseguire la registrazione dei service worker il prima possibile. Puoi vedere delle richieste di prememorizzazione nella cache (le voci con l'attributo icona accanto a queste, proveniente dal gestore install del service worker) inframmezzate da richieste per le altre risorse necessarie per visualizzare la pagina.

Nello screenshot precedente, la registrazione del service worker è stata ritardata fino a dopo il è stata caricata. Puoi vedere che le richieste di pre-memorizzazione nella cache non iniziano le risorse siano state recuperate dalla rete, eliminando così qualsiasi contesa per e la larghezza di banda. Inoltre, poiché alcuni degli elementi che stiamo prememorizzando nella cache sono già presenti cache HTTP del browser, gli elementi con (from disk cache) nella dimensione colonna: possiamo completare la cache del service worker senza dover andare alla rete.

Punti bonus se si esegue questo tipo di test da un dispositivo reale di fascia bassa su un rete mobile reale. Puoi sfruttare il debug remoto di Chrome funzionalità per collegare uno smartphone Android al computer tramite USB e assicurarti che il che esegui riflettono effettivamente l'esperienza reale di molti dei tuoi utenti.

Conclusione

Ricapitolando, assicurati che gli utenti abbiano la migliore esperienza di prima visita devono avere la massima priorità. Ritardare la registrazione dei service worker fino al termine del pagina è stata caricata durante la visita iniziale. Riceverai comunque tutti i vantaggi di avere un service worker per le visite ripetute.

Un modo semplice per assicurarsi di ritardare il comando iniziale registrazione prima del caricamento della prima pagina è utilizzare quanto segue:

if ('serviceWorker' in navigator) {
    window.addEventListener('load', function() {
    navigator.serviceWorker.register('/service-worker.js');
    });
}