Progressive web apps sur des sites multi-origines

Défis et solutions pour créer des progressive web apps sur des sites multi-origines.

Demián Renzulli

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 précisément, le règlement d'origine identique impose des restrictions concernant le partage d'éléments tels que les service workers et les caches, les autorisations et la possibilité de proposer une expérience autonome sur plusieurs origines. Cet article décrit les bonnes et les mauvaises utilisations de plusieurs origines, et décrit les défis et les solutions de contournement liés à la création de progressive web apps sur des sites multi-origines.

Bons et mauvais usages de plusieurs origines

Il existe plusieurs raisons légitimes qui justifient que les sites utilisent une architecture multi-origine, principalement en raison de la fourniture d'un ensemble indépendant d'applications Web ou de la création d'expériences complètement isolées les unes des autres. Il y a également des utilisations à éviter.

Exemple correct

Examinons d'abord 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 ciblant différentes zones géographiques (par exemple, https://newyork.craigslist.org) ou proposer des contenus 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 d'origine. Par exemple, sur un site d'actualités, l'application Web "Mots croisés" peut être volontairement diffusée depuis https://crosswords.example.com, puis 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.

Le mauvais

Si vous n'effectuez aucune de ces actions, l'utilisation d'une architecture à origines multiples sera probablement un inconvénient lorsque vous créerez des progressive web apps.

Malgré cela, de nombreux sites continuent d'être structurés de cette façon sans raison particulière ou pour des raisons "anciennes". 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 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 rubrique sportive à https://sports.example.com, la politique à l'adresse https://politics.example.com, etc. Dans le cas d'un site d'e-commerce, nous utilisons par exemple https://category.example.com pour les catégories de produits, https://product.example.com pour les pages de produits, etc.

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

Remarque : Lorsque vous créez un site à partir de zéro, il est fortement recommandé d'éviter de le diviser en sous-domaines. Pour les sites existants, migrer vers une origine unique est la meilleure approche.

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 à envisager lors de la création de progressive web apps.

Défis et solutions de contournement pour les PWA de différentes origines

Lors de la création d'un site Web sur plusieurs origines, il est difficile de proposer une expérience PWA unifiée, principalement en raison des règles d'origine identique qui imposent un certain nombre de contraintes. Examinons-les l'une après l'autre.

Service workers

L'origine de l'URL de script du service worker doit être identique à celle de la page appelant la méthode register(). Cela signifie, par exemple, qu'une page associée à https://www.example.com ne peut pas appeler register() avec une URL de service worker située à l'adresse 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). En revanche, il ne contrôlera aucune page dans 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).

Attention : L'enregistrement et la mise en place de plusieurs service workers actifs consomment des ressources supplémentaires (mémoire, processeur, etc.). Par conséquent, faites preuve de bon sens quant au nombre de service workers actifs qu'un utilisateur devra probablement parcourir sur le site.

Mise en cache

L'objet Cache, l'objet "IndexedDB" et l'objet "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 des scénarios comme celui-ci:

• Exploiter la mise en cache du navigateur:il est toujours recommandé d'utiliser les bonnes pratiques de mise en cache du navigateur classique. Cette technique présente l'avantage supplémentaire de réutiliser les ressources mises en cache pour plusieurs 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.

• Simplifiez le processus d'installation des service workers:si vous gérez plusieurs service workers, évitez de faire payer aux utilisateurs des frais d'installation élevés chaque fois qu'ils accèdent à une nouvelle origine. En d'autres termes, ne mettez en pré-cache que les ressources qui sont absolument nécessaires.

Une fois que le service worker est actif et en cours d'exécution, la règle d'origine commune limite également les requêtes multi-origines effectuées à l'intérieur des service workers. Heureusement, il existe une solution de contournement recommandée, qui consiste à utiliser CORS (comme expliqué ici). Il est déconseillé d'utiliser le mode no-cors lors de l'extraction de ressources à l'intérieur du service worker.

Autorisations

Les autorisations sont également appliqué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 sur d'autres origines, telles que https://www.example.com.

Étant donné qu'il n'est pas possible de partager des autorisations entre différentes origines, la seule solution consiste à demander une autorisation pour chacun des sous-domaines nécessitant une fonctionnalité donnée (par exemple, l'emplacement). Pour des opérations telles que le transfert Web, 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 demander à nouveau.

Installation

Pour installer une PWA, chaque origine doit avoir 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 (https://section.example.com, par exemple) ne pourra pas installer la PWA avec une start_url sur une autre (par exemple, https://www.example.com). En d'autres termes, les utilisateurs recevant 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 répondant aux critères d'installation:

1. Écouter l'événement beforeinstallprompt.
2. Empêchez l'affichage de l'invite en appelant event.preventDefault().

Ainsi, vous vous assurez que l'invite ne s'affiche pas dans des parties non souhaitées du site, tout en continuant à l'afficher, par exemple dans l'origine principale (par exemple, la page d'accueil).

Mode autonome

Lorsque vous naviguez 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 du fournisseur. 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 vous pouvez appliquer une solution de contournement pour de 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 en plein écran.
2. Une fois la tâche terminée dans l'iFrame (par exemple, au cours du processus de connexion), vous pouvez utiliser postMessage() pour transmettre toute information résultant de l'iFrame vers la page parent.
3. Pour finir, une fois le message reçu par la page principale, vous pouvez annuler l'enregistrement des écouteurs et supprimer l'iFrame du DOM.

Attention : La technique précédente permet d'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). Toutefois, elle n'est pas efficace à implémenter pour des chemins 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 est recommandé d'éviter ce problème en validant toutes les origines à l'aide de Digital Asset Links.

Conclusion

La règle d'origine identique impose de nombreuses restrictions pour les sites basés sur plusieurs origines qui souhaitent offrir une expérience PWA cohérente. C'est pourquoi, afin d'offrir la meilleure expérience utilisateur possible, nous vous déconseillons fortement de diviser les sites en plusieurs origines.

Pour les sites existants qui sont déjà créés de cette manière, il peut être difficile de faire fonctionner correctement les PWA multi-origines, mais nous avons exploré des solutions potentielles. Chacune d'elles peut s'accompagner de compromis. Vous devez donc faire 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 origine unique, sauf si vous avez une raison importante de conserver l'architecture multi-origine.

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