Afgezien van het feit dat Jake Archibald zich zorgen maakte over het wegkwijnen en afnemen van zijn ontwikkelaarsvaardigheden, maakte hij er een sterk argument van dat je door op een intelligente manier gebruik te maken van servicemedewerkers de prestaties van je site of app drastisch kunt verbeteren. Bekijk de video voor een overzicht.
Als je de laadtijd van je pagina een boost wilt geven, zoals Jake suggereert, moet je echt kunnen begrijpen hoe servicemedewerkers de verzoeken van je 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 holistisch kunt begrijpen hoe al uw gebruikers de prestaties van uw site zien ( een ander gebruiksscenario is het detecteren van inhoudsinjectie ). Kortom, u krijgt hiermee inzicht in bijna elk aspect van elk webverzoek dat vanaf uw site wordt gedaan, tenzij u een servicemedewerker of een webmedewerker heeft.
Hier is een kort voorbeeld van hoe het kan worden gebruikt om een lijst te krijgen 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 Resource Timing en User Timing API's zijn gemaakt en geïmplementeerd voordat de servicemedewerker een twinkeling in de ogen van de ingenieur was en de bovenstaande code niet zou kunnen begrijpen welke invloed de servicemedewerker hierop had.
Een recente reeks wijzigingen in Chrome 45 (bèta in juli 2015) zal u helpen door de mogelijkheid te introduceren voor alle vormen van werknemers (web- en servicemedewerkers) om toegang te hebben tot de API's voor resourcetiming en gebruikerstiming, zodat u houd de netwerkprestaties voor al uw gebruikers op de hoogte.
Toegang tot prestatiestatistieken van een servicemedewerker
De grootste verandering is de toevoeging van het performance aan een Workers-context (Web en ServiceWorkers), waarmee u nu de prestatietiming kunt begrijpen van alle verzoeken die in de context van de werker worden gedaan en waarmee u ook uw eigen cijfers kunt bepalen voor het meten van JS-uitvoering. Als u alleen vanuit de context van het huidige venster kunt zien wat er gebeurt, mist u cruciale timinginformatie van:
-
fetch()-verzoeken die binnen deoninstallgebeurtenis van de servicemedewerker zijn gedaan -
fetch()verzoeken die worden gedaan bij 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()-verzoek dat wordt gedaan en onderschept door deonfetchhandler.
Het laatste punt is belangrijk. Eén manier om aan een servicemedewerker te denken is als een proxy die zich tussen de webinterface en het netwerk bevindt. Het performance in het window ziet alleen de timing en informatie voor het deel van het verzoek dat het aanroept, het heeft geen kennis van de servicemedewerker die tussen de client en het netwerk zit, dus het kan de impact van de servicemedewerker niet begrijpen .
Hoe kan ik dit gebruiken?
Een typische servicemedewerker die eerst offline ondersteuning biedt, heeft een installatiestap waarin alle assets worden gedownload en opgeslagen voor later gebruik
Een voorbeeld van waar dit gebruikt kan worden is het vastleggen en loggen van de timinggegevens van de installatiestap, zodat u weloverwogen beslissingen kunt nemen over hoe u de prestaties van uw installatie kunt verbeteren op basis van echt gebruikersgebruik.
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 te begrijpen hoe de meerderheid van hun gebruikers hun site ervaren. Tools zoals Google Analytics rapporteren al sitesnelheidsgegevens met behulp van de Navigation Timing API, maar zullen moeten worden bijgewerkt om prestatieanalyses vanuit een Worker-context op te nemen.
Zal de Navigation Timing API aankomen bij servicemedewerkers?
Op dit moment zijn er geen plannen om de Navigation Timing API toe te voegen aan de context van servicemedewerkers, omdat er geen traditionele navigatie is in een servicemedewerker. Het interessante is dat voor de servicemedewerker elke navigatie in de gecontroleerde reeks pagina's van de servicemedewerker eruit ziet als het ophalen van bronnen. Dit alleen al maakt servicemedewerkers een ongelooflijk aantrekkelijke manier om het grootste deel van uw prestatielogica in uw webapp te centraliseren.