Défis et solutions de contournement pour créer des Progressive Web Apps sur des sites multi-origines.
Contexte
Par le passé, l'utilisation d'architectures multi-origines présentait certains avantages, mais pour les applications Web progressives, cette approche présente de nombreux défis. En particulier, le Règlement d'origine identique impose des restrictions pour le partage d'éléments tels que les service workers et les caches, les autorisations, et pour obtenir une expérience autonome sur plusieurs origines. Cet article décrit les bons et mauvais usages des origines multiples, et explique les défis et les solutions de contournement pour créer des applications Web progressives sur des sites multi-origines.
Bonnes et mauvaises utilisations des origines multiples
Les sites peuvent avoir plusieurs raisons légitimes d'utiliser une architecture multi-origine, principalement pour fournir un ensemble indépendant d'applications Web ou pour créer des expériences complètement isolées les unes des autres. Il existe également des utilisations à éviter.
Exemple correct
Commençons par les raisons utiles:
Localisation / Langue:utilisez un domaine de premier niveau avec code pays pour séparer les sites à diffuser dans différents pays (par exemple,
https://www.google.com.ar), ou des sous-domaines pour diviser les sites ciblant différentes zones géographiques (par exemple :https://newyork.craigslist.org) ou pour proposer du contenu dans une langue spécifique (par exemple,https://en.wikipedia.org).Webapps indépendantes:utilisation de sous-domaines différents pour proposer des expériences dont l'objectif diffère considérablement de celui du site de l'origine principale. Par exemple, sur un site d'actualités, la webapp de mots croisés peut être diffusée intentionnellement à partir de
https://crosswords.example.com, et installée et utilisée en tant que PWA indépendante, sans avoir à partager aucune ressource ni fonctionnalité avec le site Web principal.
Les points négatifs
Si vous ne faites rien de tout cela, il est probable que l'utilisation d'une architecture multi-origine soit un inconvénient lors du développement de progressive web apps.
Malgré cela, de nombreux sites continuent d'être structurés de cette manière sans raison particulière ou pour des raisons "historiques". Par exemple, vous utilisez des sous-domaines pour séparer arbitrairement des parties d'un site qui devraient faire partie d'une expérience unifiée.
Par exemple, nous vous déconseillons vivement d'utiliser les modèles suivants:
Sections de site:permet de séparer les différentes sections d'un site sur des sous-domaines. Sur les sites d'actualités, il n'est pas rare de voir la page d'accueil à l'adresse
https://www.example.com, tandis que la section "Sport" se trouve àhttps://sports.example.com, la section "Politique" àhttps://politics.example.com, etc. Dans le cas d'un site d'e-commerce, utilisez par exemplehttps://category.example.compour les catégories de produits,https://product.example.compour les pages de produits, etc.Parcours utilisateur:une autre approche déconseillée consiste à séparer différentes parties plus petites du site, comme les pages des flux de connexion ou d'achat dans des sous-domaines. Par exemple, à l'aide de
https://login.example.comethttps://checkout.example.com.
Dans les cas où la migration vers une seule origine n'est pas possible, vous trouverez ci-dessous une liste des défis et (dans la mesure du possible) des solutions de contournement à envisager lors de la création de Progressive Web Apps.
Défis et solutions de contournement pour les PWA sur différentes origines
Lorsque vous créez un site Web sur plusieurs origines, il est difficile de proposer une expérience PWA unifiée, principalement en raison de la règle de même origine, qui impose un certain nombre de contraintes. Examinons-les une par une.
Service workers
L'origine de l'URL du script du service worker doit être identique à celle de la page qui appelle register(). Par exemple, une page située sur https://www.example.com ne peut pas appeler register() avec une URL de service worker sur https://section.example.com.
Un autre point à prendre en compte est qu'un service worker ne peut contrôler que les pages hébergées sous l'origine et le chemin d'accès auxquels il appartient. Cela signifie que si le service worker est hébergé sur https://www.example.com, il ne peut contrôler que les URL de cette origine (selon le chemin défini dans le paramètre de portée), mais ne contrôle aucune page dans d'autres sous-domaines, comme ceux de https://section.example.com, par exemple.
Dans ce cas, la seule solution consiste à utiliser plusieurs service workers (un par origine).
Mise en cache
L'objet Cache, IndexedDB et localStorage sont également limités à une seule origine. Cela signifie qu'il est impossible d'accéder aux caches appartenant à https://www.example.com, par exemple à partir de https://www.section.example.com.
Voici quelques conseils pour gérer correctement les caches dans ce type de scénario:
Exploitez la mise en cache du navigateur:il est toujours recommandé d'appliquer les bonnes pratiques traditionnelles de mise en cache du navigateur. Cette technique présente l'avantage supplémentaire de réutiliser les ressources mises en cache entre les origines, ce qui n'est pas possible avec le cache du service worker. Pour découvrir les bonnes pratiques d'utilisation du cache HTTP avec les service workers, consultez cet article.
Réduisez l'installation des service workers:si vous gérez plusieurs service workers, évitez de faire payer aux utilisateurs un coût d'installation élevé chaque fois qu'ils accèdent à une nouvelle origine. En d'autres termes, ne pré-misez en cache que les ressources absolument nécessaires.
Autorisations
Les autorisations sont également limitées aux origines. Cela signifie que si un utilisateur a accordé une autorisation donnée à l'origine https://section.example.com, elle ne sera pas transférée vers d'autres origines, comme https://www.example.com.
Étant donné qu'il n'est pas possible de partager des autorisations entre les origines, la seule solution consiste à demander l'autorisation sur chaque sous-domaine où une fonctionnalité donnée est requise (par exemple, la position). Pour les notifications Web push, vous pouvez conserver un cookie afin de savoir si l'autorisation a été acceptée par l'utilisateur dans un autre sous-domaine, afin de ne pas la redemander.
Installation
Pour installer une PWA, chaque origine doit disposer de son propre fichier manifeste avec un start_url par rapport à elle-même. Cela signifie qu'un utilisateur qui reçoit l'invite d'installation sur une origine donnée (par exemple, https://section.example.com) ne pourra pas installer la PWA avec un start_url sur une autre origine (par exemple, https://www.example.com). Autrement dit, les utilisateurs qui reçoivent l'invite d'installation dans un sous-domaine ne pourront installer des PWA que pour les sous-pages, et non pour l'URL principale de l'application.
Il existe également un problème : un même utilisateur peut recevoir plusieurs invites d'installation lorsqu'il navigue sur le site, si chaque sous-domaine répond aux critères d'installation et invite l'utilisateur à installer la PWA.
Pour atténuer ce problème, vous pouvez vous assurer que l'invite ne s'affiche que sur l'origine principale. Lorsqu'un utilisateur accède à un sous-domaine qui répond aux critères d'installation:
- Écoutez l'événement
beforeinstallprompt. - Empêchez l'invite d'apparaître en appelant
event.preventDefault().
Vous vous assurez ainsi que l'invite ne s'affiche pas dans des parties non souhaitées du site, tout en pouvant continuer à l'afficher, par exemple, dans l'origine principale (page d'accueil, par exemple).
Mode autonome
Lorsque vous naviguez dans une fenêtre autonome, le navigateur se comporte différemment lorsque l'utilisateur sort du champ d'application défini par le fichier manifeste de la PWA. Le comportement dépend de chaque version de navigateur et de chaque fournisseur. Par exemple, les dernières versions de Chrome ouvrent un onglet Chrome personnalisé lorsqu'un utilisateur sort du champ d'application en mode autonome.
Dans la plupart des cas, il n'existe pas de solution à ce problème, mais une solution de contournement peut être appliquée pour les petites parties de l'expérience hébergées dans des sous-domaines (par exemple, les workflows de connexion) :
- La nouvelle URL,
https://login.example.com, peut s'ouvrir dans un iFrame en plein écran. - Une fois la tâche terminée dans l'iFrame (par exemple, le processus de connexion), vous pouvez utiliser postMessage() pour transmettre les informations issues de l'iFrame à la page parente.
- Enfin, une fois le message reçu par la page principale, les écouteurs peuvent être désinscrits et l'iframe peut être supprimée du DOM.
Conclusion
La règle de même origine impose de nombreuses restrictions aux sites basés sur plusieurs origines qui souhaitent proposer une expérience PWA cohérente. C'est pourquoi, pour offrir une expérience optimale aux utilisateurs, nous vous déconseillons vivement de diviser les sites en différentes origines.
Pour les sites existants déjà créés de cette manière, il peut être difficile de faire fonctionner correctement les PWA multi-origines. Nous avons toutefois exploré quelques solutions de contournement potentielles. Chacune de ces méthodes peut présenter des avantages et des inconvénients. Utilisez votre bon sens pour choisir l'approche à adopter sur votre site Web.
Lorsque vous évaluez une stratégie à long terme ou une refonte de site, envisagez de migrer vers une seule origine, sauf si vous avez une raison importante de conserver l'architecture multi-origine.
Nous remercions Penny McLachlan, Paul Covell, Dominick Ng, Alberto Medina, Pete LePage, Joe Medley, Cheney Tsai, Martin Schierle et Andre Bandarra pour leurs avis et suggestions techniques.