Diese Seite wurde von der Cloud Translation API übersetzt.

Progressive Web-Apps auf Websites mit mehreren Ursprungsservern

Herausforderungen und Behelfslösungen bei der Erstellung progressiver Web-Apps auf Websites mit mehreren Quellen

Demián Renzulli

Hintergrund

In der Vergangenheit hatte die Verwendung von Multi-Origin-Architekturen einige Vorteile, aber für progressive Web-Apps bringt dieser Ansatz viele Herausforderungen mit sich. Insbesondere schreibt die Same-Origin-Policy Einschränkungen für die Freigabe von Dingen wie Service Workern und Caches, Berechtigungen und die Bereitstellung einer eigenständigen Umgebung für mehrere Ursprünge vor. In diesem Artikel werden die guten und schlechten Verwendungen mehrerer Quellen beschrieben. Außerdem werden die Herausforderungen und Behelfslösungen für die Entwicklung progressiver Web-Apps auf Websites mit mehreren Quellen beschrieben.

Gute und schlechte Verwendungen unterschiedlicher Herkunft

Es gibt einige legitime Gründe für die Verwendung einer Multi-Origin-Architektur, die sich zumeist damit zusammensetzt, dass eine unabhängige Gruppe von Webanwendungen bereitgestellt wird oder die vollständig voneinander isoliert sind. Es gibt auch Anwendungsfälle, 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). Sie können auch Subdomains verwenden, um Websites aufzuteilen, die auf verschiedene Standorte ausgerichtet sind. Beispiel: https://newyork.craigslist.org) oder Inhalte in einer bestimmten Sprache (z.B. https://en.wikipedia.org) anzubieten.
Unabhängige Web-Apps:Verwendung verschiedener Subdomains, um Inhalte bereitzustellen, deren Zweck sich erheblich von der Website hinsichtlich ihrer Hauptquelle unterscheidet. Auf einer Nachrichtenwebsite könnte die Kreuzworträtsel-App beispielsweise absichtlich über https://crosswords.example.com bereitgestellt und als unabhängige PWA installiert und verwendet werden, ohne dass Ressourcen oder Funktionen für die Hauptwebsite freigegeben werden müssen.

Das Schlechte

Wenn Sie keine dieser Maßnahmen ergreifen, ist die Verwendung einer Multi-Origin-Architektur bei der Entwicklung progressiver Web-Apps wahrscheinlich nachteilig.

Trotzdem sind viele Websites ohne besonderen Grund oder wegen der „Legacy“-Gründe weiterhin so strukturiert. Ein Beispiel ist die Verwendung von Subdomains, um Teile einer Website beliebig zu trennen, was Teil einer einheitlichen Nutzererfahrung sein soll.

Von den folgenden Mustern wird beispielsweise dringend abgeraten:

Website-Bereiche:Trennen verschiedener Bereiche einer Website durch Subdomains. Auf Nachrichten-Websites ist es nicht ungewöhnlich, dass die Startseite unter https://www.example.com angezeigt wird, während sich der Sportbereich unter https://sports.example.com, die Politik unter https://politics.example.com usw. befindet. Bei einer E-Commerce-Website wird beispielsweise https://category.example.com für Produktkategorien oder https://product.example.com für Produktseiten verwendet.
Nutzerfluss:Ein anderer Ansatz, von dem abgeraten wird, besteht darin, verschiedene kleinere Teile der Website voneinander zu trennen, z. B. Seiten für die Anmeldung oder Kaufprozesse in Subdomains. Beispiel: https://login.example.com und https://checkout.example.com.

Wenn die Migration zu einem einzigen Ursprung nicht möglich ist, finden Sie im Folgenden eine Liste mit Herausforderungen und (wenn möglich) Behelfslösungen, die bei der Entwicklung progressiver Web-Apps in Betracht gezogen werden können.

Herausforderungen und Behelfslösungen für PWAs unterschiedlicher Ursprünge

Wenn Sie eine Website mit mehreren Ursprüngen erstellen, ist die Bereitstellung einer einheitlichen PWA-Nutzererfahrung eine Herausforderung. Das liegt hauptsächlich an der Same-Origin-Richtlinie, die einige Einschränkungen mit sich bringt. Sehen wir sie uns nacheinander 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.

Eine weitere Überlegung ist, dass ein Service Worker nur Seiten verwalten kann, die unter dem Ursprung und Pfad gehostet werden, zu dem sie gehören. Wenn der Service Worker unter https://www.example.com gehostet wird, kann er also gemäß dem im scope-Parameter definierten Pfad nur URLs aus diesem Ursprung steuern. Er kann jedoch keine Seiten in anderen Subdomains wie https://section.example.com steuern.

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

Caching

Das Cache-Objekt, indexiertDB und localStorage sind ebenfalls auf einen einzigen Ursprung beschränkt. Das bedeutet, dass kein Zugriff auf die Caches von https://www.example.com, z. B. https://www.section.example.com, möglich ist.

So können Sie Caches in solchen Szenarien richtig verwalten:

Browser-Caching nutzen:Die Best Practices für das herkömmliche Browser-Caching werden immer empfohlen. Diese Technik bietet den zusätzlichen Vorteil, dass im Cache gespeicherte Ressourcen ursprungsübergreifend wiederverwendet werden können, was mit dem Cache des Service Workers nicht möglich ist. Best Practices zur Verwendung des HTTP-Cache mit Service Workern finden Sie in diesem Beitrag.
Geringere Service-Worker-Installation: Wenn Sie mehrere Service Worker unterhalten, vermeiden Sie, dass Nutzer jedes Mal hohe Installationskosten zahlen müssen, wenn sie zu einem neuen Ursprung wechseln. Mit anderen Worten: Speichern Sie nur unbedingt notwendige Ressourcen vorab im Cache.

Berechtigungen

Berechtigungen beziehen sich auch auf Ursprünge. Wenn also ein Nutzer eine bestimmte Berechtigung für den Ursprung https://section.example.com erteilt hat, wird diese nicht auf andere Ursprünge wie https://www.example.com übertragen.

Da es keine Möglichkeit gibt, Berechtigungen ursprungsübergreifend zu teilen, besteht die einzige Lösung hier darin, für jede Subdomain, in der ein bestimmtes Element erforderlich ist (z.B. Standort), um die Berechtigung zu bitten. Für Dinge wie Web-Push können Sie ein Cookie pflegen, um zu verfolgen, ob der Nutzer die Berechtigung in einer anderen Subdomain akzeptiert hat. So müssen Sie nicht noch einmal darum bitten.

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 Nutzer, die die Installationsaufforderung auf einem bestimmten Ursprung (z. B. https://section.example.com) erhalten, die PWA nicht mit einer start_url auf einer anderen (z. B. https://www.example.com) installieren können. Das bedeutet, dass Nutzer, die die Installationsaufforderung in einer Subdomain erhalten, PWAs nur für die Unterseiten und nicht für die Haupt-URL der App installieren können.

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 dazu auffordert, die PWA zu installieren.

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

Auf Ereignis beforeinstallprompt warten.
Verhindere, dass die Aufforderung angezeigt wird, indem event.preventDefault() aufgerufen wird.

Auf diese Weise stellen Sie sicher, dass die Aufforderung nicht an unbeabsichtigten Bereichen der Website angezeigt wird. Sie können sie aber weiterhin einblenden, z. B. auf der Startseite.

Eigenständiger Modus

Während der Navigation in einem eigenständigen Fenster verhält sich der Browser anders, wenn der Nutzer den Bereich verlässt, der im Manifest der PWA festgelegt ist. Das Verhalten hängt von der jeweiligen Browserversion und vom Anbieter ab. In den aktuellen Chrome-Versionen wird beispielsweise ein benutzerdefinierter Tab in Chrome geöffnet, wenn ein Nutzer den Bereich im eigenständigen Modus verlässt.

In den meisten Fällen gibt es dafür keine Lösung, aber für kleine Bereiche der Website, die in Subdomains gehostet werden (z. B. Anmelde-Workflows), kann eine Behelfslösung angewendet werden:

Die neue URL https://login.example.com könnte in einem Vollbild-iFrame geöffnet werden.
Sobald die Aufgabe innerhalb des iFrames abgeschlossen ist, z. B. der Anmeldeprozess, können Sie mit postMessage() alle resultierenden Informationen aus dem iFrame zurück an die übergeordnete Seite übergeben.
Als letzten Schritt kann die Registrierung der Listener aufgehoben werden, sobald die Nachricht von der Hauptseite empfangen wurde, und der iFrame wird schließlich aus dem DOM entfernt.

Fazit

Die Same-Origin-Richtlinie schreibt viele Einschränkungen für Websites vor, die auf mehreren Ursprüngen basieren und für ein einheitliches PWA-Erlebnis sorgen sollen. Aus diesem Grund raten wir dringend davon ab, Websites in verschiedene Ursprünge zu unterteilen, um den Nutzern ein optimales Erlebnis zu bieten.

Bei bestehenden Websites, die bereits auf diese Weise erstellt wurden, kann es schwierig sein, PWAs mit mehreren Quellen richtig zu funktionieren. Wir haben aber einige Behelfslösungen in Betracht gezogen. Beides kann Nachteile haben. Entscheiden Sie daher nach Ihrem eigenen Ermessen, welchen Ansatz Sie für Ihre Website wählen.

Wenn Sie eine langfristige Strategie oder die Neugestaltung einer Website in Betracht ziehen, sollten Sie zu einem einzigen Ursprung migrieren, es sei denn, es gibt einen wichtigen Grund, die Multi-Origin-Architektur beizubehalten.

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