Diese Seite wurde von der Cloud Translation API übersetzt.

Progressive Web-Apps auf Websites mit mehreren Ursprungsservern

Herausforderungen und Workarounds beim Erstellen progressiver Web-Apps auf Websites mit mehreren Ursprüngen.

Demián Renzulli

Hintergrund

In der Vergangenheit gab es einige Vorteile bei der Verwendung von Architekturen mit mehreren Ursprüngen, aber für Progressive Web-Apps birgt dieser Ansatz viele Herausforderungen. Insbesondere die Richtlinie für denselben Ursprung schränkt die gemeinsame Nutzung von Service Workern und Caches, Berechtigungen und die Möglichkeit ein, eine eigenständige Nutzung über mehrere Ursprünge hinweg zu ermöglichen. In diesem Artikel werden die Vor- und Nachteile der Verwendung mehrerer Ursprünge beschrieben und die Herausforderungen und Workarounds für die Erstellung von Progressive Web-Apps auf Websites mit mehreren Ursprüngen erläutert.

Gute und schlechte Verwendung mehrerer Ursprünge

Es gibt einige legitime Gründe für die Verwendung einer Architektur mit mehreren Ursprüngen auf Websites, die hauptsächlich mit der Bereitstellung einer unabhängigen Gruppe von Webanwendungen oder der Erstellung von Erfahrungen zusammenhängen, die vollständig voneinander isoliert sind. Es gibt auch Verwendungszwecke, die vermieden werden sollten.

Gut gelöste Punkte

Sehen wir uns zuerst die nützlichen Gründe an:

Lokalisierung / Sprache:Sie können eine Top-Level-Domain mit Ländercode verwenden, um Websites zu trennen, die in verschiedenen Ländern ausgeliefert werden sollen (z.B. https://www.google.com.ar), oder Subdomains, um Websites zu unterteilen, die auf verschiedene Standorte ausgerichtet sind (z.B.: https://newyork.craigslist.org) oder um Inhalte für eine bestimmte Sprache anzubieten (z.B. https://en.wikipedia.org).
Unabhängige Web-Apps:Sie verwenden verschiedene Subdomains, um Inhalte bereitzustellen, deren Zweck sich erheblich von der Website im Hauptursprung unterscheidet. Auf einer Nachrichtenseite könnte die Kreuzworträtsel-Web-App beispielsweise absichtlich über https://crosswords.example.com bereitgestellt und als unabhängige PWA installiert und verwendet werden, ohne dass Ressourcen oder Funktionen mit der Hauptwebsite geteilt werden müssen.

Die schlechten

Wenn Sie keine dieser Dinge tun, ist es wahrscheinlich, dass die Verwendung einer Architektur mit mehreren Ursprüngen beim Erstellen von progressiven Web-Apps ein Nachteil ist.

Trotzdem sind viele Websites weiterhin so strukturiert, ohne dass es dafür einen bestimmten Grund gibt oder aus „traditionellen“ Gründen. Ein Beispiel ist die Verwendung von Subdomains, um Teile einer Website, die Teil einer einheitlichen Nutzererfahrung sein sollten, willkürlich zu trennen.

Die folgenden Muster sind beispielsweise nicht zulässig:

Websitebereiche:Verschiedene Bereiche einer Website werden auf Subdomains aufgeteilt. Bei Nachrichtenseiten ist es nicht ungewöhnlich, dass die Startseite unter https://www.example.com, der Sportbereich unter https://sports.example.com und der Politikbereich unter https://politics.example.com zu finden sind. Bei einer E-Commerce-Website können Sie beispielsweise https://category.example.com für Produktkategorien und https://product.example.com für Produktseiten verwenden.
Nutzerfluss:Ein weiterer Ansatz, der nicht empfohlen wird, besteht darin, verschiedene kleinere Teile der Website, z. B. Seiten für den Anmelde- oder Kaufvorgang, in Subdomains zu trennen. Beispiel: https://login.example.com und https://checkout.example.com.

Für die Fälle, in denen eine Migration zu einem einzelnen Ursprung nicht möglich ist, folgt eine Liste mit Herausforderungen und (wenn möglich) Problemumgehungen, die beim Erstellen von progressiven Web-Apps in Betracht gezogen werden können.

Herausforderungen und Behelfslösungen für PWAs in verschiedenen Ursprüngen

Wenn Sie eine Website auf mehreren Ursprüngen erstellen, ist es schwierig, eine einheitliche PWA-Umgebung zu bieten, was hauptsächlich an der Same-Origin-Richtlinie liegt, die eine Reihe von Einschränkungen mit sich bringt. Sehen wir uns die einzelnen Optionen an.

Service Worker

Der Ursprung der Service Worker-Skript-URL muss mit dem Ursprung der Seite übereinstimmen, die register() aufruft. 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.

Außerdem kann ein Service Worker nur Seiten steuern, die unter dem Ursprung und Pfad gehostet werden, zu dem er gehört. Wenn der Service Worker unter https://www.example.com gehostet wird, kann er nur URLs dieses Ursprungs steuern (entsprechend dem im scope-Parameter definierten Pfad), aber keine Seiten in anderen Subdomains wie z. B. https://section.example.com.

In diesem Fall besteht die einzige Problemumgehung darin, mehrere Service Worker (einen pro Herkunft) zu verwenden.

Caching

Das Cache-Objekt, IndexedDB und localStorage sind ebenfalls auf einen einzelnen Ursprung beschränkt. Das bedeutet, dass Sie beispielsweise über https://www.section.example.com nicht auf die Caches zugreifen können, die zu https://www.example.com gehören.

So können Sie Caches in solchen Fällen richtig verwalten:

Browser-Caching nutzen:Es wird immer empfohlen, herkömmliche Best Practices für das Browser-Caching zu verwenden. Diese Technik bietet den zusätzlichen Vorteil, dass zwischen verschiedenen Ursprüngen auf zwischengespeicherte Ressourcen zurückgegriffen werden kann. Das ist mit dem Cache des Service Workers nicht möglich. Best Practices für die Verwendung des HTTP-Cache mit Service Workern finden Sie in diesem Beitrag.
Service Worker-Installation schlank halten:Wenn Sie mehrere Service Worker verwalten, sollten Sie vermeiden, dass Nutzer jedes Mal, wenn sie zu einem neuen Ursprung navigieren, hohe Installationskosten zahlen müssen. Das bedeutet: Cachen Sie nur Ressourcen vor, die unbedingt erforderlich sind.

Berechtigungen

Berechtigungen sind auch auf Ursprünge beschränkt. Wenn ein Nutzer dem Ursprung https://section.example.com eine bestimmte Berechtigung erteilt hat, wird diese nicht auf andere Ursprünge wie https://www.example.com übertragen.

Da Berechtigungen nicht für mehrere Ursprünge freigegeben werden können, besteht die einzige Lösung darin, die Berechtigung für jede Subdomain anzufordern, in der eine bestimmte Funktion (z.B. Standort) erforderlich ist. Bei Web-Push-Benachrichtigungen können Sie ein Cookie verwenden, um zu erfassen, ob die Berechtigung vom Nutzer in einer anderen Subdomain akzeptiert wurde. So vermeiden Sie, dass die Berechtigung noch einmal angefordert wird.

Installation

Damit eine PWA installiert werden kann, muss jeder Ursprung ein eigenes Manifest mit einem start_url haben, das relativ zum Ursprung ist. Das bedeutet, dass ein Nutzer, der die Installationsaufforderung für einen bestimmten Ursprung (z. B. https://section.example.com) erhält, die PWA mit einem start_url nicht auf einem anderen Ursprung (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 und nicht für die Haupt-URL der App installieren.

Außerdem kann es vorkommen, dass derselbe Nutzer beim Navigieren auf der Website mehrere Installationsaufforderungen erhält, wenn jede Subdomain die Installationskriterien erfüllt und den Nutzer auffordert, die PWA zu installieren.

Um dieses Problem zu beheben, können Sie dafür sorgen, dass die Aufforderung nur auf dem Hauptursprung angezeigt wird. Wenn ein Nutzer eine Subdomain aufruft, die die Installationskriterien erfüllt, gilt Folgendes:

Auf das Ereignis beforeinstallprompt warten.
Verhindern, dass die Aufforderung angezeigt wird, indem Sie event.preventDefault() aufrufen.

So wird sichergestellt, dass der Prompt nicht an unerwünschten Stellen der Website angezeigt wird, während er beispielsweise weiterhin im Hauptursprung (z.B. auf der Startseite) angezeigt werden kann.

Eigenständiger Modus

Wenn der Nutzer in einem eigenständigen Fenster navigiert, verhält sich der Browser anders, wenn er den im 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 Standalone-Modus den Bereich verlässt.

In den meisten Fällen gibt es dafür keine Lösung. Für kleine Teile der Benutzeroberfläche, die auf Subdomains gehostet werden (z. B. Anmelde-Workflows), kann jedoch ein Workaround angewendet werden:

Die neue URL https://login.example.com könnte 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 vom iFrame an die übergeordnete Seite zurückzugeben.
Sobald die Nachricht auf der Hauptseite empfangen wurde, können die Listener abgemeldet und das iFrame schließlich aus dem DOM entfernt werden.

Fazit

Die Same-Origin-Policy schränkt Websites, die auf mehreren Ursprüngen basieren und eine einheitliche PWA-Erfahrung bieten möchten, stark ein. Um Nutzern die bestmögliche Erfahrung zu bieten, raten wir daher dringend davon ab, Websites in verschiedene Ursprünge aufzuteilen.

Bei bestehenden Websites, die bereits auf diese Weise erstellt wurden, kann es schwierig sein, PWAs mit mehreren Ursprüngen richtig zum Laufen zu bringen. Wir haben jedoch einige mögliche Problemumgehungen untersucht. Jeder Ansatz hat seine Vor- und Nachteile. Sie sollten daher sorgfältig abwägen, welcher Ansatz für Ihre Website am besten geeignet ist.

Wenn Sie eine langfristige Strategie oder eine Neugestaltung der Website in Erwägung ziehen, sollten Sie eine Migration zu einem einzelnen Ursprungsserver in Betracht ziehen, es sei denn, es gibt einen wichtigen Grund, die Architektur mit mehreren Ursprungsservern beizubehalten.

Vielen Dank für die technischen Überprüfungen und Vorschläge: Penny Mclachlan, Paul Covell, Dominick Ng, Alberto Medina, Pete LePage, Joe Medley, Cheney Tsai, Martin Schierle und Andre Bandarra.