Herausforderungen und Problemumgehungen beim Erstellen progressiver Web-Apps auf Websites mit mehreren Ursprüngen
Hintergrund
In der Vergangenheit gab es einige Vorteile bei der Verwendung von Architekturen mit mehreren Ursprüngen, aber für progressive Web-Apps stellt dieser Ansatz viele Herausforderungen dar. Insbesondere die Richtlinie für denselben Ursprung schränkt die Freigabe von Elementen wie Service Workers und Caches, Berechtigungen und die Bereitstellung einer eigenständigen Umgebung über mehrere Ursprünge ein. In diesem Artikel werden die Vor- und Nachteile mehrerer Ursprünge beschrieben. Außerdem werden die Herausforderungen und Problemumgehungen beim Erstellen progressiver Webanwendungen auf Websites mit mehreren Ursprüngen erläutert.
Gute und schlechte Verwendung mehrerer Quellen
Es gibt einige legitime Gründe, warum Websites eine Architektur mit mehreren Ursprüngen verwenden. Diese haben meist mit der Bereitstellung unabhängiger Webanwendungen oder der Erstellung von Umgebungen zu tun, die völlig voneinander getrennt sind. Es gibt aber auch Verwendungen, die vermieden werden sollten.
Gut gelöste Punkte
Sehen wir uns zuerst die nützlichen Gründe an:
Lokalisierung / Sprache:Mit einer Top-Level-Domain mit Ländercode können Sie Websites, die in verschiedenen Ländern ausgeliefert werden sollen, voneinander trennen (z. B.
https://www.google.com.ar). Mithilfe von Subdomains können Sie Websites, die auf verschiedene Standorte ausgerichtet sind, voneinander trennen (z. B.:https://newyork.craigslist.org) oder Inhalte in einer bestimmten Sprache anbieten (z.B.https://en.wikipedia.org).Unabhängige Webanwendungen: Es werden verschiedene Subdomains verwendet, um Inhalte bereitzustellen, deren Zweck sich deutlich von der Website des Hauptursprungs unterscheidet. Auf einer Nachrichtenwebsite kann die Web-App für Kreuzworträtsel beispielsweise absichtlich über
https://crosswords.example.combereitgestellt und als unabhängige PWA installiert und verwendet werden, ohne dass Ressourcen oder Funktionen mit der Hauptwebsite geteilt werden müssen.
Das Schlechte
Wenn Sie keines dieser Dinge tun, ist die Verwendung einer Architektur mit mehreren Ursprüngen beim Erstellen progressiver Web-Apps wahrscheinlich ein Nachteil.
Trotzdem werden viele Websites ohne triftigen Grund oder aus „Altlasten“ weiterhin so strukturiert. Ein Beispiel ist die Verwendung von Subdomains, um Teile einer Website willkürlich zu trennen, die Teil einer einheitlichen Website sein sollten.
Die folgenden Muster sind beispielsweise nicht empfehlenswert:
Websitebereiche:Verschiedene Bereiche einer Website werden auf Subdomains getrennt. Bei Nachrichtenwebsites ist es nicht ungewöhnlich, dass die Startseite unter
https://www.example.comzu finden ist, der Sportbereich unterhttps://sports.example.com, der Politikbereich unterhttps://politics.example.comusw. Bei einer E-Commerce-Website können Sie beispielsweisehttps://category.example.comfür Produktkategorien undhttps://product.example.comfür Produktseiten verwenden.Nutzerfluss: Es wird auch nicht empfohlen, verschiedene kleinere Bereiche der Website wie Seiten für den Anmelde- oder Kaufvorgang in Subdomains zu trennen. Beispiel:
https://login.example.comundhttps://checkout.example.com.
Wenn die Migration zu einem einzigen Ursprung nicht möglich ist, finden Sie nachstehend eine Liste mit Herausforderungen und (sofern möglich) Problemumgehungen, die beim Erstellen progressiver Web-Apps in Betracht gezogen werden können.
Herausforderungen und Lösungen für PWAs mit unterschiedlichen Ursprüngen
Wenn Sie eine Website mit mehreren Ursprüngen erstellen, ist es schwierig, eine einheitliche PWA bereitzustellen. Das liegt vor allem an der Same-Origin-Richtlinie, die eine Reihe von Einschränkungen vorschreibt. Sehen wir uns diese Optionen genauer an.
Dienstprogramme
Die URL des Service Worker-Scripts muss mit der URL der Seite übereinstimmen, auf der register() aufgerufen wird. Das bedeutet, dass eine Seite unter https://www.example.com beispielsweise nicht register() mit einer Service Worker-URL unter https://section.example.com aufrufen kann.
Ein weiterer Punkt ist, dass ein Service Worker nur Seiten steuern kann, die unter dem Ursprung und Pfad gehostet werden, zu dem er gehört. Wenn der Service Worker also bei https://www.example.com gehostet wird, kann er nur URLs von diesem Ursprung steuern (gemäß dem Pfad, der im Parameter „scope“ definiert ist), aber keine Seiten in anderen Subdomains wie z. B. in https://section.example.com.
In diesem Fall besteht die einzige Problemumgehung darin, mehrere Service Worker zu verwenden (jeweils einen pro Ursprung).
Caching
Das Cache-Objekt, IndexedDB und localStorage sind ebenfalls auf einen einzelnen Ursprung beschränkt. Das bedeutet, dass von beispielsweise https://www.section.example.com aus nicht auf die Caches zugegriffen werden kann, die zu https://www.example.com gehören.
Hier sind einige Möglichkeiten, wie Sie Caches in solchen Fällen richtig verwalten können:
Browser-Caching nutzen:Die Verwendung der Best Practices für das traditionelle Browser-Caching wird immer empfohlen. Diese Methode bietet den zusätzlichen Vorteil, dass zwischen verschiedenen Ursprüngen zwischengespeicherte Ressourcen wiederverwendet werden können, was mit dem Cache des Service Workers nicht möglich ist. Best Practices für die Verwendung des HTTP-Caches mit Service Workern finden Sie in diesem Beitrag.
Installation von Service Workern möglichst gering halten:Wenn Sie mehrere Service Worker verwalten, sollten Sie vermeiden, dass Nutzer jedes Mal hohe Installationskosten zahlen müssen, wenn sie zu einer neuen Quelle wechseln. Mit anderen Worten: Vorab nur Ressourcen im Cache speichern, die unbedingt erforderlich sind.
Berechtigungen
Berechtigungen sind auch auf Ursprünge beschränkt. Wenn ein Nutzer also dem Ursprung https://section.example.com eine bestimmte Berechtigung gewährt, wird diese nicht auf andere Ursprünge wie https://www.example.com übertragen.
Da es keine Möglichkeit gibt, Berechtigungen über mehrere Ursprünge hinweg zu teilen, besteht die einzige Lösung darin, für jede Subdomain, für die eine bestimmte Funktion erforderlich ist (z.B. Standort), um die Berechtigung zu bitten. Bei Web-Push-Mitteilungen können Sie ein Cookie verwenden, um zu verfolgen, ob die Berechtigung vom Nutzer in einer anderen Subdomain akzeptiert wurde, damit sie nicht noch einmal angefordert werden muss.
Installation
Zum Installieren einer PWA muss jeder Ursprung ein eigenes Manifest mit einer start_url haben, die relativ zu sich selbst ist. Das bedeutet, dass ein Nutzer, der die Installationsaufforderung auf einer bestimmten Quelle (z. B. https://section.example.com) erhält, die PWA mit einer start_url nicht auf einer anderen Quelle (z. B. https://www.example.com) installieren kann.
Mit anderen Worten: Nutzer, die die Installationsaufforderung in einer Subdomain erhalten, können PWAs nur für die Unterseiten installieren, nicht für die Haupt-URL der App.
Außerdem kann es vorkommen, dass derselbe Nutzer beim Besuch der Website mehrere Installationsaufforderungen erhält, wenn jede Subdomain die Installationskriterien erfüllt und den Nutzer zur Installation der PWA auffordert.
Sie können dieses Problem vermeiden, indem Sie dafür sorgen, dass der Prompt nur auf dem Hauptursprung angezeigt wird. Wenn ein Nutzer eine Subdomain aufruft, die die Installationskriterien erfüllt, geschieht Folgendes:
- Warten auf das Ereignis
beforeinstallprompt - Verhindern, dass die Aufforderung angezeigt wird: Rufen Sie
event.preventDefault()auf.
So sorgen Sie dafür, dass der Prompt nicht an nicht beabsichtigten Stellen auf der Website angezeigt wird, während er beispielsweise weiterhin am Hauptursprung (z.B. auf der Startseite) präsentiert werden kann.
Standalone-Modus
Wenn Sie in einem eigenständigen Fenster surfen, verhält sich der Browser anders, wenn der Nutzer den vom Manifest der PWA festgelegten Bereich verlässt. Das Verhalten hängt von der jeweiligen Browserversion und dem jeweiligen Anbieter ab. In den neuesten Chrome-Versionen wird beispielsweise ein benutzerdefinierter Chrome-Tab geöffnet, wenn ein Nutzer im eigenständigen Modus den Zuständigkeitsbereich verlässt.
In den meisten Fällen gibt es keine Lösung für dieses Problem. Für kleine Teile der Website, die in Subdomains gehostet werden, kann jedoch eine Problemumgehung angewendet werden (z. B. Anmeldeabläufe):
- Die neue URL
https://login.example.comkann in einem Vollbild-iFrame geöffnet werden. - Sobald die Aufgabe im iFrame abgeschlossen ist (z. B. der Anmeldevorgang), kann postMessage() verwendet werden, um alle resultierenden Informationen aus dem iFrame an die übergeordnete Seite zurückzugeben.
- Als letzten Schritt können die Listener nach Empfang der Nachricht auf der Hauptseite abgemeldet und der Iframe schließlich aus dem DOM entfernt werden.
Fazit
Die Richtlinie zum gleichen Ursprung schränkt Websites mit mehreren Ursprüngen, die eine einheitliche PWA-Nutzung bieten möchten, stark ein. Aus diesem Grund empfehlen wir Ihnen, Websites nicht in verschiedene Ursprünge aufzuteilen, um Nutzern die bestmögliche Nutzererfahrung zu bieten.
Bei bestehenden Websites, die bereits so erstellt wurden, kann es schwierig sein, PWAs mit mehreren Ursprüngen richtig zum Laufen zu bringen. Wir haben jedoch einige mögliche Lösungen gefunden. Beide Optionen haben Vor- und Nachteile. Entscheiden Sie daher selbst, welchen Ansatz Sie auf Ihrer Website verfolgen möchten.
Wenn Sie eine langfristige Strategie oder ein Website-Redesign bewerten, sollten Sie eine Migration zu einem einzigen Ursprung in Betracht ziehen, es sei denn, es gibt einen wichtigen Grund, die Architektur mit mehreren Ursprüngen beizubehalten.
Wir bedanken uns für die technischen Überprüfungen und Vorschläge von Penny Mclachlan, Paul Covell, Dominick Ng, Alberto Medina, Pete LePage, Joe Medley, Cheney Tsai, Martin Schierle und Andre Bandarra.