Ein Anfängerleitfaden für progressive Web-Apps

Progressive Web-Apps könnten das nächste große Ding für das mobile Web werden. Ursprünglich von Google im Jahr 2015 vorgeschlagen, haben sie aufgrund der relativ einfachen Entwicklung und der fast sofortigen Vorteile für die Benutzererfahrung der Anwendung bereits viel Aufmerksamkeit auf sich gezogen.

Weiterführende Literatur zu SmashingMag:

• Die Bausteine ​​von Progressive Web Apps
• Conversational Design Essentials: Tipps zum Erstellen eines Chatbots
• Erstellen einer erstklassigen App, die Ihre Website nutzt
• Erstellen einer vollständigen Web-App in Foundation for Apps

Eine progressive Webanwendung nutzt die neuesten Technologien, um das Beste aus Web- und mobilen Anwendungen zu kombinieren. Stellen Sie es sich als eine Website vor, die mit Webtechnologien erstellt wurde, sich aber wie eine App verhält und anfühlt. Jüngste Fortschritte im Browser und in der Verfügbarkeit von Servicemitarbeitern sowie in den Cache- und Push-APIs haben es Webentwicklern ermöglicht, Benutzern zu ermöglichen, Web-Apps auf ihrem Startbildschirm zu installieren, Push-Benachrichtigungen zu erhalten und sogar offline zu arbeiten.

Progressive Web-Apps nutzen das viel größere Web-Ökosystem, die Plugins und die Community sowie die relativ einfache Bereitstellung und Wartung einer Website im Vergleich zu einer nativen Anwendung in den jeweiligen App-Stores. Diejenigen unter Ihnen, die sowohl für Mobilgeräte als auch für das Web entwickeln, werden es zu schätzen wissen, dass eine Website in kürzerer Zeit erstellt werden kann, dass eine API nicht mit Abwärtskompatibilität gepflegt werden muss (alle Benutzer führen dieselbe Version Ihrer Website aus). Code, im Gegensatz zur Versionsfragmentierung nativer Apps) und dass die App im Allgemeinen einfacher bereitzustellen und zu warten ist .

Warum progressive Web-Apps?

Eine Studie hat gezeigt, dass eine App im Durchschnitt 20 % ihrer Nutzer für jeden Schritt zwischen dem ersten Kontakt des Nutzers mit der App und dem Beginn der Nutzung der App durch den Nutzer verliert. Ein Nutzer muss die App zunächst in einem App Store finden, herunterladen, installieren und schließlich öffnen. Wenn ein Benutzer Ihre progressive Web-App findet, kann er sie sofort verwenden, wodurch unnötige Download- und Installationsphasen entfallen. Und wenn der Benutzer zur App zurückkehrt, wird er aufgefordert, die App zu installieren und auf ein Vollbilderlebnis zu aktualisieren.

Eine native App ist jedoch definitiv nicht alles schlecht. Mobile Anwendungen mit Push-Benachrichtigungen erreichen bis zu dreimal mehr Retention als ihre Pendants ohne Push, und ein Benutzer öffnet eine mobile Anwendung dreimal häufiger als eine Website. Darüber hinaus verbraucht eine gut gestaltete mobile Anwendung weniger Daten und ist viel schneller, da sich einige Ressourcen auf dem Gerät befinden.

Eine progressive Webanwendung nutzt die Eigenschaften einer mobilen Anwendung, was zu einer verbesserten Benutzerbindung und -leistung führt, ohne die Komplikationen, die mit der Wartung einer mobilen Anwendung verbunden sind.

Anwendungsfälle

Wann sollten Sie eine progressive Web-App erstellen? Native wird normalerweise für Anwendungen empfohlen, zu denen Sie erwarten, dass Benutzer häufig zurückkehren, und eine progressive Web-App ist nicht anders. Flipkart verwendet eine progressive Web-App für seine beliebte E-Commerce-Plattform Flipkart Lite, und die SBB verwendet eine progressive Web-App für ihren Online-Check-in-Prozess, mit der Benutzer ohne Internetverbindung auf ihre Tickets zugreifen können.

Bei der Beurteilung, ob Ihre nächste Anwendung eine progressive Web-App, eine Website oder eine native mobile Anwendung sein soll, identifizieren Sie zunächst Ihre Benutzer und die wichtigsten Benutzeraktionen. Da eine progressive Webanwendung „progressiv“ ist, funktioniert sie in allen Browsern, und das Erlebnis wird immer dann verbessert, wenn der Browser des Benutzers mit neuen und verbesserten Funktionen und APIs aktualisiert wird.

Daher gibt es bei der Benutzererfahrung mit einer progressiven Web-App im Vergleich zu einer traditionellen Website keine Kompromisse; Sie müssen jedoch möglicherweise entscheiden, welche Funktionalität offline unterstützt werden soll, und Sie müssen die Navigation erleichtern (denken Sie daran, dass der Benutzer im eigenständigen Modus keinen Zugriff auf die Zurück-Schaltfläche hat). Wenn Ihre Website bereits über eine anwendungsähnliche Oberfläche verfügt, wird sie durch die Anwendung der Konzepte progressiver Web-Apps nur noch besser .

Wenn bestimmte Funktionen für kritische Benutzeraktionen erforderlich sind, aber aufgrund fehlender Cross-Browser-Unterstützung noch nicht verfügbar sind, ist eine native mobile Anwendung möglicherweise die bessere Option, die allen Benutzern die gleiche Erfahrung garantiert.

Merkmale einer progressiven Web-App

Bevor wir uns mit dem Code befassen, ist es wichtig zu verstehen, dass progressive Web-Apps die folgenden Merkmale aufweisen:

• Progressiv . Per Definition muss eine progressive Web-App auf jedem Gerät funktionieren und sich progressiv verbessern, indem sie alle Funktionen nutzt, die auf dem Gerät und Browser des Benutzers verfügbar sind.
• Auffindbar . Da es sich bei einer progressiven Web-App um eine Website handelt, sollte sie in Suchmaschinen auffindbar sein. Dies ist ein großer Vorteil gegenüber nativen Anwendungen, die bei der Durchsuchbarkeit immer noch hinter Websites zurückbleiben.
• Verlinkbar . Als weiteres von Websites geerbtes Merkmal sollte eine gut gestaltete Website den URI verwenden, um den aktuellen Status der Anwendung anzuzeigen. Dadurch kann die Web-App ihren Zustand beibehalten oder neu laden, wenn der Benutzer die URL der App mit einem Lesezeichen markiert oder teilt.
• Ansprechbar . Die Benutzeroberfläche einer progressiven Web-App muss zum Formfaktor und zur Bildschirmgröße des Geräts passen.
• App-ähnlich . Eine progressive Web-App sollte wie eine native App aussehen und auf dem Anwendungs-Shell-Modell mit minimalen Seitenaktualisierungen aufgebaut sein.
• Konnektivitätsunabhängig . Es sollte in Bereichen mit geringer Konnektivität oder offline funktionieren (unser Lieblingsmerkmal).
• Wiedereinschaltbar . Benutzer mobiler Apps verwenden ihre Apps eher wieder, und progressive Web-Apps sollen die gleichen Ziele durch Funktionen wie Push-Benachrichtigungen erreichen.
• Installierbar . Eine progressive Web-App kann auf dem Startbildschirm des Geräts installiert werden und ist so jederzeit verfügbar.
• Frisch . Wenn neue Inhalte veröffentlicht werden und der Benutzer mit dem Internet verbunden ist, sollten diese Inhalte in der App verfügbar gemacht werden.
• Sicher . Da eine progressive Web-App eine intimere Benutzererfahrung bietet und alle Netzwerkanfragen von Servicemitarbeitern abgefangen werden können, ist es zwingend erforderlich, dass die App über HTTPS gehostet wird, um Man-in-the-Middle-Angriffe zu verhindern.

Lassen Sie uns codieren!

Unsere erste progressive Web-App, Sky High, wird den Ankunftsplan eines Flughafens simulieren. Wenn der Benutzer zum ersten Mal auf unsere Web-App zugreift, möchten wir ihm eine Liste der bevorstehenden Flüge zeigen, die von einer API abgerufen werden. Wenn der Benutzer keine Internetverbindung hat und die Web-App neu lädt, möchten wir ihm den Flugplan so anzeigen, wie er zuletzt mit einer Verbindung heruntergeladen wurde.

Die Grundlagen

Das erste Merkmal einer progressiven Web-App ist, dass sie auf allen Geräten funktionieren und auf Geräten und Browsern, die dies zulassen, verbessert werden muss. Daher haben wir unsere Website mit herkömmlichem HTML5 und mit JavaScript erstellt, das den Abruf von Daten von einer Schein-API simuliert. In der gesamten Anwendung verwenden wir kleine Teile von Knockout, um unsere Model-View-ViewModel (MVVM)-Bindungen zu handhaben – ein leichtgewichtiges JavaScript-Framework, mit dem wir unsere JavaScript-Modelle an unsere HTML-Ansichten binden können. Wir haben uns für Knockout entschieden, weil es relativ einfach zu verstehen ist und den Code nicht überladen; Sie können dies jedoch durch ein beliebiges anderes Framework wie React oder AngularJS ersetzen.

Unsere Website folgt den Material Design Guidelines von Google, einer Reihe von Prinzipien, die Design und Interaktion leiten. Das Materialdesign dient nicht nur als einheitlicher Standard für Anwendungen und Geräte, sondern verleiht dem Design auch Bedeutung. Wir haben Materialdesign für die Ankunftsansicht von Sky High verwendet, um unserer progressiven Web-App das Aussehen und Verhalten einer nativen App zu verleihen.

Schließlich haben wir unsere App getestet, um sicherzustellen, dass sie ruckelfrei ist und dass das Scrollen seidenweich ist. Es hat sich gezeigt, dass Jank-freies Rendering die Benutzerinteraktion verbessert. Streben Sie ein Rendering mit 60 Bildern pro Sekunde an.

Für diese Demo rufen wir anstelle einer echten API eine statische JSON-Datei ab. Dies nur, um die Dinge einfach zu halten. In der realen Welt würden Sie eine API abfragen oder WebSockets verwenden.

index.html

 <!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Sky-High Airport Arrivals</title> <link async rel="stylesheet" href="./css/style.css"> <link href="https://fonts.googleapis.com/css?family=Roboto:300,600,300italic,600italic" rel="stylesheet" type="text/css"> </head> <body> <header> <div class="content"> <h3>Arrivals</h3> </div> </header> <div class="container"> <div class="content"> <ul class="arrivals-list" data-bind="foreach: arrivals"> <li class="item"> <span class="title" data-bind="html: title"></span> <span class="status" data-bind="html: status"></span> <span class="time" data-bind="html: time"></span> </li> </ul> </div> </div> <script src="./js/build/vendor.min.js"></script> <script src="./js/build/script.min.js"></script> </body> </html>
<!DOCTYPE html> <html lang="en"> <head> <meta charset="utf-8"> <meta name="viewport" content="width=device-width, initial-scale=1.0"> <title>Sky-High Airport Arrivals</title> <link async rel="stylesheet" href="./css/style.css"> <link href="https://fonts.googleapis.com/css?family=Roboto:300,600,300italic,600italic" rel="stylesheet" type="text/css"> </head> <body> <header> <div class="content"> <h3>Arrivals</h3> </div> </header> <div class="container"> <div class="content"> <ul class="arrivals-list" data-bind="foreach: arrivals"> <li class="item"> <span class="title" data-bind="html: title"></span> <span class="status" data-bind="html: status"></span> <span class="time" data-bind="html: time"></span> </li> </ul> </div> </div> <script src="./js/build/vendor.min.js"></script> <script src="./js/build/script.min.js"></script> </body> </html>

Die Datei index.html ist relativ Standard. Wir haben eine HTML-Liste erstellt und die arrivals unserer Ansichtsmodell-Eigenschaften mithilfe von Knockout über das Attribut data-bind=“foreach: arrivals” daran gebunden. Die page.js arrivals unten deklariert und im Page -Modul bereitgestellt. Auf unserer HTML-Seite haben wir für jeden Artikel im arrivals -Array die Eigenschaften title , status und time an die HTML-Ansicht gebunden.

page.js

 (var Page = (function() { // declare the view model used within the page function ViewModel() { var self = this; self.arrivals = ko.observableArray([]); } // expose the view model through the Page module return { vm: new ViewModel(), hideOfflineWarning: function() { // enable the live data document.querySelector(".arrivals-list").classList.remove('loading') // remove the offline message document.getElementById("offline").remove(); // load the live data }, showOfflineWarning: function() { // disable the live data document.querySelector(".arrivals-list").classList.add('loading') // load html template informing the user they are offline var request = new XMLHttpRequest(); request.open('GET', './offline.html', true); request.onload = function() { if (request.status === 200) { // success // create offline element with HTML loaded from offline.html template var offlineMessageElement = document.createElement("div"); offlineMessageElement.setAttribute("id", "offline"); offlineMessageElement.innerHTML = request.responseText; document.getElementById("main").appendChild(offlineMessageElement); } else { // error retrieving file console.warn('Error retrieving offline.html'); } }; request.onerror = function() { // network errors console.error('Connection error'); }; request.send(); } } })();

Diese page.js -Datei macht das Page -Modul verfügbar, das unser ViewModel vm und zwei Funktionen enthält, hideOfflineWarning und showOfflineWarning . Das Ansichtsmodell ViewModel ist ein einfaches JavaScript-Literal, das in der gesamten Anwendung verwendet wird. Die Eigenschaft, die auf dem arrivals ankommt, ist observableArray von Knockout, das unseren HTML-Code automatisch an ein JavaScript-Array bindet, sodass wir Elemente in JavaScript in unser Array pushen und platzieren und den HTML-Code der Seite automatisch aktualisieren können.

Die Funktionen hideOfflineWarning und showOfflineWarning ermöglichen es dem Rest unserer Anwendung, diese Funktionen aufzurufen, um die Benutzeroberfläche der Seite zu aktualisieren, die anzeigt, ob wir online verbunden sind. Die showOfflineWarning fügt unserem HTML arrivals-list eine loading hinzu, um die Liste auszublenden, und ruft dann die HTML-Datei offline.html über XHR ab. Unter der Annahme, dass die Datei erfolgreich abgerufen wurde ( response.status === 200 ), hängen wir dies an unseren HTML-Code an. Wenn wir keine Servicemitarbeiter verwenden und der Benutzer nicht mit dem Internet verbunden ist, wäre es natürlich nicht möglich, offline.html , und der Benutzer würde die Offline-Seite des Browsers sehen.

Die Geschäftslogik, aus der wir die Daten von unserer API abrufen und an unsere Ansichtsmodelle und Ansichten binden, befindet sich in arrivals.js und ist eine Standard-MVVM-Funktionalität mit Knockout. In der Datei arrivals.js initialisieren wir einfach die Dienste und Ansichtsmodelle, die wir in der gesamten Anwendung verwenden werden, und stellen eine Funktion – Arrivals.loadData() – bereit, die die Daten abruft und an das Ansichtsmodell bindet.

Web-App-Manifest

Lassen Sie uns unsere Web-App App-ähnlicher gestalten. Eine Web-App-Manifestdatei ist eine einfache JSON-Datei, die der Spezifikation des W3C folgt. Damit ist es möglich, die Web-App im Vollbildmodus als eigenständige Anwendung auszuführen, ein Symbol zuzuweisen, das angezeigt wird, wenn die Anwendung auf dem Gerät installiert wird, und der App ein Thema und eine Hintergrundfarbe zuzuweisen. Darüber hinaus schlägt Chrome auf Android dem Benutzer über ein Web-App-Installationsbanner proaktiv vor, die Web-App zu installieren. Um die Installationsaufforderung anzuzeigen, muss Ihre Web-App:

• über eine gültige Web-App-Manifestdatei verfügen,
• über HTTPS bereitgestellt werden,
• einen gültigen Servicemitarbeiter registriert haben,
• wurden zweimal besucht, wobei zwischen jedem Besuch mindestens fünf Minuten lagen.

manifest.json

 { "short_name": "Arrivals", "name": "Arrivals at Sky High", "description": "Progressive web application demonstration", "icons": [ { "src": "launcher-icon.png", "sizes": "48x48", "type": "image/png" }, { "src": "launcher-icon-96.png", "sizes": "96x96", "type": "image/png" }, { "src": "launcher-icon-144.png", "sizes": "144x144", "type": "image/png" }, { "src": "launcher-icon-192.png", "sizes": "192x192", "type": "image/png" }, { "src": "launcher-icon-256.png", "sizes": "256x256", "type": "image/png" } ], "start_url": "./?utm_source=web_app_manifest", "display": "standalone", "orientation": "portrait", "theme_color": "#29BDBB", "background_color": "#29BDBB" }

Lassen Sie uns diese Manifestdatei aufschlüsseln:

• short_name ist ein für Menschen lesbarer Name für die Anwendung. In Chrome für Android ist dies auch der Name, der das Symbol auf dem Startbildschirm begleitet.
• name ist auch ein für Menschen lesbarer Name für die Anwendung und definiert, wie die Anwendung aufgelistet wird.
• description bietet eine allgemeine Beschreibung der Webanwendung.
• icons definiert eine Reihe von Bildern unterschiedlicher Größe, die als Symbolsatz der Anwendung dienen. In Chrome für Android wird das Symbol auf dem Begrüßungsbildschirm, auf dem Startbildschirm und im Aufgabenumschalter verwendet.
• start_url ist die Start-URL der Anwendung.
• display definiert den Standardanzeigemodus für die Webanwendung: fullscreen , standalone , minimal-ui oder browser .
• orientation definiert die Standardausrichtung für die Webanwendung: portrait oder landscape .
• theme_color ist die standardmäßige Designfarbe für die Anwendung. Auf Android wird dies auch verwendet, um die Statusleiste einzufärben.
• background_color definiert die Hintergrundfarbe der Webanwendung. In Chrome definiert es auch die Hintergrundfarbe des Begrüßungsbildschirms.
• related_applications ist in unserem Beispiel nicht implementiert, wird aber verwendet, um native Anwendungsalternativen in den verschiedenen App-Stores anzugeben.

Fügen Sie die manifest.json -Referenz zum head -Tag der index.html -Datei hinzu:

 <link rel="manifest" href="./manifest.json">

Sobald ein Benutzer die Web-App zu seinem Startbildschirm hinzugefügt hat, kann er sofort von seinem Gerät aus wieder mit Ihrer Anwendung interagieren, ohne den Browser direkt öffnen zu müssen. Sie können sehen, dass dies viel mehr als ein Web-Lesezeichen ist.

Zum Startbildschirm in Chrome für Android vom Smashing Magazine auf Vimeo hinzufügen.

Servicemitarbeiter

Einer der aufregenderen Aspekte von progressiven Web-Apps ist, dass sie offline arbeiten können. Mit Service Workern ist es möglich, Daten anzuzeigen, die in früheren Sitzungen der App abgerufen wurden (mithilfe von IndexedDB) oder alternativ die Anwendungs-Shell anzuzeigen und den Benutzer darüber zu informieren, dass er nicht mit dem Internet verbunden ist (der Ansatz, den wir haben aufgenommen in dieser Demo). Sobald sich der Benutzer wieder verbindet, können wir die neuesten Daten vom Server abrufen.

All dies ist durch Service Worker möglich, bei denen es sich um ereignisgesteuerte Skripts (in JavaScript geschrieben) handelt, die Zugriff auf domänenweite Ereignisse haben, einschließlich Netzwerkabrufen. Mit ihnen können wir alle statischen Ressourcen zwischenspeichern, was die Netzwerkanforderungen drastisch reduzieren und auch die Leistung erheblich verbessern könnte.

Anwendungs-Shell

Die Anwendungs-Shell ist das Minimum an HTML, CSS und JavaScript, das für eine Benutzeroberfläche erforderlich ist. Eine native mobile Anwendung enthält die Anwendungs-Shell als Teil ihrer verteilbaren Datei, wohingegen Websites diese normalerweise über das Netzwerk anfordern. Progressive Webanwendungen schließen diese Lücke, indem sie die Ressourcen und Assets der Anwendungs-Shell im Cache des Browsers platzieren. In unserer Sky High-Anwendung können wir sehen, dass unsere Anwendungs-Shell aus der oberen Kopfleiste, den Schriftarten und jeglichem CSS besteht, das erforderlich ist, um diese elegant darzustellen.

Um mit Service Workern zu beginnen, müssen wir zuerst die JavaScript-Datei unseres Service Workers, sw.js , erstellen, die sich im Stammverzeichnis befindet.

sw.js

 // Use a cacheName for cache versioning var cacheName = 'v1:static'; // During the installation phase, you'll usually want to cache static assets. self.addEventListener('install', function(e) { // Once the service worker is installed, go ahead and fetch the resources to make this work offline. e.waitUntil( caches.open(cacheName).then(function(cache) { return cache.addAll([ './', './css/style.css', './js/build/script.min.js', './js/build/vendor.min.js', './css/fonts/roboto.woff', './offline.html' ]).then(function() { self.skipWaiting(); }); }) ); }); // when the browser fetches a URL… self.addEventListener('fetch', function(event) { // … either respond with the cached object or go ahead and fetch the actual URL event.respondWith( caches.match(event.request).then(function(response) { if (response) { // retrieve from cache return response; } // fetch as normal return fetch(event.request); }) ); });

Schauen wir uns unseren Servicemitarbeiter genauer an. Zuerst setzen wir eine cacheName Variable. Dies wird verwendet, um festzustellen, ob Änderungen an unseren zwischengespeicherten Assets vorgenommen wurden. In diesem Beispiel verwenden wir einen statischen Namen, was bedeutet, dass sich unsere Assets nicht ändern oder aktualisiert werden müssen.

 self.addEventListener('install', function(e) { // declare which assets to cache }

Das install wird während der Installationsphase des Service Workers ausgelöst und wird nur einmal ausgelöst, wenn der Service Worker bereits installiert ist. Daher wird durch das Aktualisieren der Seite die Installationsphase nicht erneut ausgelöst. Während der Installationsphase können wir angeben, welche Assets zwischengespeichert werden. In unserem obigen Beispiel cachen wir eine CSS-Datei, zwei JavaScript-Dateien, unsere Fonts-Datei, unsere Offline-HTML-Vorlage und natürlich den Anwendungsstamm. self.skipWaiting() zwingt den wartenden Service Worker, aktiv zu werden.

Bisher haben wir unseren Service Worker deklariert, aber bevor wir sehen, dass er in Kraft tritt, müssen wir ihn in unserem JavaScript referenzieren. In unserer Anwendung registrieren wir es in main.js

 // Register the service worker if available. if ('serviceWorker' in navigator) { navigator.serviceWorker.register('./sw.js').then(function(reg) { console.log('Successfully registered service worker', reg); }).catch(function(err) { console.warn('Error whilst registering service worker', err); }); } window.addEventListener('online', function(e) { // Resync data with server. console.log("You are online"); Page.hideOfflineWarning(); Arrivals.loadData(); }, false); window.addEventListener('offline', function(e) { // Queue up events for server. console.log("You are offline"); Page.showOfflineWarning(); }, false); // Check if the user is connected. if (navigator.onLine) { Arrivals.loadData(); } else { // Show offline message Page.showOfflineWarning(); } // Set Knockout view model bindings. ko.applyBindings(Page.vm);

Wir haben auch zwei Ereignis-Listener hinzugefügt, um zu überprüfen, ob sich der Status der Sitzung von online zu offline oder umgekehrt geändert hat. Die Ereignishandler rufen dann die verschiedenen Funktionen auf, um die Daten über Arrivals.loadData() abzurufen und die Offline-Nachricht über Page.showOfflineWarning bzw. Page.hideOfflineWarning zu aktivieren oder zu deaktivieren. Unsere Anwendung prüft auch, ob der Benutzer gerade online ist, indem er navigator.onLine verwendet, und ruft entweder die Daten ab oder zeigt die Offline-Warnung entsprechend an. Und in der letzten Zeile von main.js wenden wir die Knockout-Bindungen auf unsere View Model Page.vm .

Wenn wir unsere Anwendung zum ersten Mal laden (mit Chrome Developer Tools), sehen wir nichts Neues. Beim erneuten Laden sehen wir jedoch, dass eine Reihe von Netzwerkressourcen vom Service Worker abgerufen wurden. Dies ist unsere Anwendungs-Shell.

Offline-Test

Ein Benutzer, der die Anwendung ohne Internetverbindung ausführt (vorausgesetzt, er war bereits auf der Seite), führt einfach dazu, dass die Anwendungs-Shell und die Offline-Warnung angezeigt werden – eine Verbesserung gegenüber dem umherstreifenden T-Rex von Chrome. Sobald der Benutzer eine Netzwerkverbindung hergestellt hat, deaktivieren wir die Warnung und rufen die neuesten Daten ab.

The Guardian verfolgt einen besonders interessanten Ansatz, wenn Offline-Benutzer auf seine Website zugreifen, und bietet ein Kreuzworträtsel:

Mitteilungen

Push-Benachrichtigungen ermöglichen es Benutzern, sich für zeitnahe Updates von Anwendungen zu entscheiden, denen sie vertrauen, und helfen ihnen, sich erneut mit den Apps zu beschäftigen. Push-Benachrichtigungen im Web ermöglichen es Ihnen, mit Ihrem Publikum zu interagieren, selbst wenn der Browser geschlossen ist.

Die Push-API wird in Chrome, Opera und Samsungs Browsern unterstützt und befindet sich in Firefox und Microsoft Edge in der Entwicklung. Leider gibt es keinen Hinweis darauf, dass die Funktion in Safari implementiert wird.

Leistung

Einer der einfachsten Gewinne bei Servicemitarbeitern ist, dass wir die Leistung mit wenig bis gar keinem Aufwand verbessern können. Vergleich unserer Website mit sich selbst, bevor Servicemitarbeiter implementiert wurden, bevor wir beim Laden der Seite über 200 KB abgerufen haben; das ist jetzt auf 13 KB reduziert. In einem normalen 3G-Netzwerk hätte das Laden der Seite 3,5 Sekunden gedauert; jetzt dauert es 500 Millisekunden.

Diese Leistungsverbesserungen sind drastisch, da die Anwendung selbst sehr klein ist und über eine eingeschränkte Funktionalität verfügt. Dennoch ist es durch die richtige Verwendung von Caching möglich, die Leistung und die wahrgenommene Leistung erheblich zu verbessern, insbesondere für Benutzer an Orten mit geringer Konnektivität.

Leuchtturm

Das Chrome-Team von Google hat ein Tool zum Testen von progressiven Web-Apps zusammengestellt. Lighthouse läuft in Node.js oder als Chrome-Plugin und ist auch auf GitHub zu finden.

Um einen Lighthouse-Test durchzuführen, muss Ihre Website online verfügbar sein, was bedeutet, dass Sie nicht auf localhost testen können.

Laden Sie zunächst das npm-Paket herunter:

 npm install -g GoogleChrome/lighthouse

Führen Sie nach der Installation Chrome (ab Version 52) aus:

 npm explore -g lighthouse -- npm run chrome lighthouse https://incredibleweb.github.io/pwa-tutorial/

Die Ausgabe des Lighthouse-Laufs wird in der Befehlszeile angezeigt und bewertet Ihre Website gemäß den von Ihnen implementierten progressiven Web-App-Funktionen und -Eigenschaften – zum Beispiel, ob Sie eine manifest.json -Datei verwenden oder ob Ihre Seite offline verfügbar ist .

Fazit

Dieser Artikel ist lediglich ein Appetitanreger für progressive Web-Apps. Wir könnten noch viel mehr tun, um das App-ähnliche Erlebnis zu schaffen, nach dem Benutzer suchen, sei es durch die Unterstützung von Push-Benachrichtigungen mit der Push-API, die erneute Aktivierung der App oder die Verwendung von IndexedDB und Hintergrundsynchronisierung zur Verbesserung des Offline-Erlebnisses.

Cross-Browser-Unterstützung

Progressive Web-Apps befinden sich noch in den Anfängen, und die browserübergreifende Unterstützung ist noch begrenzt, insbesondere in Safari und Edge. Microsoft unterstützt jedoch offen progressive Web-Apps und sollte bis Ende des Jahres weitere Funktionen implementieren.

• Service Worker und Cache-API . Unterstützt in Chrome, Firefox, Opera und dem Samsung-Browser. In Entwicklung in Microsoft Edge, voraussichtlich Ende 2016 verfügbar. Für Safari in Erwägung gezogen.
• Zum Startbildschirm hinzufügen . Unterstützt in Chrome, Firefox, Opera, Android Browser und Samsungs Browser. Microsoft scheint darauf hinzudeuten, dass progressive Web-Apps als Store-Einträge verfügbar sein werden. Keine Pläne für Safari bis jetzt.
• Push-API . Wird hauptsächlich von Chrome, Firefox, Opera und dem Samsung-Browser unterstützt. In Entwicklung in Microsoft Edge. Keine Pläne für Safari bis jetzt.

Wenn mehr Entwickler die Funktionen progressiver Web-Apps nutzen – die relativ einfach zu implementieren sind und sofortige Belohnungen bieten –, werden Benutzer diese Web-Apps lieber in unterstützten Browsern nutzen und hoffentlich die anderen Browser-Anbieter davon überzeugen, sich anzupassen.

Quellcode

Der gesamte Quellcode für dieses Tutorial ist in einem Github-Repository verfügbar, und die Demo ist auf GitHub-Seiten verfügbar.