PWA - Progressive Web Apps

Also meine Erfahrungen damit sind gemischt und hängen eigentlich noch Jahre zurück, eigentlich an dem Punkt von meinem letzten Thread hier dazu, Deine sw.js ist eigentlich vom Aufbau her wie meine, aber doch an entscheidenden Stellen anders und genau hier sehe ich eigentlich Probleme, die da wohl auch kommen werden. Zumindest denke ich das so und es würde mit den ganzen Warnungen der diversen Anleitungen, darunter MSN und Mozilla übereinstimmen.

Vorab ist Deine JS etwas seltsam aufgebaut, zumindest die Funktionen, die meine nicht hat. Die funktionieren zwar technisch, sind aber von der Syntax her unlogisch und auch deren Beschreibungen. Da werden nämlich true und false vertauscht.

Da gibt es z.B. eine Liste an URLs, die niemals gecacht werden soll.

const neverCacheUrls = [/\/wp-admin/,/\/wp-login/,/preview=true/];

Dazu gibt es eine Funktion, die den fetch() abbricht, wenn die URL in der "Sperrliste" vorkommt. Aber wie man sieht, die Prüfung ist da umgedreht. Der bricht nicht ab, wenn die URL enthalten ist, sondern, wenn sie nicht enthalten ist. man beachte da das if( ! ....)

    // Return if the current request url is in the never cache list
    if ( ! neverCacheUrls.every(checkNeverCacheList, e.request.url) ) {
      console.log( 'SuperPWA: Current request is excluded from cache.' );
      return;
    }

Das ist so erst mal eigentlich falsch, wird dann aber richtig, weil die nächste Funktion auch falsch ist. Die prüfen also beide falsch auf true und false, damit es am Ende wieder richtig wird.

// Check if current url is in the neverCacheUrls list
function checkNeverCacheList(url) {
    if ( this.match(url) ) {
        return false;
    }
    return true;
}

Man beachte auch hier. Das Ding prüft, ob eine URL enthalten ist mit "if ( this.match(url) )". Wenn sie enthalten ist, dann sendet es false. Naja, wenn eine Prüfung positiv ist, also nach enthalten gesucht wird und es enthalten ist, dann sollte ein true kommen und kein false. Aber wie gesagt, da beide Funktionen das umkehren, passt es wieder. Ist aber seltsam, schlecht lesbar und schlecht erweiterbar.

So, was ich da aber als Fehler sehe, der aber erst später auftreten wird, ist die Bezeichnung der sw.js, in dem Fall als "superpwa-sw.js?2.2.17". Eine Grundregel ist beim Service-Worker eigentlich, dass sich der Dateiname des Workers nicht ändern darf. Die Kennung 2.2.17 deutet aber genau darauf hin.

Warum sollte man das nicht tun?

Weil die Browser, die den Service-Worker bereits installiert haben, einen neuen mit einem neuen Namen nicht mitbekommen bzw. der alte immer aktiv bleibt. Der Grund ist ganz einfach. Der Worker selbst, also die "superpwa-sw.js?2.2.17" liegt ja selbst im Cache. Er ist im Browser installiert und aktiviert. Also nutzt der Browser später, Wochen, Jahre später, nach einer Umbenennung, immer noch den, den er installiert hat. Der installierte wird auch nicht aktualisiert, denn der neue, aktualisierte Worker, hat dann ja einen anderen Namen.

Genau dieses Verhalten hatte ich auch bei mir, ich spielte da nämlich auch mit sw-test-1, sw-test-2 und sw-test-3 rum. Im Test ging das alles, da installierte Worker immer per Hand installiert und deinstalliert wurden, im laufenden Betrieb passiert das aber nicht. Da wird installiert und, wenn erforderlich, der installierte aktualisiert, ein deinstallieren ist in den aktiven Workern nicht vorgesehen. Wie oben erwähnt, ein anderer Name ist dann aber ein anderer Worker, das nicht zu einer Aktualisierung des alten führt. Wenn da dann später also ein Worker mit der Kennung "2.2.18" kommt, dann wird der installiert und aktiviert, der mit der "2.2.17" bleibt aber da.

Das führte bei mir zu dem Fall, heute teilweise noch, dass Browser auf Daten zugriffen, insbesondere JS und CSS, die ihrerseits Zeitstempel haben, die es nicht mehr gibt. Klar, die haben den alten Worker aktiv. In dem alten Worker waren die Files so für den Cache angelegt. Und was macht der Worker nun? Er will diese Files nutzen.

Daher ist auch die Aussage im Glossar falsch bzw. richtig, aber genau das Gegenteil von Deiner Worker-App "2.2.17":

Zitat

Aktualisierungen in Echtzeit: PWAs ermöglichen es den Entwicklern, Updates in Echtzeit bereitzustellen. Da PWAs auf einem Server gehostet werden, erhalten alle Benutzer automatisch die neueste Version, wenn sie die App öffnen.

Das passiert halt nur, wenn die App die gleiche ist wie vorher, also die gleiche interne App-Kennung hat. Hat sie einen anderen Namen, dann nicht mehr. Im Grunde wie jede andere App. Wenn Du eine in den Store hochlädst, dann verteilen sich die Updates auch von alleine. So lange, bis Du ein Update machst und das als neue App dort hochlädst, denn dann gibt es quasi zwei (zwei App-Kennungen). Eine alte App und eine neue App. Hat man die alte installiert, dann kann sich die neue aktualisieren so oft wie sie will, bemerkt man nicht, denn lokal installiert hat man ja die alte.

Das mit dem Store war nun nur ein Vergleich, aber mit der WebApp passiert genau das gleiche. Hat man da v1 installiert und die App bleibt gleich. Dann kann es Updates auf 1.1, 1.2, 1.x etc geben. Bringt der Entwickler aber ein komplett neues Produkt unter anderer Kennung, vielleicht dann als v2, dann muss man die neu installieren. Denn die vorhanden sucht ja nur nach Updates von der 1.x

Im Grunde auch wie Debian oder Ubuntu. Wenn man da die letzte Stable drauf hat, kommen Updates. So lange, bis sich das Produkt an sich ändert. Dann kann man nach Stable-Updates suchen wie man mag, denn es gibt keine mehr für den installierten Zweig. Es gibt dann ja eine neue Stable, die neu installiert werden muss. Genau das passiert, wenn sich der Name des Workers ändert.

Die Idee hatte ich auch schon mal und hab es vor... 2 Jahren(?) auf einem Testshop versucht.
Das hat sogar auf Anhieb funktioniert, was bei mir eher selten der Fall ist, scheiterte aber letztendlich daran, das man dafür eine große Community oder sehr viele User braucht.
Ein kleiner Shop braucht da erst gar nicht anfangen wollen. Das lädt einfach keiner runter.

Und noch ein Nadelöhr: Ich verwende ja viele Bilder. So richtig viele^^

Ich hab das da verwendet: https://www.opencart.com/index.php?rout…r=Todor%20Donev

Das Thema PWA muss man ja eigentlich in seine Bestandteile trennen. Das, was Alex oben schreibt, was PWAs alles haben, sind keine Dinge, die sie haben, sondern haben können und genau das macht dann zusammen, wenn man will, die installierbare WPA.

Service-Worker

Zuerst hat man ja nur mal einen Service-Worker. Der macht ja quasi die Hauptaufgabe, das Caching, wenn man dem das vorgibt. Das macht der ja nicht von alleine, man muss das dem schon sagen, dass er es machen soll und nach welcher Strategie bzw. unterschiedlichen Strategien in unterschiedlichen Fällen, z.B. Dokumente, Bilder, CSS und andere Daten und da dann eben CacheFirst, NetworkFirst, CacheWithFallback oder StaleWhileRevalidate.

Manifest

Dann gibt es da das Manifest. Das ist auch nichts neues. Wenn man etwas mit Favicons spielt und dort dann auch die Angaben machen will für Hintergrundfarben, Kacheln für Windows und größere Icons, dann hat man schon ein Manifest.

Nicht installierbare WPA

Dann gibt es die nicht installierbare WPA. Das hat man im Grunde schon von alleine, wenn man die beiden obigen Punkte hat. Hinzu kommt eigentlich nur noch was wie "Titel" und "Beschreibung" im Manifest. Der Service-Worker muss in dem Fall Cachen können, aber das können eigentlich alle.

Installierbare WPA

Zuletzt gibt es dann die installierbare WPA, das ist auch das gleiche wie oben, nur dass in dem Fall ein Offline-Modus dabei sein muss und noch ein paar andere Dinge, die auf einer Webseite Voraussetzung sind. Vieles davon ist bei Alex eingebaut, aber nicht, weil es so richtig ist, sondern damit die entsprechenden Bedingungen gefüllt sind, auch wenn es sinnlos ist, und es installierbar wurde. Wenn man die App von Alex aber installiert (nicht die oben genannte Glossar, sondern die Koran), dann merkt man, dass da offline noch nicht mal die Grundfunktionen funktionieren. Genau genommen muss dem aber so sein, wenn man die im Store einreicht. Scheint wohl nicht wirklich geprüft zu werden. Eher nur, ob die entsprechenden Optionen gefüllt sind, aber nicht mit was.

Nutzung

Viele Funktionen davon, vor allem das Caching, ist ja nicht nur für eine installierbare WPA, sondern der Grundzustand vom Service-Worker. Das geht also nicht nur bei einer installierten App, sondern bei jeder Webseite in jedem Browser. Dazu muss man auch nicht offline sein, das geht auch so. Im Grunde könnte man sagen, das ist wie ein H2-Server-Push an Daten, die benötigt werden und schnell geladen werden sollen. Unterschied nur, der Push sendet immer, mit jedem Request, der Service-Worker installiert einmal, dann sind die Daten im Worker-Cache. Und ebenfalls unterschiedlich, der Service-Worker kann weitere Daten nachträglich Cachen.

Und ja, es macht keinen Sinn alles zu cachen. In meinem Fall mit den Unterkünften wären das auch tausende an Bildern. Bei Dir mit der Seide ebenso. Macht keinen Sinn. Ist aber kein Problem, es erwartet auch keiner, dass ein Shop wie vom Otto-Versand offline komplett geht. Zumal wir ja noch immer im online-Modus sind. Da wird dann also gecached, was per PreCache definiert wurde oder eben, was nachträglich angefragt wurde. Es besteht aber immer eine Netzwerkverbindung. Also wenn nicht im Cache, kein Problem, Netzwerk ist ja da.

Der nächste Vorteil ist, dass die Service-Worker nicht im Hauptthread arbeiten und somit die Webseite schneller werden kann. Das schon mal per Cache, ja, aber eben auch durch die Art, wie verarbeitet wird. Normales Javascript und Request, z.B. per Ajax, laufen im Hauptthread, Service-Worker nicht. Man könnte hier z.b. auch was mit Bildergalerien und so machen. Also ein großes Bild ganz normal über die Webseite anfordern, eventuell auch über den Cache vom SW, aber eben die ganzen anderen Bilder im Hintergrund, asynchron, per Worker laden und einbinden. Diese ganzen Requests wären dann vom Hauptthread abgekoppelt und blockieren den nicht. Das sind aber schon erweiterte Funktionen vom Service-Worker.

Auch kann man weitere Dinge abkoppeln oder eben offline nutzbar machen, etwa einen Bestellprozess. Also in den Warenkorb legen, Adressdaten eingeben und Absenden, alles machbar, nur dass die Bestellung selbst dann erst verschickt wird, wenn man wieder online ist.

Oder eben andere Dinge in den Hintergrund auslagern wie Warenbestände live anzeigen. Geht auch per Ajax, aber dann im Hauptthread. Der Service-Worker kann das im Hintergrund synchronisieren. Oder Dinge wie Webtracking. Daten an Matomo oder Analytics senden ist auch Hauptthread, normalerweise. Der Service-Worker kann das auch im Hauptthread machen, sogar sammeln, wenn man offline war und dann alles auf einen Schlag senden, wenn man wieder Internet hat. Das Script von Alex hat das witzigerweise eingebunden, aber per Analytics Script, wobei die Seite ja gar kein Analytics verwendet.

Offline-Nutzung und Fehlerseiten

Wie oben schon geschrieben, hat man Service-Worker und Manifest, dann hat man schon eine PWA. Bringt man dem Service-Worker nun auch noch bei, dass er auf offline-Inhalte reagiert, dann wird sie installierbar. Auf offline zu reagieren bedeutet hier zwei Dinge. Er muss cachen (was schon da ist) und ganz wichtig, es muss eine eigene Fehlermeldung bringen, wenn ein Gerät offline ist und die Seite nicht erreichbar ist. Es darf nicht die default Fehlerseite vom Browser kommen. Im Grunde hat man da also eine Art oflline.html, also was wie eine custom 404-Meldung oder so.

Diesen Wert hat Alex in der PWA z.B. gefüllt, daher akzeptiert, aber sinnlos gefüllt. Denn seine Fehlerseite ist die Startseite. Wenn man also die Startseite online aufruft, dann weiter klickt auf Seite 2 -> Seite 3 -> Seite 4 und dann die Online-Verbindung verliert, dann ist das erst mal gut so. Klickt man dann aber Seite 5 an, dann würde normalerweise die Browser-Fehlermeldung kommen, von wegen "kein Internet". Das darf nicht und ist auch nicht der Fall. Bei Alex kommt aber keine eigene Fehlerseite, sondern die Startseite.

Das mit den vielen Bildern wird eigentlich auch erst ein Problem, wenn man offline ist. Aber wie oben bereits per Otto-Versand erwähnt, das erwartet keiner und muss auch nicht. Es muss nicht die ganze PWA offline verfügbar sein, nur die Grundfunktionen und eben eigene Fehlermeldungen bzw. Manipulationen. Bei Bildern könnte man da also sehr gut eingreifen, wenn nicht im Cache und offline, dass dann nicht die Fehlermeldung vom Browser kommt, sondern eine Ersatzgrafik. Bei Google ist das z.B. dieser kleine Dinosaurier, der dann angezeigt wird, wenn ein Bild oder externes Element wie ein Frame nicht geladen werden konnte.

Im Store einreichen

Und wenn man das ganze dann im Store einreichen will, dann muss eben die Grundanforderung erfüllt sein. Grundsätzlich offline nutzbar, eigene Fehlerseiten, Offline-Modus, Caching.

Ist bei Alex so auch nicht erfüllt, denn wenn man die App installiert, auf der Startseite ist und dann den Flugmodus aktiviert, dann kommt man von der Startseite nicht mehr weg. Ich denke mal "grundsätzlich nutzbar" ist etwas anderes, als nur eine Seite und nichts geht mehr. Einreichen ging dennoch, weil die Optionen eben gefüllt sind. Aber wirklich mal getestet hat die PWA wohl keiner.

Kann von Google indexiert werden

Das zu erwähnen ist eigentlich quatsch, denn das ist ja nur eine normale Webseite und die wird ohnehin indexiert. Als installierbare PWA ist das ja quasi nichts anderes als eine native App mit WebView, also eine Art Iframe in einer App. Eine wirkliche native App ist das ja nicht, nur eine Ansicht der responsive Webseite. Der Unterschied der PWA zur Webseite ist nur, dass wenn man die installiert, die ein eigenes Icon hat, in einem eigenen Fenster läuft, quasi wie eine eigene App, keine URL-Bar hat und so Zeug, das ein Browser eigentlich hat. Sie täuscht also vor, eine native App zu sein, was sie aber nicht ist.

Abschließend: Die oben verlinkte PWA zum Glossar hat das gleiche Problem wie die Koran, eher noch mehr. Dort geht offline nämlich noch nicht mal das CSS bzw. das Script für die Navigation. Als Fehlerseite ebenso die Startseite etc.

Bei der "Glossar" schaut das etwa so aus. Da fehlen also schon mal wichtige PreCache-Dateien. Übermittelt werden nur die Startseite und die Offline-Seite, wobei die Offline-Seite eben die Startseite ist. CSS, JS oder andere wichtige Hauptseiten sind nicht dabei, daher offline überhaupt nicht nutzbar. Naja, "nicht nutzbar" ist zweideutig. Nutzen kann man sie ja, aber nur die aktuelle Seite oder die Startseite.

Es gibt aber keine Vorgabe, was alles automatisch in den Cache soll. Das muss man selbst entscheiden. Es sollte nicht zu wenig sein, aber auch nicht zu viel, zumal es je nach Endgerät ohnehin unterschiedliche Speicherlimits gibt. Da muss man sich also selbst entscheiden, was man macht. Bei meiner Geranien-Seite könnte ich da durchaus alle 40 HTML-Seiten cachen lassen und die beiden CSS und JS, Bilder bleiben weg, nur das Headerbild und Logo übertragen. Wobei das Speicherlimit durchaus ein großer Unterschied der PWA zur nativen APP ist. Die native App hat kein Limit, die PWA schon und das eben unterschiedlich.

Auch beim nachträglichen Cache, wenn man online auf der Seite surft muss man das beachten. HTML-Seiten, kleine Bilder, ok, kann man machen. Aber große Ansichten von Galerien eher nicht. Die gehen dann halt offline nicht, ist so, aber es macht keinen Sinn, den Speicher da mit zig MB großen Bilder vollzustopfen. Das muss man dem Service-Worker aber auch erst mal beibringen. In der Regel, wenn aktiv, cachen die alles, was sie in die Finger bekommen.