Enregistrement d'un service worker

Bonnes pratiques pour chronométrer l'enregistrement de vos service workers

Jeff Posnick

Services les nœuds de calcul peut accélérer significativement les visites répétées sur votre application Web, mais vous devez pour s'assurer que l'installation initiale d'un service worker ne dégrade pas de l'expérience de première visite de l'utilisateur.

En général, le report d'un service worker enregistrement avant le chargement de la page initiale offrira la meilleure expérience pour les utilisateurs, en particulier ceux qui ont des appareils mobiles avec des connexions réseau lentes.

Texte standard d'inscription commun

Si vous avez déjà entendu parler des service workers, vous avez probablement déjà rencontré code récurrent semblable à ce qui suit:

if ('serviceWorker' in navigator) {
    navigator.serviceWorker.register('/service-worker.js');
}

Elle peut parfois être accompagnée de quelques instructions console.log(). code qui détecte une mise à jour d'un enregistrement de service worker précédent, afin de invitant les utilisateurs à actualiser la page. Mais ce ne sont que des variations mineures avec les quelques lignes de code standards.

Existe-t-il des nuances pour navigator.serviceWorker.register ? Existe-t-il à suivre ? Sans surprise, étant donné que cet article ne se termine pas la réponse à ces deux questions est "oui !"

Première visite d'un utilisateur

Prenons l'exemple de la première visite d'un utilisateur sur une application Web. Il n'y a pas encore de service worker, et le navigateur n'a aucun moyen de savoir à l'avance s'il y aura un service qui est finalement installé.

En tant que développeur, votre priorité doit être de vous assurer que le navigateur obtient l'ensemble minimal de ressources critiques nécessaires pour afficher une fenêtre interactive . Tout ce qui ralentit la récupération de ces réponses est l'ennemi pour une expérience plus rapide et interactive.

Imaginons maintenant qu'au cours du téléchargement du code JavaScript ou des images votre page doit s'afficher, votre navigateur décide de démarrer un fil de discussion en arrière-plan ou (par souci de concision, nous considérons qu'il s'agit d'un thread). Partez du principe que vous n'êtes pas sur un ordinateur de bureau puissant, mais plutôt le type de manque de puissance téléphone mobile que la plupart des gens considèrent comme leur principal appareil. Rotation en cours ce thread supplémentaire ajoute des conflits de temps CPU et de mémoire que votre navigateur qui auraient autrement consacré l'affichage d'une page Web interactive.

Il est peu probable qu'un thread d'arrière-plan inactif fasse une différence significative. Mais que si ce thread n'est pas inactif, mais décide à la place qu'il va également démarrer télécharger des ressources à partir du réseau ? Tout problème lié au processeur ou à la mémoire les conflits devraient prendre un peu de recul pour s'inquiéter de la bande passante limitée disponibles pour de nombreux appareils mobiles. La bande passante est précieuse, alors ne fiez pas les ressources critiques en téléchargeant les ressources secondaires en même temps.

En résumé, lancer un nouveau thread Service Worker pour télécharger et mettre en cache des ressources en arrière-plan peut aller à l'encontre de votre objectif : fournir le délai d'interaction le plus court la première fois qu'un utilisateur accède à votre sur votre site.

Améliorer le code récurrent

La solution consiste à contrôler le démarrage du service worker en choisissant à quel moment appeler navigator.serviceWorker.register() Une simple règle de base serait de retarder les inscriptions avant le load event se déclenche sur window, comme ceci:

if ('serviceWorker' in navigator) {
    window.addEventListener('load', function() {
    navigator.serviceWorker.register('/service-worker.js');
    });
}

Mais le bon moment pour lancer l'enregistrement d'un service worker dépend aussi sur ce que fait votre application Web juste après son chargement. Par exemple, la conférence Google I/O application Web 2016 avec une courte animation avant de passer à l'écran principal. Notre équipe constaté que le fait de donner un coup de pied de l'enregistrement du service worker pendant l'animation peut entraîner des à-coups. sur les appareils mobiles bas de gamme. Plutôt que d'offrir une mauvaise expérience aux internautes, nous retardé d'enregistrement du service worker jusqu'à la fin de l'animation, à laquelle le navigateur était le plus sont susceptibles d'avoir quelques secondes d'inactivité.

De même, si votre application Web utilise un framework qui effectue une configuration supplémentaire après la page s'est chargée, recherchez un événement spécifique au framework le travail est terminé.

Visites suivantes

Jusqu'à présent, nous nous sommes concentrés sur la première visite, mais quel impact L'inscription des service workers tardivement est-elle associée à des visites répétées sur votre site ? Bien que cela puisse surprendre certaines personnes, cela ne devrait pas avoir d’impact du tout.

Lorsqu'un service worker est enregistré, il passe par l'install et activate cycle de vie événements. Une fois qu'un service worker est activé, il peut gérer les événements fetch pour tous les visites ultérieures de votre application Web. Le service worker démarre avant la pour toutes les pages concernées, ce qui est logique à ce sujet. Si le service worker existant n'était pas déjà en cours d'exécution visitant une page, il n'aurait pas la possibilité de traiter fetch événements pour les requêtes de navigation.

Une fois qu'un service worker est actif, vous pouvez appeler navigator.serviceWorker.register(), ou même que vous l'appeliez du tout. À moins que vous ne modifiiez l'URL du script du service worker, navigator.serviceWorker.register() est effectivement un no-op lors des visites suivantes. Quand appelée n'est pas pertinente.

Pourquoi s'inscrire à l'avance ?

Existe-t-il des scénarios dans lesquels vous pouvez enregistrer votre service worker dès le possible est logique ? Par exemple, quand votre service worker utilise clients.claim() de prendre le contrôle de la page lors de la première visite, et le service worker effectue des tests d'exécution agressifs mise en cache dans son gestionnaire fetch. Dans ce cas, il y a un d'activer le service worker le plus rapidement possible, afin d'essayer remplir ses caches d’exécution avec des ressources qui pourraient s’avérer utiles plus tard. Si votre application Web entre dans cette catégorie, il est utile de prendre du recul pour assurez-vous que le gestionnaire install de votre service worker ne demande pas qui luttent pour la bande passante avec les requêtes de la page principale.

Tester des éléments

Un excellent moyen de simuler une première visite consiste à ouvrir votre application Web dans un Navigation privée fenêtre, et examiner le trafic réseau dans Chrome DevTools. Comme un Web vous rechargez probablement une instance locale de votre application Web des dizaines et des dizaines de fois par jour. En retournant sur votre site, et des caches entièrement remplis, vous n'obtenez pas la même expérience qu'un nouvel utilisateur recevra, et il est facile d'ignorer un problème potentiel.

Voici un exemple illustrant la différence entre les dates d'inscription faire. Les deux captures d'écran sont prises lors de la consultation d'un échantillon application dans Mode navigation privée utilisant une limitation de bande passante réseau pour simuler une connexion lente

La capture d'écran ci-dessus montre le trafic réseau lors de la modification de l'échantillon. pour enregistrer un service worker dès que possible. Vous pouvez voir requêtes de mise en cache préalable (les entrées associées à l'icône icône à côté d'eux, en provenance du gestionnaire install du service worker) entre les demandes des autres ressources nécessaires à l'affichage de la page.

Dans la capture d'écran ci-dessus, l'enregistrement d'un service worker a été retardé jusqu'à la fin du était chargée. Vous pouvez constater que les requêtes de mise en cache préalable ne démarrent que lorsque les ressources ont été extraites du réseau, éliminant ainsi tout conflit pour la bande passante réseau. De plus, étant donné que certains des éléments que nous mettons en cache se trouvent déjà dans le cache HTTP du navigateur, c'est-à-dire les éléments dont la taille est (from disk cache) nous pouvons remplir le cache du service worker sans avoir à accéder à la réseau.

C'est encore mieux si vous effectuez ce type de test à partir d'un appareil d'entrée de gamme réel un vrai réseau mobile. Vous pouvez bénéficier du débogage à distance de Chrome fonctionnalités pour connecter un téléphone Android à votre ordinateur de bureau via USB, et assurez-vous que le les tests que vous exécutez reflètent en fait l'expérience réelle d'un grand nombre de vos utilisateurs.

Conclusion

En résumé, s'assurer que les utilisateurs bénéficient de la meilleure expérience de première visite possible doit être une priorité absolue. Retard de l'enregistrement du service worker jusqu'à la fin du s'est chargée lors de votre première visite. Vous bénéficierez quand même tous les avantages d'avoir un service worker pour vos visites répétées.

Un moyen simple de retarder l'exécution initiale de votre service worker l'inscription avant le chargement de la première page consiste à utiliser ce qui suit:

if ('serviceWorker' in navigator) {
    window.addEventListener('load', function() {
    navigator.serviceWorker.register('/service-worker.js');
    });
}