Jake Archibald hat sich nicht nur Sorgen gemacht, dass seine Entwicklerfähigkeiten verkümmern, sondern auch überzeugend dargelegt, dass sich die Leistung von Websites oder Apps durch den intelligenten Einsatz von Service Workern drastisch verbessern lässt. Im Video erhalten Sie einen Überblick.
Wenn Sie die Ladezeit Ihrer Seite wie von Jake vorgeschlagen optimieren möchten, müssen Sie unbedingt wissen, wie sich Service Worker auf die Anfragen Ihrer Seite auswirken.
Die Resource Timing- und die User Timing-API sind wichtige Komponenten in der RUM-Infrastruktur (Real User Monitoring) vieler Websites, da Sie damit ganzheitlich nachvollziehen können, wie alle Ihre Nutzer die Leistung Ihrer Website wahrnehmen. Ein weiterer Anwendungsfall ist das Erkennen von Content-Injection. Kurz gesagt, können Sie damit fast jeden Aspekt jeder Webanfrage, die von Ihrer Website gestellt wird, nachvollziehen – es sei denn, Sie haben einen Service Worker oder einen Web Worker.
Hier ist ein kurzes Beispiel für die Verwendung, um eine Liste aller Anfragen abzurufen, 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 Service Worker überhaupt in Erwägung gezogen wurden. Der oben genannte Code kann daher nicht nachvollziehen, wie sich der Service Worker auf die APIs ausgewirkt hat.
Durch eine Reihe von Änderungen in Chrome 45 (Beta im Juli 2015) erhalten alle Arten von Workern (Web- und Service-Worker) Zugriff auf die Resource Timing API und die User Timing API. So können Sie die Netzwerkleistung für alle Ihre Nutzer im Blick behalten.
Über einen Service Worker auf Leistungsmesswerte zugreifen
Die größte Änderung ist das Hinzufügen des performance-Objekts in einem Worker-Kontext (Web- und ServiceWorker). Damit können Sie jetzt die Leistungszeitpunkte aller Anfragen nachvollziehen, die im Kontext des Workers gestellt werden. Außerdem können Sie eigene Markierungen für die Messung der JS-Ausführung festlegen. Wenn Sie nur sehen können, was im aktuellen Fenster passiert, fehlen Ihnen wichtige Timing-Informationen aus folgenden Quellen:
fetch()-Anfragen, die imoninstall-Ereignis des Service Workers gestellt werdenfetch()-Anfragen, die beim Zwischenspeichern von Daten in einemonpush-Ereignis gestellt werden, können jetzt nachvollzogen werden, um die Leistung zu ermitteln, die Nutzer sehen.- Schließlich werden
fetch()-Anfragen gestellt und vomonfetch-Handler abgefangen.
Der letzte Punkt ist wichtig. Ein Service Worker kann als Proxy zwischen der Web-UI und dem Netzwerk betrachtet werden. Das performance-Objekt im window sieht nur die Zeitangaben und Informationen für den Teil der Anfrage, den es aufruft. Es kennt den Service Worker, der sich zwischen dem Client und dem Netzwerk befindet, nicht und kann daher die Auswirkungen des Service Workers nicht nachvollziehen.
Wie kann ich das nutzen?
Ein typischer Service Worker, der Offline-First unterstützt, hat einen Installationsschritt, in dem alle Assets für die spätere Verwendung heruntergeladen und gespeichert werden.
Ein Beispiel hierfür ist das Aufzeichnen und Protokollieren der Zeitmessungsdaten des Installationsschritts. So können Sie fundierte Entscheidungen darüber treffen, wie Sie die Leistung Ihrer Installation basierend auf der tatsächlichen Nutzung durch Nutzer 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;
})
);
});
Viele Websites verwenden heute RUM, um zu verstehen, wie die meisten Nutzer ihre Website erleben. Tools wie Google Analytics melden bereits Daten zur Websitegeschwindigkeit über die Navigation Timing API, müssen aber aktualisiert werden, um Leistungsanalysen aus einem Worker-Kontext zu ermöglichen.
Wird die Navigation Timing API in Service Workern verfügbar sein?
Derzeit ist nicht geplant, die Navigation Timing API dem Service Worker-Kontext hinzuzufügen, da es in einem Service Worker keine herkömmlichen Navigationsvorgänge gibt. Interessant ist, dass für den Service Worker jede Navigation in der vom Service Worker kontrollierten Gruppe von Seiten wie ein Ressourcenabruf aussieht. Allein dadurch sind Service Worker eine äußerst attraktive Möglichkeit, den Großteil Ihrer Leistungslogik in Ihrer Web-App zu zentralisieren.