Défis et solutions de contournement pour créer des Progressive Web Apps dans des sites multi-origines.
Publié le 19 août 2019
Auparavant, l'utilisation d'architectures multi-origines présentait certains avantages. Cette approche présente de nombreux défis pour les progressive web apps. 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 l'obtention d'une expérience autonome sur plusieurs origines.
Découvrez les bons et les mauvais usages des origines multiples, et expliquez les défis et les solutions pour créer des applications Web progressives sur des sites multi-origines.
Utilisation appropriée et inappropriée de plusieurs origines
Il existe plusieurs raisons légitimes pour lesquelles les sites peuvent utiliser une architecture multi-origines. La plupart d'entre elles sont liées à la fourniture d'un ensemble indépendant d'applications Web ou à la création d'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 un code pays pour séparer les sites à diffuser dans différents pays (par exemple,
https://www.google.com.ar) ou utilisez 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).Applications Web indépendantes : utilisation de différents sous-domaines pour proposer des expériences dont l'objectif diffère considérablement de celui du site sur l'origine principale. Par exemple, sur un site d'actualités, l'application Web de mots croisés peut être intentionnellement diffusée à partir de
https://crosswords.example.com, et installée et utilisée comme une PWA indépendante, sans avoir à partager de ressources ni de fonctionnalités avec le site Web principal.
Le mauvais
Si vous n'effectuez aucune de ces actions, il est probable que l'utilisation d'une architecture multi-origines soit un inconvénient lors de la création 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 "anciennes". Par exemple, vous pouvez utiliser des sous-domaines pour séparer arbitrairement des parties d'un site qui devraient faire partie d'une expérience unifiée.
Par exemple, les schémas suivants sont fortement déconseillés :
Sections du site : séparez 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, la section "Sports" à l'adressehttps://sports.example.com, la section "Politique" à l'adressehttps://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.Flux utilisateur : une autre approche à éviter consiste à séparer différentes petites parties du site, comme les pages de connexion ou de paiement, dans des sous-domaines. Par exemple, en utilisant
https://login.example.comethttps://checkout.example.com.
Dans les cas où la migration vers une origine unique n'est pas possible, vous trouverez ci-dessous une liste de 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 pour les PWA sur différentes origines
Lorsque vous créez un site Web sur plusieurs origines, il est difficile de fournir 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 un par un.
Service workers
L'origine de l'URL du script du service worker doit être la même que celle de la page appelant register(). Cela signifie, par exemple, qu'une page à l'adresse https://www.example.com ne peut pas appeler register() avec une URL de service worker à l'adresse 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 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 pas les pages d'autres sous-domaines, comme celles de https://section.example.com.
Dans ce cas, la seule solution de contournement 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 n'est pas possible 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'utiliser 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 sur plusieurs 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.
Veillez à ce que l'installation du service worker soit légère : si vous gérez plusieurs service workers, évitez d'imposer aux utilisateurs un coût d'installation élevé chaque fois qu'ils accèdent à une nouvelle origine. En d'autres termes, ne prémettez 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 reportée à d'autres origines, comme https://www.example.com.
Comme 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 localisation). Pour les notifications Web push, par exemple, vous pouvez conserver un cookie pour savoir si l'autorisation a été acceptée par l'utilisateur dans un autre sous-domaine, afin d'éviter de la redemander.
Installation
Pour installer une PWA, chaque origine doit avoir son propre fichier manifeste avec un start_url relatif à lui-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).
En d'autres termes, les utilisateurs qui reçoivent l'invite d'installation dans un sous-domaine ne pourront installer les PWA que pour les sous-pages, et non pour l'URL principale de l'application.
Un même utilisateur peut également 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 résoudre 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 de s'afficher en appelant
event.preventDefault().
Vous vous assurez ainsi que l'invite ne s'affiche pas dans des parties non prévues du site, tout en pouvant continuer à l'afficher, par exemple, dans l'origine principale (par exemple, la page d'accueil).
Mode autonome
Lorsqu'il navigue 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 et fournisseur de navigateur. Par exemple, les dernières versions de Chrome ouvrent un onglet Chrome personnalisé lorsqu'un utilisateur quitte le champ d'application en mode autonome.
Dans la plupart des cas, il n'existe pas de solution à ce problème. Toutefois, une solution de contournement peut être appliquée aux 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), postMessage() peut être utilisé pour renvoyer les informations résultantes de l'iFrame à la page parente.
- Enfin, une fois le message reçu par la page principale, les écouteurs peuvent être désenregistrés et l'iframe peut être supprimé du DOM.
Conclusion
La règle d'origine identique impose de nombreuses restrictions aux sites reposant sur plusieurs origines et qui souhaitent offrir une expérience PWA cohérente. Pour cette raison, afin d'offrir la meilleure expérience possible aux utilisateurs, nous vous déconseillons vivement de diviser les sites en différentes origines.
Pour les sites existants déjà conçus de cette manière, il peut être difficile de faire fonctionner correctement les PWA multi-origines, mais nous avons exploré quelques solutions de contournement potentielles. Chacune de ces méthodes présente des avantages et des inconvénients. Il vous incombe donc de déterminer celle qui convient le mieux à 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-origines.
Merci beaucoup à Penny Mclachlan, Paul Covell, Dominick Ng, Alberto Medina, Pete LePage, Joe Medley, Cheney Tsai, Martin Schierle et Andre Bandarra pour leurs suggestions et leurs avis techniques.