À l'exception de Jake Archibld, qui s'inquiétait de la dégradation ou de la chute de ses compétences en développement, il a clairement démontré qu'en utilisant intelligemment un service worker, vous pouvez améliorer considérablement les performances de votre site ou application. Regardez la vidéo pour en savoir plus.
Si vous souhaitez optimiser le temps de chargement de votre page comme indiqué Jake, vous devez vraiment être capable de comprendre l'impact des service workers sur les requêtes de votre page.
Les API Resource Timing et User Timing sont des composants essentiels de l'infrastructure RUM (Real User Monitoring) de nombreux sites, car elles vous permettent de comprendre de manière globale comment l'ensemble de vos utilisateurs voient les performances de votre site (un autre cas d'utilisation consiste à détecter les injections de contenu). En résumé, il vous permet de comprendre presque tous les aspects de chaque requête Web envoyée à partir de votre site, sauf si vous avez un service worker ou un service worker.
Voici un exemple rapide de la manière dont il peut être utilisé pour obtenir la liste de toutes les requêtes adressées à un domaine autre que le domaine actuel.
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;
};
Les API Resource Timing et User Timing ont été créées et mises en œuvre avant que le service worker ne soit un scintillement dans l'œil des ingénieurs, et que le code ci-dessus ne puisse pas comprendre l'impact du service worker sur cette API.
Un ensemble de modifications récentes apportées à Chrome 45 (bêta en juillet 2015) va vous aider en permettant à toutes les formes de workers (Web et service worker) d'accéder aux API Resource Timing et User Timing, et de gérer ainsi les performances réseau de tous vos utilisateurs.
Accéder aux métriques de performances à partir d'un service worker
Le changement le plus important est l'ajout de l'objet performance dans un contexte de workers (Web et ServiceWorkers). Il vous permettra à présent de comprendre les temps de performances de toutes les requêtes effectuées dans le contexte du nœud de calcul et de définir vos propres marques pour la mesure de l'exécution JS. Si vous ne pouvez voir que ce qui se passe dans le contexte de la fenêtre actuelle, vous passerez à côté d'informations temporelles critiques:
- Requêtes
fetch()effectuées dans l'événementoninstalldu service worker - Les requêtes
fetch()effectuées lors de la mise en cache des données dans un événementonpushpeuvent désormais être suivies pour comprendre les performances observées par vos utilisateurs. - Enfin, les requêtes
fetch()sont effectuées et interceptées par le gestionnaireonfetch.
Le dernier point est important. Un service worker est comparable à un proxy situé entre l'interface utilisateur Web et le réseau. L'objet performance sur window ne voit que les codes temporels et les informations de la partie de la requête qu'il appelle. Il ne sait pas si le service worker se situe entre le client et le réseau, et ne peut donc pas comprendre l'impact du service worker.
Comment puis-je l'utiliser ?
Pour un service worker type qui prend en charge l'utilisation hors connexion en priorité, il est préférable de procéder à l'étape d'installation afin de télécharger et d'enregistrer tous les éléments pour une utilisation ultérieure.
Cela peut par exemple être utilisé pour enregistrer et consigner les données temporelles de l'étape d'installation afin que vous puissiez prendre des décisions mesurées sur la façon d'améliorer les performances de votre installation en fonction de l'utilisation réelle des utilisateurs.
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;
})
);
});
Aujourd'hui, de nombreux sites utilisent le RUM pour comprendre comment la majorité de leurs visiteurs consultent leur site. Des outils tels que Google Analytics génèrent déjà des rapports sur les données de vitesse du site à l'aide de l'API Navigation Timing, mais ils devront être mis à jour pour inclure l'analyse des performances à partir d'un contexte de nœud de calcul.
L'API Navigation Timing sera-t-elle disponible pour les Service Workers ?
Pour l'instant, il n'est pas prévu d'ajouter l'API Navigation Timing au contexte du service worker, car il n'y a pas de navigations traditionnelles dans un service worker. Il est intéressant de noter que pour le service worker, chaque navigation dans l'ensemble de pages contrôlé par un service worker ressemble à une extraction de ressources. Cela rend les service workers un moyen incroyablement convaincant de centraliser la majeure partie de votre logique de performances dans votre application Web.