Die Vorteile von Progressive Web Apps (PWA) sind vor allem die Schnelligkeit, die Verlässlichkeit und die Möglichkeit der Interaktion. Sie haben auch Dinge wie einen Service Worker.
Service Worker ist eine Technologie, die alle möglichen Teile auch offline verfügbar macht. Es ist ein Client-Side-Proxy, den man nutzen kann, um alles zu cachen und so ein Modell der Seite zu bauen. Das heißt, dass die Seite beim ersten Laden normal (also relativ langsam) lädt. Ab dem zweiten Laden ist dann aber alles gecached und die Seite sollte deutlich schneller laden.
Schnelligkeit ist für jede Website unglaublich wichtig. Denn 53% aller Nutzer verlassen eine Website, wenn sie mehr als 3 Sekunden lädt. Laut einer weiteren Statistik verringern sich pro Sekunde Ladezeit die Konversionen um 7%.
Was kann alles in drei Sekunden passieren? Hier ein Beispiel. Das Smartphone muss in dieser Zeit sehr viele Dinge machen, um die Verbindung zur Website herzustellen. Und darüber hinaus muss die Seite dann noch geladen werden. Wir haben im Chrome Model eine Ladezeit von 1 Sekunde angepeilt, denn in dieser Spanne fühlt es sich für den Nutzer schnell an und er fängt nicht an, an etwas anderes zu denken.
Aktuell ist es aber so, dass mobile Websites im Durchschnitt 19 Sekunden brauchen, um vollständig geladen zu sein. 77% dieser Seiten brauchen dabei mehr als 10 Sekunden. Und nach 10 Sekunden springen Nutzer zu 100% ab und werden die Seite nie sehen.
Die Probleme, die sich uns also im mobilen Web darstellten, waren: Lange Ladezeiten, Inhalte, die nicht responsive sind und Inhalte, die keine gute Nutzererfahrung darstellten. Deswegen haben wir AMP eingeführt.
Mit AMP baut man ein spezielles HTML namens AMP-HTML, das ein paar neue Webkomponenten einbindet und ein paar andere Komponenten ersetzt. Z.B. wird das Image Tag mit dem AMP Image Tag ersetzt, da AMP die Logpipeline prioritisiert und daher jeden Teil einzeln kontrollieren können muss. Man kann also einfach nur eine AMP bauen - oder zur AMP noch eine extra normale Website. Die Plattformen, die AMP unterstützen, zeigen dann die AMP. Alle anderen würden dann die Canonical Seite, also die normale Website, zeigen. Die Seite des AMP Projektes ist z.B. nur auf AMP gebaut und reicht uns völlig aus.
AMP erlaubt es, schnelle und schöne Seiten zu bauen. Und das mit einer immer wachsenden Anzahl an Komponenten.
Der AMP Cache führt dazu, dass die Inhalte mit automatischen Optimierungen (wie z.B. http/2) und Pre-Rendering verbessert wird.
Für AMP ist das Pre-rendering extrem wichtig - denn dies führt zu dem "sofort" Gefühl, das durch AMP ausgelöst wird. AMP weiß, wo jedes Element auf der Seite positioniert ist und kann so den ersten Viewport Pre-Rendern. Dabei wird kein JavaScript von Drittparteien ausgeführt. Dies lässt ein Datenschutzproblem wegfallen, da die Seite den Pre-Load gar nicht mitbekommt.
AMP sind normale HTML Seiten mit CSS. Es gibt kein User-authored JavaScript, sondern custom Elements. Sandboxed AMP iFrames können alles enthalten, wenn man mehr als das braucht. Zudem gibt es die AMP Open Source JavaScript Library. Alles dort ist extrem gut zu cachen, managed das Rendern und optimiert die Performance. Sollte man also AMP oder PWA nutzen?
Was sind die Beschränkungen von AMP? Es gibt kein (User-authored) JavaScript. Es gibt keine custom Service Worker. Man kann keine Push Notifications einbauen. Es gibt kein Web App Manifest. Dies gilt zumindest dann, wenn die Seiten aus dem AMP Cache geliefert werden.
AMP bieten eine sofortige Auslieferung und eine optimierte Findbarkeit. Sie bieten aber keine User Scripts und sind vor allem für statische Inhalte zu gebrauchen. PWA hingegen bieten fortschrittliche Features und funktionieren in einem sehr dynamischen Umfeld. Aber dafür ist die erste Auslieferung langsamer und sie lassen sich nicht so einfach in andere Plattformen einbetten.
Was ist also die ideale Erfahrung, die wir bieten wollen, z.B. im E-Commerce Umfeld? Man startet mit der Suche und klickt auf das Resultat. Dieses lädt sofort, da es auf AMP Basis gebaut wurde. Man sucht sich etwas aus, klickt drauf und landet direkt beim Checkout. Dies ist für uns die ideale Nutzererfahrung. Dies kann man erreichen, indem man AMP als PWA aufbaut.
So ist z.B. auch die Seite des AMP Projektes aufgebaut. Sie haben dann einen Service Worker für Offline / Caching sowie ein Web App Manifest.
Startet man also in der Suche und klickt auf das Ergebnis, öffnet sich eine gecachete Version inline. Der Service Worker läuft also noch nicht. Klickt man dann aber auf einen Link auf der Seite, öffnet sich die nächste Seite auf der origin und der Service Worker ist eingeschaltet. Dann kann man sie zum Himescreen hinzufügen und Push Notifications senden usw.
Die Seite ist dann also zugleich AMP und PWA. So können wir einen Schritt weitergehen und theoretisch Inhalte hinzufügen, die auf AMP eigentlich gar nicht funktionieren. Diese Dinge können dann dynamisch in Service Worker hinzugefügt werden. Das bedeutet, dass die gecachete AMP eine normale AMP ist, die auch den AMP Validator Test besteht. Denn diese kennt das Konzept des Service Worker nicht. Aber sobald man von der ersten Seite weiterklickt, übernimmt der Service Worker und man kann neue Dinge einbauen.
Beim Thema AMP zu PWA gibt es zwei Muster, die ich AMP UP und AMP DOWN nenne. Das eine führt von einer AMP zu einer PWA, das andere bindet AMP in einer PWA ein.
In der ersten Variante erreicht man ganz normal sofort die inline Version per AMP Cache. Dann passiert etwas magisches und man endet in der Instant Progressive Web App. Dies wird z.B. von der Washington Post genutzt, wo der Service Worker vorgeladen und aufgewärmt wird. Klickt man also auf einen Link, ist alles wichtige schon installiert und vorgeladen. Die nächsten Klicks wirken also auch sofort.
Hier geht dann alles schnell, man hat aber zwei verschiedene Strukturen für das Backend. Auf der einen Seite ist das Backend, das viele AMP kreiert und HTML ausspuckt. Auf der anderen Seite das Backend, das PWA kreiert und dabei unter Umständen JSON API ausspielt. Die PWA muss dabei das ganze Templating selbst machen.
AMP sind dabei nicht nur Websites, sondern ein eigenes Datenformat. Man kann sie also auch entsprechend nutzen. So können wir unser Backend deutlich vereinfachen. Es generiert dann AMP, die wiederum in der PWA eingebettet werden und die AMP als Datenquelle nutzen.
Was kann man nun mit iFrames machen, denn diese sind sehr langsam und eigentlich nicht gut für die Nutzererfahrung. Aktuell kann man das via Shadow DOM machen.
Bisher war es so: Wir haben ein Fenster, ein AMP Library Instance per Fenster und ein Dokument. Das macht es für den Browser relativ einfach und übersichtlich.
Jetzt haben wir mehrere Dokumente. Aber weiterhin nur eine AMP Library Instance, die nur einmal für alle Dokumente zusammengestellt wurde. Das Laden von allen weiteren Dokumenten nach dem ersten wird also viel viel schneller von Statten gehen.
Wir haben eine reaktionsbasierte Demo aufgebaut, die ihr euch einmal anschauen könnt. Da findet ihr euch den passenden Code dazu.
Und man kann dieses Muster sehr einfach bauen, denn wir bieten euch Hilfsmittel. Zum Beispiel die AMP-shadow class, mit der man automatisch den Header und Footer für das eingebettete Format erstellen kann. Denn normalerweise gibt es bei AMP Header und Footer, die man aber im eingebetteten Modus nicht zeigen möchte.
Der andere Weg ist, die Dinge, die ihr nicht haben wollt, einfach per Regex loszuwerden und sie im Quellcode mit Dingen zu ersetzen, die nicht AMP kompatibel sind.
Und abschließend gibt es noch etwas, was ich den AMP Konami Code nenne. Das ist das finale Stück, welches das Muster zusammenführt.
Ein Problem haben wir jedoch weiterhin. Ihr kopiert eine URL in die PWA und teilt es dann mit einem Freund - dann öffnet sich bei eurem Freund die PWA ohne den warmen Cache. Denn er kommt ja nicht von der AMP und hat daher nicht den angewärmten AMP Cache.
Was können wir da also tun? Meistens haben wir eine Subdomain für all unsere AMP und eine weitere Subdomain für all unsere PWA.
Aber in diesem Fall nutzen wir einfach denselben URL Space. Das führt dazu, dass der Service Worker dann die Anfrage abfängt und schlussendlich, da wir auf derselben URL sind, einfach die PWA ausspielt.
Hier ist ein Beispiel, wie man das machen kann. Im Service Worker hat man ein "Fetch" Event. Interessant ist dabei, dass das "Fetch" Event alle eingehenden und ausgehenden Anfragen auf diesem Client Side Proxy Worker behandelt und damit auch die Navigation mit einschließt. Ist die Anfrage also eine Navigation, antworten wir mit einer komplett anderen Seite, nämlich der PWA, und fangen dann sofort damit an, die Request URL zu fetchen. So geht dann alles noch schneller. Man hat dann eine AMP, eine PWA und nur eine Anfrage.
Das beste ist, dass es damit progressiv erweitert wird. Ohne den Service Worker geht man nur zur AMP und hat eine ziemlich schnelle Erfahrung. Ist der Service Worker aber erhältlich und installiert, erhält man die PWA zusätzlich zur AMP.
Wir haben auch noch etwas namens Fallback URL Rewriting. Dies ist zum Beispiel für Safari wichtig, wo Service Worker noch nicht funktionieren. Das heißt, dass man dort fast immer AMP sehen würde. Fallback URL Rewriting erlaubt dann, URLs umzuschreiben, wenn es keinen Service Worker gibt. Dann kann man trotzdem auf einer Seite enden, die weitere Funktionalitäten hat und damit fast wie eine PWA ist (nur ohne den Service Worker).
Von hier an wird eine Demo gezeigt, die sich jeder ab Minute
25:12 selbst anschauen kann - alternativ können die in der Folie gezeigten URLs genutzt werden.
