Oltre a Jake Archibald che si preoccupava che le sue abilità di sviluppatore vadano a maturare e cadano, ha sostenuto in modo netto che, utilizzando in modo intelligente il service worker, è possibile migliorare drasticamente le prestazioni del tuo sito o della tua app. Guarda il video per una panoramica.
Se intendi aumentare il tempo di caricamento della pagina come suggerisce Jake, devi essere in grado di capire come i Service worker influenzano le richieste della tua pagina.
Resource Timing e User Timing sono componenti fondamentali nell'infrastruttura RUM (Real User Monitoring) di molti siti perché consentono di comprendere in modo olistico il modo in cui tutti gli utenti vedono le prestazioni del tuo sito (Un altro caso d'uso è il rilevamento dell'inserimento di contenuti). In breve, ti permette 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 rapido esempio di come può essere utilizzato per ottenere un elenco di tutte le richieste effettuate a un dominio diverso da quello attuale.
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 il service worker diventasse un luccichio agli occhi degli ingegneri e il codice riportato sopra non sarebbe stato in grado di comprendere l'impatto che ha avuto il Service Worker.
Una recente serie di modifiche in Chrome 45 (beta a luglio 2015) è utile introducendo la possibilità per tutti i lavoratori (web e service worker) di accedere alle API Resource Timing e User Timing, in modo da tenere sotto controllo le prestazioni della rete per tutti gli utenti.
Accesso alle metriche delle prestazioni da un service worker
Il cambiamento più grande è l'aggiunta dell'oggetto performance a un contesto Workers (Web e ServiceWorker), che ora ti consente di comprendere i tempi delle prestazioni di tutte le richieste effettuate nel contesto del worker e di impostare i tuoi contrassegni per la misurazione dell'esecuzione di JavaScript. Se riesci a vedere solo cosa succede nel contesto della finestra corrente, ti sfuggirebbero informazioni importanti sulle tempistiche:
- Richieste
fetch()effettuate all'interno dell'eventooninstalldel service worker - Ora è possibile tracciare le richieste
fetch()effettuate durante la memorizzazione nella cache di dati in un eventoonpushper comprendere le prestazioni visibili agli utenti. - infine, le richieste
fetch()effettuate e intercettate dal gestore dionfetch.
L'ultimo punto è importante. Un service worker può essere paragonato a un proxy
che si trova tra l'interfaccia utente web e la rete. L'oggetto performance nell'oggetto window vede solo i tempi e le informazioni per la parte della richiesta richiamata, non è a conoscenza del service worker che si trova tra il client e la rete, pertanto non può comprendere l'impatto del service worker.
Come faccio a utilizzarla?
Un service worker tipico che supporta prima la modalità offline ha una passaggio di installazione in cui scaricherà e salverà tutti gli asset per un utilizzo futuro
Un esempio di utilizzo di questa funzionalità è la registrazione e la registrazione dei dati relativi alle tempistiche del passaggio di installazione, in modo da poter prendere decisioni misurate su come migliorare le prestazioni dell'installazione in base all'utilizzo reale dell'utente.
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 usano RUM per capire in che modo la maggior parte degli utenti usufruisce del sito. Strumenti come Google Analytics segnalano già i dati relativi alla velocità del sito utilizzando l'API Navigation Timing, ma dovranno essere aggiornati per includere l'analisi delle prestazioni da un contesto Worker.
L'API Navigation Timing arriverà ai Service Workers
Al momento non è prevista l'aggiunta dell'API Navigation Timing al contesto del service worker, perché un service worker non prevede navigazioni tradizionali. La cosa interessante è che per il service worker, ogni navigazione nell'insieme di pagine controllate del service worker sembra un recupero di risorse. Questo da solo rende i service worker un modo incredibilmente efficace per centralizzare la maggior parte della logica delle prestazioni nella tua app web.