Progressive web apps sur des sites multi-origines

Difficultés et solutions pour créer des Progressive Web Apps sur des sites multi-origines.

Demián Renzulli

Publié le 19 août 2019

Auparavant, l'utilisation d'architectures multi-origines présentait certains avantages. Pour les progressive web apps, cette approche présente de nombreux défis. En particulier, la règle 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.

Découvrez les bonnes et les mauvaises utilisations de plusieurs origines, et découvrez les défis et les solutions de contournement pour créer des progressive web apps sur des sites multi-origines.

Bonnes et mauvaises utilisations de plusieurs origines

Il existe quelques raisons légitimes pour lesquelles les sites utilisent une architecture multi-origine, principalement 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

Voici d'abord les raisons utiles :

• Localisation/Langue : utiliser un domaine national de premier niveau pour séparer les sites à diffuser dans différents pays (par exemple, https://www.google.com.ar) ou utiliser des sous-domaines pour diviser les sites ciblant différentes zones géographiques (par exemple : https://newyork.craigslist.org) ou de 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 en tant que PWA indépendante, sans avoir à partager de ressources ni de fonctionnalités avec le site Web principal.

Les inconvénients

Si vous ne faites rien de tout cela, l'utilisation d'une architecture multi-origine sera probablement 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 d'héritage. Par exemple, l'utilisation de sous-domaines pour séparer arbitrairement des parties d'un site qui devraient faire partie d'une expérience unifiée.

Par exemple, les modèles suivants sont fortement déconseillés :

• Sections du site : 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 "Sports" se trouve à l'adresse https://sports.example.com, la section "Politique" à l'adresse https://politics.example.com, etc. Dans le cas d'un site d'e-commerce, vous pouvez utiliser https://category.example.com pour les catégories de produits, https://product.example.com pour les pages produit, etc.

• Parcours utilisateur : une autre approche déconseillée consiste à séparer différentes petites parties du site, comme les pages de connexion ou de parcours d'achat, dans des sous-domaines. Par exemple, à l'aide de https://login.example.com et https://checkout.example.com.

Remarque  : Lorsque vous créez un site de toutes pièces, nous vous recommandons vivement d'éviter de le diviser en sous-domaines. Pour les sites existants, la migration vers une origine unique est la meilleure approche.

Pour les cas où la migration vers une origine unique n'est pas possible, vous trouverez ci-dessous une liste des difficultés et, dans la mesure du possible, des solutions de contournement à envisager lors de la création de progressive web apps.

Difficultés et solutions 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 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 sur https://www.example.com ne peut pas appeler register() avec une URL de service worker sur https://section.example.com.

Autre point à prendre en compte : 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 champ d'application), mais ne contrôlera aucune page d'autres sous-domaines, comme ceux de https://section.example.com.

Dans ce cas, la seule solution consiste à utiliser plusieurs service workers (un par origine).

Attention  : L'enregistrement et l'utilisation de plusieurs service workers actifs consomment des ressources supplémentaires (mémoire, processeur, etc.). Par conséquent, déterminez avec soin le nombre de service workers actifs dont un utilisateur aura probablement besoin pour naviguer sur le site.

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 : nous vous recommandons toujours d'utiliser les bonnes pratiques traditionnelles de mise en cache du navigateur. Cette technique offre 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 connaître les bonnes pratiques d'utilisation du cache HTTP avec les service workers, consultez cet article.

• Limitez la taille de l'installation du service worker : 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 mettez en cache que les ressources absolument nécessaires.

Une fois que le service worker est actif et en cours d'exécution, la règle de même origine limite également les requêtes interorigines effectuées dans les service workers. Heureusement, il existe une solution de contournement recommandée, qui consiste à utiliser CORS (comme expliqué ici). Nous vous déconseillons d'utiliser le mode no-cors lors de la récupération de ressources dans le service worker.

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.

Comme il n'est pas possible de partager des autorisations entre différentes 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 éléments tels que les notifications push Web, 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 un start_url relatif à 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). 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.

De plus, 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 :

1. Écoutez l'événement beforeinstallprompt.
2. 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 dans des parties non prévues du site, tout en continuant à l'afficher, par exemple, dans l'origine principale (par exemple, la page d'accueil).

Mode autonome

Lors de la navigation 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 la version et du fournisseur de chaque navigateur. Par exemple, les dernières versions de Chrome ouvrent un onglet personnalisé Chrome 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, 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) :

1. La nouvelle URL, https://login.example.com, pourrait s'ouvrir dans un iFrame plein écran.
2. Une fois la tâche terminée dans l'iFrame (par exemple, le processus de connexion), vous pouvez utiliser postMessage() pour transmettre les informations obtenues de l'iFrame à la page parente.
3. Enfin, une fois que la page principale a reçu le message, les écouteurs peuvent être désenregistrés et l'iFrame peut être supprimé du DOM.

Attention  : La technique précédente peut aider à atténuer les modifications potentielles de l'interface utilisateur dans une petite partie du site, où l'utilisateur peut effectuer une action dans un sous-domaine et revenir à l'origine principale (comme dans un flux de connexion), mais elle ne sera pas efficace pour des chemins d'accès entiers, y compris de nombreuses pages hébergées dans des sous-domaines (comme des sections entières du site).

Remarque  : Dans le contexte des activités Web de confiance, il existe une méthode recommandée pour éviter ce problème, qui consiste à valider toutes les origines à l'aide de Digital Asset Links.

Conclusion

La règle d'origine identique impose de nombreuses restrictions aux sites créés sur plusieurs origines qui souhaitent offrir une expérience de PWA cohérente. C'est pourquoi, pour 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 qui sont 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 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 origine unique, sauf si vous avez une raison importante de conserver l'architecture multi-origine.

Nous remercions chaleureusement Penny Mclachlan, Paul Covell, Dominick Ng, Alberto Medina, Pete LePage, Joe Medley, Cheney Tsai, Martin Schierle et Andre Bandarra pour leurs examens techniques et leurs suggestions.