Diese Seite wurde von der Cloud Translation API übersetzt.

Progressive Web-Apps auf Websites mit mehreren Ursprungsservern

Herausforderungen und Behelfslösungen für die Entwicklung progressiver Web-Apps auf Multi-Origin-Websites

Demián Renzulli

Hintergrund

In der Vergangenheit hatte die Verwendung von Multi-Origin-Architekturen einige Vorteile, aber für progressive Web-Apps birgt dieser Ansatz viele Herausforderungen. Die Richtlinie für denselben Ursprung schränkt insbesondere die gemeinsame Nutzung von Elementen wie Service Workern und Caches, Berechtigungen und zum Erstellen einer eigenständigen Umgebung über mehrere Ursprünge hinweg ein. In diesem Artikel werden die guten und die negativen Verwendungen mehrerer Ursprünge beschrieben. Außerdem werden die Herausforderungen und Problemumgehungen für die Erstellung progressiver Web-Apps auf Multi-Origin-Websites erläutert.

Gute und schlechte Verwendung mehrerer Ursprünge

Es gibt einige legitime Gründe für die Verwendung einer Multi-Origin-Architektur, die hauptsächlich auf der Bereitstellung unabhängiger Webanwendungen oder der Erstellung von Inhalten besteht, die vollständig voneinander getrennt 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 verwenden eine länderspezifische Top-Level-Domain, um Websites zu trennen, die in verschiedenen Ländern ausgeliefert werden sollen (z.B. https://www.google.com.ar), oder mithilfe von Subdomains, um Websites aufzuteilen, die auf verschiedene Standorte ausgerichtet sind (z.B. https://newyork.craigslist.org) oder Inhalte für eine bestimmte Sprache (z.B. https://en.wikipedia.org) anzubieten.
Unabhängige Web-Apps:Es werden verschiedene Subdomains verwendet, um Nutzerfreundlichkeit zu bieten, deren Zweck sich erheblich von der Website des eigentlichen Ursprungs unterscheidet. Auf einer Nachrichtenwebsite könnte die Kreuzworträtsel-Webanwendung beispielsweise absichtlich von 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.

Das Schlechte

Wenn Sie all das nicht tun, ist die Verwendung einer Multi-Origin-Architektur bei der Entwicklung progressiver Web-Apps wahrscheinlich ein Nachteil.

Trotzdem werden viele Websites ohne besonderen Grund oder aus „veralteten“ Gründen weiterhin so strukturiert. Ein Beispiel ist die Verwendung von Subdomains zur willkürlichen Trennung von Teilen einer Website, die Teil eines einheitlichen Erlebnisses sein sollen.

Von den folgenden Mustern wird beispielsweise dringend abgeraten:

Websitebereiche:Verschiedene Bereiche einer Website durch Subdomains voneinander trennen. Auf Nachrichten-Websites befindet sich die Startseite häufig unter https://www.example.com, der Sportbereich hingegen unter https://sports.example.com, Politik unter https://politics.example.com usw. Bei einer E-Commerce-Website sollte zum Beispiel https://category.example.com für Produktkategorien oder https://product.example.com für Produktseiten verwendet werden.
Nutzerfluss:Wir raten auch davon ab, verschiedene kleinere Bereiche der Website, wie z. B. die Seiten für die Anmeldung oder den Kaufvorgang, in Subdomains zu trennen. Beispiel: https://login.example.com und https://checkout.example.com.

Für den Fall, dass eine Migration zu einem einzigen Ursprung nicht möglich ist, finden Sie nachfolgend eine Liste mit Herausforderungen und (wenn möglich) Problemumgehungen, die bei der Entwicklung progressiver Web-Apps in Betracht gezogen werden können.

Herausforderungen und Behelfslösungen für PWAs unterschiedlicher Herkunft

Wenn eine Website aus mehreren Ursprüngen erstellt wird, ist die Bereitstellung einer einheitlichen PWA eine Herausforderung, hauptsächlich aufgrund der Richtlinie für denselben Ursprung, die eine Reihe von Einschränkungen auferlegt. Sehen wir sie uns einzeln 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 register() nicht mit einer Service Worker-URL unter https://section.example.com aufrufen kann.

Eine weitere Überlegung 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 unter https://www.example.com gehostet wird, kann er also nur URLs aus diesem Ursprung steuern (gemäß dem Pfad, der im Bereichsparameter definiert ist), aber keine Seite in anderen Subdomains, z. B. denen in https://section.example.com.

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

Caching

Das Cache-Objekt, indexedDB und localStorage sind ebenfalls auf einen einzelnen Ursprung beschränkt. Es ist also nicht möglich, auf die Caches von https://www.example.com zuzugreifen, z. B. über https://www.section.example.com.

Hier sind einige Dinge, die Sie in Szenarien wie diesem tun können, um Caches richtig zu verwalten:

Browser-Caching nutzen: Die Anwendung der Best Practices für das herkömmliche Browser-Caching wird immer empfohlen. Diese Methode bietet den zusätzlichen Vorteil, dass im Cache gespeicherte Ressourcen ursprungsübergreifend wiederverwendet werden, 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.
Weniger Aufwand für Service Worker-Installation: Wenn Sie mehrere Service Worker unterhalten, vermeiden Sie, dass Nutzer bei jeder Fahrt zu einem neuen Ursprung hohe Installationskosten zahlen müssen. Mit anderen Worten: Speichern Sie nur Ressourcen vorab im Cache, die unbedingt erforderlich sind.

Berechtigungen

Berechtigungen gelten auch für Ursprünge. Wenn also ein Nutzer eine 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 für verschiedene Ursprünge zu teilen, besteht die einzige Lösung hier darin, die Berechtigung für jede Subdomain anzufordern, in der eine bestimmte Funktion (z.B. Standort) erforderlich ist. Bei Web-Push-Aktionen können Sie mithilfe eines Cookies erfassen, ob die Berechtigung von einem Nutzer in einer anderen Subdomain akzeptiert wurde. So wird eine erneute Anfrage vermieden.

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 von einem bestimmten Ursprung (z. B. https://section.example.com) erhalten, die PWA nicht mit einer start_url auf einem anderen Gerät (z. B. https://www.example.com) installieren können. Anders gesagt: 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 besteht das Problem, dass derselbe Nutzer beim Aufrufen der Website mehrere Installationsaufforderung erhält, wenn jede Subdomain die Installationskriterien erfüllt und der Nutzer aufgefordert wird, die PWA zu installieren.

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

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

So sorgen Sie dafür, dass die Aufforderung nicht an ungewollten Stellen auf der Website erscheint, während sie weiterhin eingeblendet werden kann, z. B. im Hauptort (z. B. auf der Startseite).

Eigenständiger Modus

Wenn Nutzer in einem eigenständigen Fenster navigieren, 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 dem Anbieter ab. In den neuesten Chrome-Versionen wird beispielsweise ein benutzerdefinierter Tab in Chrome geöffnet, wenn ein Nutzer im eigenständigen Modus aus dem Bereich wechselt.

In den meisten Fällen gibt es keine Lösung, aber eine Problemumgehung kann für kleine Teile der Websitevariante verwendet werden, die in Subdomains gehostet wird (z. B. Anmeldeworkflows):

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 Anmeldevorgang, können mit postMessage() alle Informationen aus dem iFrame zurück an die übergeordnete Seite übergeben werden.
Sobald die Nachricht von der Hauptseite empfangen wurde, kann als letzter Schritt die Registrierung der Listener aufgehoben und der iFrame schließlich aus dem DOM entfernt werden.

Fazit

Die Richtlinie für denselben Ursprung legt viele Einschränkungen für Websites fest, die auf mehreren Ursprüngen basieren und eine kohärente PWA‐Nutzung erreichen möchten. Für eine optimale Nutzererfahrung raten wir daher dringend davon ab, Websites in verschiedene Ursprünge zu unterteilen.

Bei bestehenden Websites, die bereits auf diese Weise erstellt wurden, kann es schwierig sein, PWAs mit mehreren Quellen richtig zu funktionieren. Wir haben jedoch einige mögliche Problemumgehungen gefunden. Beides kann Nachteile mit sich bringen. Überlegen Sie sich daher gut, welchen Ansatz Sie für Ihre Website wählen möchten.

Bei der Bewertung einer langfristigen Strategie oder einer Neugestaltung der Website solltest du auf einen einzelnen Ursprung umstellen, sofern es keinen wichtigen Grund für die Beibehaltung der Multi-Origin-Architektur gibt.

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.