Jake Archibald befürchtete nicht, dass seine Entwicklerfähigkeiten verrotten und abfallen. Er hat aber überzeugend Argumente dafür vorgebracht, dass sich die Leistung Ihrer Website oder App durch den intelligenten Service Worker erheblich verbessern lässt. Sehen Sie sich das Video an, um einen Überblick zu erhalten.
Wenn ihr die Seitenladezeit optimieren möchtet, wie Jakob schon sagt, müsst ihr wirklich verstehen, wie Service Worker die Anfragen eurer Seite beeinflussen.
Das Resource Timing und die User Timing API sind kritische Komponenten in der RUM-Infrastruktur (Real User Monitoring) vieler Websites, da du damit ganzheitlich nachvollziehen kannst, wie alle Nutzer die Leistung deiner Website sehen (ein weiterer Anwendungsfall ist das Erkennen von Einschleusungen von Inhalten). Kurz gesagt können Sie nahezu jeden Aspekt jeder Webanfrage von Ihrer Website verstehen, es sei denn, Sie haben einen Service Worker oder einen Web Worker.
Hier ist ein kurzes Beispiel, wie Sie damit eine Liste aller Anfragen abrufen können, die an eine Domain gesendet wurden, die nicht die aktuelle Domain ist.
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;
};
Die Resource Timing API und die User Timing API wurden erstellt und implementiert, bevor der Service Worker für die Entwickler ein Kinderspiel war und der obige Code nicht nachvollziehen konnte, welche Auswirkungen der Service Worker auf sie hatte.
Durch eine Reihe von Änderungen in Chrome 45 (Beta im Juli 2015) können alle Mitarbeiter (Web- und Service Worker) Zugriff auf die Resource Timing API und die User Timing API erhalten. So behalten Sie die Netzwerkleistung aller Ihrer Nutzer im Blick.
Über einen Service Worker auf Leistungsmesswerte zugreifen
Die größte Änderung besteht darin, das Objekt performance in einen Worker-Kontext (Web und ServiceWorkers) einzufügen. Damit können Sie jetzt den zeitlichen Ablauf der Leistung aller Anfragen nachvollziehen, die im Kontext des Workers gestellt werden, und eigene Markierungen für die Messung der JS-Ausführung setzen. Wenn Sie nur sehen können, was im Kontext des aktuellen Fensters geschieht, verpassen Sie wichtige Zeitinformationen aus:
fetch()-Anfragen innerhalb desoninstall-Ereignisses des Service Workersfetch()-Anfragen, die beim Caching von Daten in einemonpush-Ereignis gestellt werden, können jetzt verfolgt werden, um die Leistung Ihrer Nutzer zu verstehen.fetch()-Anfrage, die vomonfetch-Handler gestellt und abgefangen wird.
Der letzte Punkt ist wichtig. Ein Service Worker kann sich als Proxy zwischen der Web-UI und dem Netzwerk vorstellen. Das performance-Objekt im window sieht nur die Zeitangaben und Informationen für den Teil der Anfrage, den es aufruft. Der zwischen Client und Netzwerk liegende Service Worker ist nicht bekannt, sodass die Auswirkungen des Service Workers nicht erkannt werden können.
Wie kann ich diese Funktion verwenden?
Ein typischer Service Worker, der zuerst Offline unterstützt, hat einen Installationsschritt, bei dem alle Assets zur späteren Verwendung heruntergeladen und gespeichert werden.
Dies kann beispielsweise verwendet werden, um die Zeitdaten des Installationsschritts aufzuzeichnen und zu protokollieren. So können Sie anhand der tatsächlichen Nutzung in der Praxis einige Entscheidungen darüber treffen, wie Sie die Leistung Ihrer Installation verbessern können.
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;
})
);
});
Heutzutage verwenden viele Websites RUM, um nachzuvollziehen, wie die Mehrheit ihrer Nutzer ihre Website sieht. Tools wie Google Analytics melden bereits Daten zur Websitegeschwindigkeit über die Navigation Timing API, müssen jedoch aktualisiert werden, um die Leistungsanalyse aus einem Worker-Kontext zu berücksichtigen.
Wird die Navigation Timing API bei Service Workern verfügbar sein?
Derzeit gibt es keine Pläne, die Navigation Timing API in den Service Worker-Kontext aufzunehmen, da es in einem Service Worker keine herkömmlichen Navigationen gibt. Interessant ist, dass für den Service Worker jede Navigation in den vom Service Worker kontrollierten Seiten wie ein Ressourcenabruf aussieht. All das macht Service Worker zu einer überzeugenden Möglichkeit, den Großteil der Leistungslogik in Ihrer Webanwendung zu zentralisieren.