Défis et solutions pour créer des progressive web apps sur des sites multi-origines
Contexte
Auparavant, l'utilisation d'architectures multi-origines présentait certains avantages, mais pour les progressive web apps, cette approche présente de nombreux défis. Plus spécifiquement, les règles de même origine imposent des restrictions pour le partage d'éléments tels que les service workers et les caches, les autorisations et la fourniture d'une expérience autonome sur plusieurs origines. Cet article décrit les bonnes et mauvaises utilisations de différentes origines, et explique les défis et les solutions de contournement liés au développement de progressive web apps sur des sites multi-origines.
Utilisations à bon ou mauvais des origines multiples
Il existe plusieurs raisons légitimes qui peuvent inciter les sites à utiliser une architecture multi-origine. Il s'agit principalement de fournir un ensemble indépendant d'applications Web ou de créer des expériences complètement isolées les unes des autres. Certains usages doivent également être évités.
Exemple correct
Commençons par examiner les raisons utiles:
Localisation / Langue : utilisation d'un domaine de premier niveau correspondant à un code pays pour séparer les sites devant être diffusés dans différents pays (par exemple,
https://www.google.com.ar) ou utiliser des sous-domaines pour répartir les sites ciblés sur différentes zones géographiques (par exemple,https://newyork.craigslist.org) ou proposer du contenu dans une langue spécifique (par exemple,https://en.wikipedia.org).Applications Web indépendantes:utiliser différents sous-domaines pour proposer des expériences dont l'objectif diffère considérablement de celui du site d'origine. Par exemple, dans un site d'actualités, l'application Web de mots croisés peut être intentionnellement diffusée à partir de
https://crosswords.example.com, puis installée et utilisée en tant que PWA indépendante, sans avoir à partager des ressources ou des fonctionnalités avec le site Web principal.
Mauvaise
Si vous n'entreprenez aucune de ces opérations, l'utilisation d'une architecture multi-origines ne sera probablement pas optimale pour la création de progressive web apps.
Malgré cela, de nombreux sites continuent d'être structurés ainsi sans raison particulière ou pour des raisons "d'héritage". Par exemple, vous pouvez utiliser des sous-domaines pour séparer arbitrairement les parties d'un site qui devraient faire partie d'une expérience unifiée.
Les modèles suivants, par exemple, sont fortement déconseillés:
Sections de site:séparation de différentes sections d'un site au sein de 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 "Sports" se trouve àhttps://sports.example.com, "Politique" àhttps://politics.example.com, etc. Dans le cas d'un site d'e-commerce, utilisez une valeur commehttps://category.example.compour les catégories de produits,https://product.example.compour les pages de produits, etc.Parcours utilisateur:nous vous déconseillons également de séparer différentes parties plus petites du site, comme les pages de connexion ou d'achat dans les sous-domaines. Par exemple, vous pouvez utiliser
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 problèmes et, si possible, des solutions de contournement à prendre en compte lors du développement de progressive web apps.
Défis et solutions pour les PWA de différentes origines
Lorsque vous créez un site Web sur plusieurs origines, il est difficile d'offrir une expérience PWA unifiée, principalement en raison des règles d'origine commune, qui imposent un certain nombre de contraintes. Examinons-les une par une.
Service workers
L'origine de l'URL de script du service worker doit être identique à celle de la page qui appelle register(). Cela signifie, par exemple, qu'une page de https://www.example.com ne peut pas appeler register() avec une URL de service worker à l'adresse https://section.example.com.
Autre point important à prendre en compte : un service worker ne peut contrôler que les pages hébergées sous l'origine et sous le chemin d'accès auquel elle 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 champ d'application), mais ne contrôle aucune page d'autres sous-domaines tels que ceux de https://section.example.com.
Dans ce cas, la seule solution consiste à utiliser plusieurs service workers (un par origine).
Mise en cache
L'objet Cache, indexéDB 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 depuis https://www.section.example.com.
Voici quelques conseils pour gérer correctement les caches dans des scénarios comme ceux-ci:
Exploitez la mise en cache dans le navigateur:nous vous recommandons de toujours suivre les bonnes pratiques traditionnelles de mise en cache dans le navigateur. Cette technique présente l'avantage de réutiliser les ressources mises en cache sur différentes origines, ce qui ne peut pas être fait avec le cache du service worker. Pour connaître les bonnes pratiques d'utilisation du cache HTTP avec les service workers, consultez cet article.
Allégez l'installation des service workers:si vous gérez plusieurs service workers, évitez de faire payer des frais d'installation élevés aux utilisateurs chaque fois qu'ils accèdent à une nouvelle origine. En d'autres termes, mettez uniquement en pré-cache 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, celle-ci 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 plusieurs origines, la seule solution consiste ici à demander une autorisation sur chaque sous-domaine pour lequel une fonctionnalité donnée est requise (par exemple, l'emplacement). Pour les applications Web push, par exemple, vous pouvez conserver un cookie pour savoir si l'utilisateur a accepté l'autorisation dans un autre sous-domaine, afin d'éviter de la demander à nouveau.
Installation
Pour installer une PWA, chaque origine doit avoir son propre fichier manifeste avec une start_url relative à elle-même. Cela signifie qu'un utilisateur qui reçoit l'invite d'installation pour une origine donnée (https://section.example.com) ne pourra pas installer la PWA avec une start_url sur une autre (c'est-à-dire https://www.example.com).
En d'autres termes, 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.
Par ailleurs, 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 l'invite à 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 visite un sous-domaine qui répond aux critères d'installation:
- Écouter l'événement
beforeinstallprompt - Empêcher l'affichage de l'invite en appelant
event.preventDefault().
De cette façon, vous vous assurez que l'invite ne s'affiche pas à des endroits non souhaités du site, tout en continuant à l'afficher, par exemple dans l'origine principale (par exemple, la page d'accueil).
Mode autonome
Dans une fenêtre autonome, le navigateur se comporte différemment lorsque l'utilisateur quitte le champ d'application défini par le fichier manifeste de la PWA. Le comportement dépend de la version du navigateur et de son fournisseur. Par exemple, lorsqu'un utilisateur sort du champ d'application en mode autonome, les dernières versions de Chrome ouvrent un onglet personnalisé Chrome.
Dans la plupart des cas, il n'existe pas de solution à ce problème, mais une solution de contournement peut être appliquée à de petites parties de l'expérience hébergées sur des sous-domaines (par exemple, les workflows de connexion) :
- La nouvelle URL,
https://login.example.com, pourrait s'ouvrir dans un iFrame en plein écran. - Une fois l'opération terminée dans l'iFrame (le processus de connexion, par exemple), vous pouvez utiliser la fonction postMessage() pour transmettre toutes les informations issues de l'iFrame à la page parente.
- Pour finir, une fois le message reçu par la page principale, vous pouvez annuler l'enregistrement des écouteurs, puis supprimer l'iFrame du DOM.
Conclusion
Les règles concernant les origines communes imposent de nombreuses restrictions aux sites créés à partir de plusieurs origines, qui souhaitent proposer une expérience de PWA cohérente. C'est pourquoi, pour offrir une expérience optimale aux utilisateurs, nous vous recommandons vivement de ne pas diviser les sites en différentes origines.
Pour les sites existants déjà conçus de cette manière, il peut s'avérer difficile de faire fonctionner correctement les PWA multi-origines. Toutefois, nous avons exploré des solutions de contournement potentielles. Chacune de ces méthodes peut s'accompagner de compromis, alors faites preuve de discernement lorsque vous décidez de l'approche à adopter pour votre site Web.
Lorsque vous évaluez une stratégie à long terme ou la refonte de votre site, envisagez de migrer vers une seule origine, sauf s'il existe une raison importante de conserver l'architecture multi-origine.
Nous vous remercions de leurs commentaires techniques et de leurs suggestions: Penny Mclachlan, Paul Covell, Dominick Ng, Alberto Medina, Pete LePage, Joe Medley, Cheney Tsai, Martin Schierle et Andre Bandarra.