Jake Archibald maakte zich zorgen dat zijn ontwikkelaarsvaardigheden zouden verslechteren en afnemen, maar hij betoogde overtuigend dat je door slim gebruik te maken van service workers de prestaties van je site of app drastisch kunt verbeteren. Bekijk de video voor een overzicht.
Als u de laadtijd van uw pagina wilt versnellen zoals Jake voorstelt, moet u eerst begrijpen hoe service workers de verzoeken van uw pagina beïnvloeden.
De Resource Timing en de User Timing API zijn cruciale componenten in de RUM-infrastructuur (Real User Monitoring) van veel sites, omdat u hiermee een volledig beeld krijgt van hoe al uw gebruikers de prestaties van uw site ervaren ( een ander gebruiksvoorbeeld is het detecteren van contentinjectie ). Kortom, hiermee krijgt u inzicht in vrijwel elk aspect van elke webaanvraag die vanaf uw site wordt gedaan, tenzij u een service worker of web worker gebruikt.
Hier is een snel voorbeeld van hoe u dit kunt gebruiken om een lijst op te vragen van alle verzoeken die zijn gedaan aan een domein dat niet het huidige domein is.
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;
};
De API's voor Resource Timing en User Timing zijn gemaakt en geïmplementeerd voordat de Service Worker überhaupt bestond. De bovenstaande code zou niet kunnen begrijpen welke impact de Service Worker hierop heeft.
Dankzij een aantal recente wijzigingen in Chrome 45 (bètaversie in juli 2015) krijgen alle soorten workers (web- en serviceworkers) toegang tot de API's voor Resource Timing en User Timing. Zo kunt u optimaal inzicht krijgen in de netwerkprestaties van al uw gebruikers.
Toegang tot prestatiegegevens van een servicemedewerker
De grootste verandering is de toevoeging van het performance aan een Workers-context (Web- en ServiceWorkers). Hiermee krijgt u nu inzicht in de prestatietimings van alle verzoeken die in de context van de worker worden gedaan en kunt u ook uw eigen markeringen instellen voor het meten van de JS-uitvoering. Als u alleen kunt zien wat er gebeurt vanuit de context van het huidige venster, mist u kritieke timinginformatie van:
-
fetch()-verzoeken die worden gedaan binnen deoninstall-gebeurtenis van de service worker -
fetch()-aanvragen die worden gedaan tijdens het cachen van gegevens in eenonpush-gebeurtenis, kunnen nu worden getraceerd om inzicht te krijgen in de prestaties die uw gebruikers zien. - ten slotte
fetch()-aanvragen die worden gedaan en onderschept door deonfetchhandler.
Het laatste punt is belangrijk. Je kunt een service worker zien als een proxy die tussen de webinterface en het netwerk zit. Het performance in het window ziet alleen de timing en informatie voor het deel van de aanvraag dat het aanroept. Het heeft geen kennis van de service worker die tussen de client en het netwerk zit en kan daarom de impact van de service worker niet begrijpen.
Hoe kan ik dit gebruiken?
Een typische servicemedewerker die offline ondersteuning biedt, zou eerst een installatiestap hebben waarbij alle assets worden gedownload en opgeslagen voor later gebruik.
Een voorbeeld waarvoor dit kan worden gebruikt, is om de timinggegevens van de installatiestap vast te leggen en te loggen. Zo kunt u op basis van echt gebruikersgebruik weloverwogen beslissingen nemen over hoe u de prestaties van uw installatie kunt verbeteren.
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;
})
);
});
Tegenwoordig gebruiken veel sites RUM om inzicht te krijgen in hoe de meeste gebruikers hun site ervaren. Tools zoals Google Analytics rapporteren al sitesnelheidsgegevens met behulp van de Navigation Timing API, maar moeten worden bijgewerkt om prestatieanalyses vanuit een Worker-context te kunnen bevatten.
Zal de Navigatie Timing API beschikbaar zijn voor Service Workers?
Er zijn momenteel geen plannen om de Navigation Timing API toe te voegen aan de service worker-context, omdat er geen traditionele navigatie in een service worker is. Het interessante is dat voor de service worker elke navigatie in de gecontroleerde paginaset van de service worker eruitziet als een resource fetch. Dit alleen al maakt service workers een ongelooflijk aantrekkelijke manier om het grootste deel van je prestatielogica in je webapp te centraliseren.