Oltre a preoccuparsi che le sue competenze di sviluppatore non siano più richieste, Jake Archibald ha dimostrato in modo convincente che, utilizzando in modo intelligente i worker di servizio, puoi migliorare drasticamente il rendimento del tuo sito o della tua app. Guarda il video per una panoramica.
Se vuoi migliorare il tempo di caricamento della pagina come suggerisce Jake, devi essere in grado di capire in che modo i worker influiscono sulle richieste della tua pagina.
Le API Resource Timing e User Timing sono componenti fondamentali dell'infrastruttura RUM (Real User Monitoring) di molti siti perché ti consentono di comprendere in modo olistico come tutti gli utenti vedono le prestazioni del tuo sito (un altro caso d'uso è il rilevamento dell'iniezione di contenuti). In breve, ti consente di comprendere quasi ogni aspetto di ogni richiesta web effettuata dal tuo sito, a meno che tu non abbia un service worker o un web worker.
Ecco un breve esempio di come può essere utilizzato per ottenere un elenco di tutte le richieste effettuate a un dominio diverso da quello corrente.
var getThirdPartyRequests = function() {
var thirdPartyRequests = [];
var requests = window.performance.getEntriesByType("resource");
var currentHost = window.location.host
for(var requestIdx = 0; requestIdx < requests.length; requestIdx++) {
var request = requests[requestIdx];
var url = new URL(request.name);
var host = url.host;
if(host != currentHost) {
thirdPartyRequests.push(request);
}
}
return thirdPartyRequests;
};
Le API Resource Timing e User Timing sono state create e implementate prima che i worker di servizio fossero nell'immaginario degli ingegneri e il codice riportato sopra non sarebbe in grado di capire l'impatto del worker di servizio.
Una recente serie di modifiche in Chrome 45 (beta a luglio 2015) ti aiuterà introducendo la possibilità per tutte le forme di worker (web e di servizio) di accedere alle API Resource Timing e User Timing e quindi di consentirti di tenere traccia delle prestazioni della rete per tutti i tuoi utenti.
Accedere alle metriche sul rendimento da un servizio worker
La modifica più importante è l'aggiunta dell'oggetto performance in un contesto di worker (web e ServiceWorker) che ora ti consente di comprendere i tempi di esecuzione di tutte le richieste effettuate nel contesto del worker e di impostare i tuoi indicatori per la misurazione dell'esecuzione di JS. Se riesci a vedere solo
cosa succede nel contesto della finestra corrente, perderai informazioni
critiche sui tempi di:
- richieste
fetch()effettuate all'interno dell'eventooninstalldel service worker - Ora le richieste
fetch()effettuate durante la memorizzazione nella cache dei dati in un eventoonpushpossono essere monitorate per comprendere il rendimento visualizzato dagli utenti. - Infine, le richieste
fetch()effettuate e intercettate dall'handleronfetch.
L'ultimo punto è importante. Un modo per considerare un worker di servizio è come un proxy
che si trova tra l'interfaccia utente web e la rete. L'oggetto performance su
window vede solo i tempi e le informazioni relativi alla parte della richiesta che invoca, non ha conoscenza del service worker tra il client
e la rete, quindi non può comprendere l'impatto del service worker.
Come posso utilizzarlo?
Un tipico service worker che supporta la modalità offline first avrà un passaggio di installazione in cui scaricherà e salverà tutti gli asset per un uso successivo
Un esempio di utilizzo potrebbe essere registrare e registrare i dati relativi ai tempi del passaggio di installazione in modo da poter prendere alcune decisioni ponderate su come migliorare il rendimento dell'installazione in base all'utilizzo reale degli utenti.
self.addEventListener("install", function() {
var urls = [
'/',
'/images/chrome-touch-icon-192x192.png',
'/images/ic_add_24px.svg',
'/images/side-nav-bg@2x.jpg',
'/images/superfail.svg',
'/scripts/voicememo-core.js',
'/styles/voicememo-core.css',
'/third_party/Recorderjs/recorder.js',
'/third_party/Recorderjs/recorderWorker.js',
'/third_party/Recorderjs/wavepcm.js',
'/third_party/moment.min.js',
'/favicon.ico',
'/manifest.json'
];
urls = urls.map(function(url) {
return new Request(url, {credentials: 'include'});
});
event.waitUntil(
caches
.open(CACHE_NAME + '-v' + CACHE_VERSION)
.then(function(cache) {
// Fetch all the URL's and store in the cache
return cache.addAll(urls);
})
.then(function () {
// Analyze all the requests
var requests = self.performance.getEntriesByType("resource");
// Loop across all the requests and save the timing data.
return;
})
);
});
Oggi molti siti utilizzano il RUM per capire come la maggior parte degli utenti utilizza il sito. Strumenti come Google Analytics registrano già i dati sulla velocità del sito utilizzando l'API Navigation Timing, ma dovranno essere aggiornati per includere l'analisi del rendimento da un contesto di worker.
L'API Navigation Timing arriverà nei Service Worker
Al momento non è prevista l'aggiunta dell'API Navigation Timing al contesto del worker di servizio, poiché in un worker di servizio non sono presenti navigazioni tradizionali. La cosa interessante è che per il service worker ogni navigazione nell'insieme di pagine controllato dal service worker sembra un recupero di risorse. Questo fatto da solo rende i service worker un modo incredibilmente efficace per centralizzare la maggior parte della logica di rendimento nella tua app web.