Assets und Daten

Eine progressive Web-App ist eine Website. Alle Assets sind dieselben wie im Web, nur mit neuen Tools, die diese Assets online schnell laden und auch offline verfügbar machen.

App-Komponenten

Die Entwicklung einer Anwendung umfasst in der Regel verschiedene Assets und Ressourcen – von der Logik und dem Code (kompiliert oder nicht kompiliert) bis hin zu Elementen der Benutzeroberfläche wie Bildschirmdesigns, Bildern, Logos und Schriftarten.

Eine progressive Web-App ist eine Website. Daher entsprechen alle Assets denen im Web:

  • HTML für Inhalt und anfängliche Seitendarstellung.
  • JavaScript für die Logik, einschließlich der Möglichkeit, WebAssembly-Module (kompilierter Code) auszuführen und Hardware-optimierte 2D- und 3D-Grafiken zu rendern.
  • CSS für Layout, Stile und Animationen
  • Bilder in Webformaten wie PNG, JPEG, WebP und SVG.
  • Videos in Webformaten wie MPEG-4 und WebM
  • Web-Schriftarten
  • Daten im JSON-Format oder in anderen Formaten.

Standardmäßig laden Websites Assets über das Netzwerk herunter. Der Download beginnt mit HTML und wird mit den restlichen Ressourcen fortgesetzt.

Die Verwaltung dieser Ressourcen, damit sie schnell geladen und offline verfügbar sind, war für das Web eine Herausforderung. Heutzutage stützen PWAs Funktionen, die zuvor nur plattformspezifischen Apps vorbehalten waren.

Plattformspezifische Apps im Vergleich zu PWA

Wenn Sie eine plattformspezifische App installieren, laden Sie in der Regel ein Paket herunter, das alle Assets der App enthält: Code, Bilder, Schriftarten, Videos usw. Dadurch stehen Ihnen alle diese Ressourcen in Ihrem Gerätespeicher zur Verfügung, auch wenn die App offline ist.

Bei einer klassischen Website ist hingegen eine Netzwerkverbindung erforderlich, um die Assets bei Bedarf herunterzuladen. Wenn Sie offline sind, wird ein Fehler im Browser angezeigt, da clientseitig keine Assets vorhanden sind.

Der PWA-Ansatz verbessert die herkömmliche Weberfahrung, indem einige oder alle Assets clientseitig zur Verfügung gestellt werden, wie bei plattformspezifischen Apps. Wenn Sie eine PWA öffnen, erfolgt das anfängliche Rendern daher möglicherweise so unmittelbar wie bei einer Plattform-App, weil die Assets ohne Verbindung zum Netzwerk verfügbar sind.

Caches und Speicher

Seit der Einführung des Webs hatten Entwickler keine vollständige Kontrolle darüber, wie eine Ressource im Cache gespeichert wird. Der Browser ist für den HTTP-Cache verantwortlich und kann Ressourcen je nach Richtlinien möglicherweise im Cache speichern und bereitstellen. Andere Speicheroptionen wie Web Storage und IndexedDB sollten einfache Daten und Objekte speichern.

PWAs sind für ihre Inhalte nicht allein auf diese Richtlinien angewiesen. Stattdessen bieten wir heute Lösungen an, mit denen Sie besser steuern können, wann und wie Ressourcen im Cache gespeichert werden und wann und wie sie lokal bereitgestellt werden: die Cache Storage API. Im Web sind einige clientseitige Speicherlösungen verfügbar:

  • Webspeicher: Umfasst localStorage und sessionStorage. Diese APIs speichern einfache Schlüssel/Wert-String-Paare. Der Webspeicher ist begrenzt und verfügt über eine synchrone API. Daher sollte er nach Möglichkeit vermieden werden.
  • IndexedDB Eine objektbasierte Datenbank (No-SQL) mit einer asynchronen API, die sich gut für die Webleistung eignet. IndexedDB kann strukturierte und binäre Daten clientseitig speichern. In der Regel werden sie zum Speichern von Daten verwendet, z. B. Daten, die Sie als API-Anfrage senden oder erhalten würden. Außerdem empfiehlt es sich, Daten sofort lokal zu speichern und sie später mit dem Server zu synchronisieren. Die IndexedDB API wird für die Interaktion mit der Datenbank verwendet.
  • Cache-Speicher: Eine Sammlung von HTTP-Anfrage- und -Antwortpaaren, mit denen Sie Ressourcen – mit ihren HTTP-Headern – genau so speichern und abrufen können, wie sie vom Server bereitgestellt werden. Mit der Cache Storage API können Sie Netzwerkanfragen z. B. für Ihre Assets speichern, abrufen, aktualisieren und löschen, auch wenn Sie offline sind.

Die Notwendigkeit von Service Workern

Eine PWA kann ihre Assets im Cache-Speicher und in IndexedDB speichern, aber wie können wir diese Assets verwenden, um Ihren Nutzern eine schnelle und Offlinenutzung zu ermöglichen? Die Antwort auf die Frage? Service Workers

Mit einem Service Worker können Sie Assets bereitstellen, ohne eine Verbindung zum Netzwerk herstellen zu müssen, Benachrichtigungen an Nutzer senden, Ihrem PWA-Symbol ein Logo hinzufügen, Inhalte im Hintergrund aktualisieren und sogar die gesamte PWA offline nutzen. Weitere Informationen zu Service Workern finden Sie im nächsten Kapitel.

Offline-fähig

Nutzer erwarten von Ihrer Anwendung, dass sie schnell und jederzeit einsatzbereit ist. Ihre App sollte also auch offline funktionieren.

Eine Offline-Bereitstellung bedeutet nicht, dass alle Ihre Inhalte oder Dienste ohne Netzwerkverbindung verfügbar sein sollten. Wenn der Nutzer offline ist, also beispielsweise eine Seite, auf der Sie aufgefordert werden, eine Verbindung zum Internet herzustellen, um fortfahren zu können, schaffen Sie eine bessere Nutzererfahrung, da der Nutzer Ihre App nicht sehen kann, anstatt einen allgemeinen Browserfehler anzuzeigen. In einigen Browsern ist dies eine unverzichtbare Funktion, um die Installationskriterien für PWAs zu erfüllen. Es ist besser, die Benutzeroberfläche Ihrer PWA zusammen mit im Cache gespeicherten Inhalten anzuzeigen. Nutzer können Ihre gesamte PWA weiterhin verwenden und Serveränderungen synchronisieren, sobald sie wieder online sind. Das ist der Standard für die Offlinearbeit.

Um Ihre App offline verfügbar zu machen, müssen Sie die für Ihre Offlinenutzung erforderlichen Assets im Cache speichern und Ihren Service Worker für eine spätere Bereitstellung bereitstellen. Fügen Sie die Offline-Assets dem Cache hinzu, bevor Sie sie benötigen. Dies ist ein besonderer Fall, in dem Sie sie bei Anforderung nicht im Cache speichern können.

Häufig verwendete Cache-Ansätze

Bei Ihrer PWA sind Sie für alle Entscheidungen verantwortlich. Je nach Ihren Anforderungen können Sie die beste Methode zum Speichern von Assets im Cache wählen oder sie installieren. Hier sind einige Entscheidungen, die Sie treffen müssen:

  • Precaching: Wählen Sie beim ersten Laden die Assets aus, die Sie installieren möchten. Diese sollten den HTML-Code und die Mindestanzahl von Assets zum Rendern der App enthalten. Wenn Sie Precache verwenden, sollten Sie berücksichtigen, dass Sie den Speicherplatz und das Netzwerk des Geräts nutzen. Gehen Sie bewusst und verantwortungsvoll vor, wenn Sie Assets herunterladen und im Cache speichern.
  • Bei Bedarf Cache: Wird verwendet, um Assets zum Cache hinzuzufügen, wenn sie angefordert werden. In der Regel sind dies Assets, die sich unabhängig von der App-Version ändern können, z. B. Bilder oder Inhalte. Im Abschnitt Caching finden Sie verschiedene Strategien für das Caching bei Bedarf.
  • APIs und Webdienste: API-Aufrufe können im Cache gespeichert werden. Anstatt die API-Antworten im Cache zu speichern, können Sie ihre Daten auch in IndexedDB speichern.

Assets aktualisieren

Wenn Entwickler im Standard-App-Modell für im App-Katalog installierte Apps ihre App aktualisieren müssen, veröffentlichen sie ein neues Paket. Nutzer müssen das gesamte Paket noch einmal herunterladen, auch wenn die meisten Assets nicht geändert wurden. Bei PWAs entscheiden Sie anhand der oben beschriebenen Ansätze, wie und wann Sie Assets aktualisieren. Es gibt verschiedene Möglichkeiten, Assets zu aktualisieren:

  • Vollständiges Update: In diesem Fall werden mit dem Code bei jeder Änderung an der App alle Assets wieder in den Cache heruntergeladen – auch wenn es sich um eine kleinere Änderung handelt.
  • Teilweise Aktualisierung: Bei diesem Ansatz erstellen Sie eine Methode, um zu definieren, welche Assets aktualisiert wurden, und aktualisieren nur diese, mit oder ohne Eingriff des Nutzers.
  • Kontinuierliche Aktualisierung: Mit diesem Verfahren werden Ihre Assets bei jeder PWA-Nutzung automatisch geprüft und aktualisiert.

Größe und Lebensdauer

In der Regel haben plattformspezifische Apps keine Auswirkungen auf Größenbeschränkungen. Bei der Installation können Apps Gigabyte oder mehr groß sein. Solange das Gerät genügend Kapazität hat, ist die Installation zulässig. Solange die App installiert ist, wird auch der gesamte Speicherplatz verwendet, unabhängig davon, ob Sie die App verwenden oder nicht. Bei PWAs wird der Speicherplatz anders behandelt. Im Browser werden Ihre Assets gemäß den Richtlinien gespeichert, die Sie in der Logik Ihrer PWA definieren.

Die Größenbeschränkungen hängen vom Browser ab. Sie ist nicht so flexibel wie bei plattformspezifischen Apps, reicht jedoch für die meisten Webanwendungen aus. Die spezifischen Einschränkungen nach Browser finden Sie in diesem Artikel.

Browser können Assets entfernen, wenn der Speicher zu wenig Speicher belegt oder nach einigen Wochen Inaktivität entfernt wird, wenn der Nutzer Ihre PWA im Browser verwendet. Wenn der Nutzer Ihre PWA installiert, kann sie auf einigen Plattformen nicht entfernt werden. Sofern verfügbar, kann Code nichtflüchtigen Speicher über eine API anfordern, um diese Bereinigung zu vermeiden.

Ressourcen