Architecture

Pour concevoir votre application afin d'exploiter au mieux la technologie qui rend les PWA fiables, installables et performantes, il faut d'abord comprendre votre application et ses contraintes, puis choisir une architecture adaptée à ces deux aspects.

SPA et MPA

Aujourd'hui, il existe deux principaux modèles architecturaux dans le développement Web: les applications monopages (SPA) et les applications multipages (MPA).

Les applications monopages sont définies par le contrôle JavaScript côté client pour la plupart ou la totalité du rendu HTML d'une page, en fonction des données récupérées par ou fournies à l'application. L'application remplace la navigation intégrée du navigateur en la remplaçant par sa fonctionnalité de routage et de gestion des vues.

Dans les applications multipages, le code HTML préaffiché est généralement envoyé directement au navigateur. Il est souvent amélioré par du code JavaScript côté client une fois que le navigateur a terminé de charger le code HTML, et il s'appuie sur les mécanismes de navigation intégrés du navigateur pour afficher les vues suivantes.

Les deux architectures peuvent être utilisées pour créer des PWA.

Chacune de ces méthodes présente des avantages et des inconvénients, et il est essentiel de choisir celle qui convient le mieux à votre cas d'utilisation et à votre contexte pour offrir une expérience rapide et fiable à vos utilisateurs.

Applications monopages

Avantages
  • Mises à jour d'encarts pour la plupart atomiques.
  • Dépendances côté client chargées au démarrage.
  • Les chargements suivants sont rapides en raison de l'utilisation du cache.
Inconvénients
  • Coût de chargement initial élevé.
  • Les performances dépendent du matériel de l'appareil et de la connexion réseau.
  • Une application plus complexe est requise.

Les applications monopages sont parfaitement adaptées à l'architecture si:

  • Les interactions des utilisateurs s'articulent principalement autour de mises à jour atomiques de données interconnectées affichées sur la même page, par exemple dans un tableau de bord de données en temps réel ou une application de montage vidéo.
  • Votre application comporte des dépendances d'initialisation côté client uniquement (par exemple, un fournisseur d'authentification tiers dont les coûts de démarrage sont prohibitifs).
  • Les données nécessaires au chargement d'une vue dépendent d'un contexte spécifique côté client uniquement, par exemple, l'affichage des commandes d'un matériel connecté.
  • L'application est suffisamment petite et simple pour que sa taille et sa complexité n'aient pas d'impact sur les inconvénients listés ci-dessus.

Les applications monopages ne constituent pas un bon choix d'architecture dans les cas suivants:

  • Les performances de chargement initial sont essentielles. Les applications monopages doivent généralement charger plus de JavaScript pour déterminer ce qu'elles doivent charger et comment les afficher. Le temps d'analyse et d'exécution de ce code JavaScript, combiné à la récupération du contenu, est plus lent que l'envoi du code HTML affiché.
  • Votre application fonctionne principalement sur des appareils à faible puissance. Étant donné que les applications monopages dépendent de JavaScript pour le rendu, l'expérience utilisateur dépend beaucoup plus de la puissance de leur appareil spécifique que dans une MPA.

Étant donné que les applications monopages doivent remplacer la navigation intégrée du navigateur par leur itinéraire, elles exigent un niveau de complexité minimal pour mettre à jour efficacement la vue actuelle, gérer les modifications de navigation et nettoyer les vues précédentes qui seraient normalement gérées par le navigateur, ce qui les rend plus difficiles à gérer et plus lourdes à gérer sur l'appareil de l'utilisateur.

Applications multipages

Avantages
  • Principalement des mises à jour pleine page.
  • La vitesse d'affichage initiale est essentielle.
  • Les scripts côté client peuvent être améliorés.
Inconvénients
  • Les affichages secondaires nécessitent un autre appel au serveur.
  • Le contexte n'est pas conservé d'une vue à l'autre.
  • Nécessite un serveur ou le prérendu.

Les applications multipages constituent un bon choix d'architecture dans les cas suivants:

  • Les interactions des utilisateurs sont principalement axées sur les vues d'une seule donnée associée à des données contextuelles facultatives, comme une application d'actualités ou d'e-commerce.
  • La vitesse d'affichage initiale est essentielle, car il est plus rapide d'envoyer le code HTML déjà affiché au navigateur que de l'assembler à partir d'une requête de données après le chargement, l'analyse et l'exécution d'une alternative basée sur JavaScript.
  • L'interactivité ou le contexte côté client peuvent être inclus en tant qu'amélioration après le chargement initial, par exemple en superposant un profil sur une page affichée ou en ajoutant des composants secondaires dépendant du contexte côté client.

Les MPA ne constituent pas un bon choix d'architecture dans les cas suivants:

  • Le coût du téléchargement, de l'analyse à nouveau et de la réexécution de votre code JavaScript ou CSS est prohibitif. Cet inconvénient est atténué dans les PWA utilisant des service workers.
  • Le contexte côté client, comme la position de l'utilisateur, ne s'applique pas de façon transparente d'une vue à l'autre, et récupérer ce contexte peut s'avérer coûteux. Vous devez la capturer et la récupérer, ou effectuer une nouvelle demande entre les vues.

Les vues individuelles doivent être affichées dynamiquement par un serveur ou préaffichées avant l'accès, ce qui peut limiter l'hébergement ou accroître la complexité des données.

Laquelle choisir ?

Même avec ces avantages et ces inconvénients, les deux architectures sont valides pour créer votre PWA. Vous pouvez même les combiner pour différentes parties de votre application, en fonction de ses besoins. Par exemple, les fiches Play Store doivent suivre une architecture MPA et le processus de paiement doit suivre une architecture SPA.

Quel que soit le choix, l'étape suivante consiste à comprendre comment utiliser au mieux les service workers afin d'offrir la meilleure expérience possible.

La puissance des service worker

Le service worker possède une puissance bien supérieure au routage et à la distribution de base des réponses mises en cache et réseau. Nous pouvons créer des algorithmes complexes capables d'améliorer l'expérience utilisateur et les performances.

Service Workers inclus

Un modèle émergent d'utilisation des service workers en tant que partie intégrante de l'architecture d'un site est le service Worker includes (SWI). SWI divise les éléments individuels (généralement une page HTML) en plusieurs éléments en fonction de leurs besoins de mise en cache, puis les reconstitue dans le service worker pour améliorer la cohérence, les performances et la fiabilité, tout en réduisant la taille du cache. Un site web avec un en-tête global, une zone de contenu, une barre latérale et un pied de page.

Cette image est un exemple de page Web. Il comporte cinq sections différentes qui décomposent la page en:

  • La mise en page globale.
  • En-tête global (barre sombre supérieure).
  • Zone de contenu (lignes centrales à gauche et image).
  • Barre latérale (haute barre moyennement foncée au milieu à droite).
  • Pied de page (barre inférieure sombre)

Mise en page globale

La mise en page globale est peu susceptible de changer souvent et ne comporte aucune dépendance. Il s'agit d'un bon candidat pour la prémise en cache.

L'en-tête et le pied de page globaux contiennent des éléments tels que le menu supérieur et le pied de page du site. Ils présentent un défi particulier: si la page était mise en cache dans son ensemble, ces éléments peuvent changer entre les chargements de page, en fonction de la date de mise en cache de la page donnée.

En les séparant et en les mettant en cache indépendamment du contenu, vous vous assurez que les utilisateurs bénéficient toujours de la même version, quelle que soit la date de mise en cache. Comme ils ne sont pas souvent mis à jour, ils sont aussi adaptés à la prémise en cache. Ils ont toutefois une dépendance: le CSS et le JavaScript du site.

CSS et JavaScript

Idéalement, le code CSS et JavaScript du site doit être mis en cache avec une stratégie obsolète lors de la revalidation, afin d'autoriser les mises à jour incrémentielles sans mettre à jour le service worker, comme c'est le cas avec les éléments en pré-cache. Cependant, ils doivent également être maintenus au minimum chaque fois que le service worker met à jour l'en-tête ou le pied de page global. C'est pourquoi le cache doit également être mis à jour avec la dernière version des éléments lors de l'installation du service worker.

Zone de contenu

Vient ensuite la zone de contenu. En fonction de la fréquence des mises à jour, nous vous recommandons de choisir entre les mises à jour du réseau en premier ou les rendre obsolètes lors de la revalidation. Les images doivent être mises en cache avec une stratégie axée sur la mise en cache, comme expliqué précédemment.

Enfin, en supposant que le contenu de la barre latérale comporte du contenu secondaire tel que des tags et des éléments connexes, l'extraction depuis le réseau n'est pas suffisante. Pour ce faire, vous pouvez utiliser une stratégie obsolète de revalidation.

Après avoir suivi tout cela, vous pensez peut-être que vous ne pouvez effectuer ce type de mise en cache par section que pour les applications monopages. Toutefois, en adoptant des modèles inspirés des inclusions côté serveur ou des inclusions côté serveur dans votre service worker, avec certaines fonctionnalités de service worker avancées, vous pouvez le faire pour l'une ou l'autre des architectures.

Essayez par vous-même

Dans le prochain atelier de programmation, vous pouvez tester les inclusions de service worker:

Réponses en streaming

La page précédente peut être créée à l'aide du modèle de shell d'application dans le monde des applications monopages, où le shell de l'application est mis en cache, puis diffusé, et le contenu est chargé côté client. Avec l'introduction et la large disponibilité de l'API Streams, le shell d'application et le contenu peuvent être combinés dans le service worker et diffusés en streaming vers le navigateur. Vous bénéficiez ainsi de la flexibilité de mise en cache du shell d'application avec la vitesse des MPA.

Pour les raisons suivantes:

  • Les flux peuvent être créés de manière asynchrone, ce qui permet à différents éléments d'un flux de provenir d'autres sources.
  • Le demandeur d'un flux peut commencer à travailler sur la réponse dès que le premier bloc de données est disponible, au lieu d'attendre que l'intégralité de l'élément soit terminée.
  • Les analyseurs optimisés pour le streaming, y compris le navigateur, peuvent afficher progressivement le contenu du flux avant qu'il ne soit terminé, ce qui accélère la perception des performances de la réponse.

Grâce à ces trois propriétés des flux, les architectures basées sur les flux ont généralement de meilleures performances perçues que les autres.

L'utilisation de l'API Streams peut s'avérer difficile, car elle est complexe et de base. Heureusement, il existe un module Workbox qui peut vous aider à configurer des réponses par flux pour vos service workers.

Domaines, origines et champ d'application de la PWA

Les web workers, y compris les service workers, l'espace de stockage et même la fenêtre d'une PWA installée, sont tous régis par l'un des mécanismes de sécurité les plus critiques sur le Web: la règle d'origine identique. Au sein de la même origine, les autorisations sont accordées, les données peuvent être partagées et le service worker peut communiquer avec différents clients. En dehors de la même origine, les autorisations ne sont pas accordées automatiquement, et les données sont isolées et inaccessibles entre différentes origines.

Règles d'origine identique

Deux URL ont l'origine exacte lorsque le protocole, le port et l'hôte sont identiques.

Par exemple, https://squoosh.app et https://squoosh.app/v2 ont la même origine, mais http://squoosh.app, https://squoosh.com, https://app.squoosh.app et https://squoosh.app:8080 ont des origines différentes. Pour en savoir plus et obtenir des exemples, consultez la documentation de référence MDN sur la règle d'origine commune.

Changer de sous-domaine n'est pas le seul moyen de modifier un hôte. Chaque hôte est composé d'un domaine de premier niveau (TLD), d'un domaine de niveau secondaire (SLD) et de zéro ou plusieurs libellés (parfois appelés sous-domaines), séparés par des points entre les deux et se lisant de droite à gauche dans une URL. La modification d'un élément entraîne l'affectation d'un hôte différent.

Dans le module de gestion des fenêtres, nous avons déjà vu à quoi ressemble le navigateur intégré à l'application lorsqu'un utilisateur accède à une autre origine depuis une PWA installée.

Ce navigateur intégré à l'application apparaîtra même si les sites Web ont le même TLD et le même SLD, mais avec des libellés différents, car ils sont alors considérés comme des origines différentes.

L'un des aspects clés d'une origine dans un contexte de navigation Web est le fonctionnement du stockage et des autorisations. Une origine partage de nombreuses caractéristiques entre tous ses contenus et les PWA qu'elle contient, y compris les suivantes:

  • Quota de stockage et données (IndexedDB, cookies, stockage Web, stockage en cache).
  • Enregistrement des service workers.
  • Autorisations accordées ou refusées (par exemple, Web Push, géolocalisation, capteurs).
  • Enregistrements push Web

Lorsque vous passez d'une origine à une autre, tous les accès précédents sont révoqués. Vous devez donc accorder à nouveau les autorisations, et votre PWA ne peut pas accéder à toutes les données enregistrées dans l'espace de stockage.

Ressources