Progressive Web App

Seit Anfang September ist dieses Blog eine Progressive Web App. Das bedeutet, dass dieses Blog nun auch offline funktioniert und man es auf dem Smartphone als App hinzufügen kann.

Warum? Lighthouse

Nun, Chrome bietet mit Lighthouse Ratschläge, wie man seine Website verbessern kann. Einer der vier Unterpunkte heißt Progressive Web App und war frustrierend schlecht bewertet. Die folgenden Schritte habe ich also nur für Lighthouse gemacht und es hat sich auf jeden Fall gelohnt:

Lighthouse-Audit Ergebnisse

Wie?

Lighthouse bietet eine Checkliste, auf der neben einigen Punkten, die generell eine gute Idee sind, drei Punkte aufgeführt sind, die erfüllt sein müssen:

  • Site is served over HTTPS
    • Dank Let’s Encrypt ist das kein Problem mehr.
  • The start URL (at least) loads while offline
    • Das ist der aufwendigste Teil. Um dies zu erreichen muss man einen service worker registrieren. Damit der service worker weiß, welche Dateien notwendig sind, benutze ich nach jedem erfolgreichen Build sw-precache mit einer sehr einfachen Konfiguration. Dadurch benötige ich jetzt Node, um das Blog zu erstellen ¯\_(ツ)_/¯
  • Metadata provided for Add to Home screen
    • Damit ist eine manifest.json gemeint. Diese Datei enthält links zu Icons, die als Appsymbol benutzt werden, wenn man die Seite auf Android oder Windows installiert. Und es legt die Farbe der Adressleiste im mobilen Chrome fest. Ein nützlicher Dienst, um ein solches Manifest zu erstellen, ist app-manifest.firebaseapp.com

Was jetzt?

Service Worker ermöglichen Benachrichtigungen von einer Website. Ein natürlicher nächster Schritt wäre es also Benachrichtigungen zu versenden, wenn ein neuer Post online ist. Auf der anderen Seite bin ich selbst immer etwas genervt von Websites, die mich benachrichtigen wollen und der Lighthouse Punktestand ist schon optimal, also wird das wohl nicht passieren.

Push to Publish 2

Nachdem ich vor Kurzem einen euphorischen Eintrag über mein automatisiertes Update dieses Blogs via Travis-CI und GitHub pages geschrieben habe, bin ich jetzt auf eine einfachere Lösung gestoßen.

Alles unter einem Dach bei Netlify Netlify Logo

Es gibt einen einfachen Buildservice, der zwar nicht so flexibel ist wie Travis-CI, aber für dieses Blog ausreicht. Netlify baut die Seite also bei jedem Push in ein beobachtetes GitHub Repository. Nach Konfiguration des DNS und einem weiteren Knopfdruck ist die Seite mit einem SSL Zertifikat von Let’s Encrypt ausgestattet und erreichbar. Also Bonus kann man selbst HTTP-Header bestimmen über eine _headers Datei:

/*
    Strict-Transport-Security: max-age=31536000; includeSubDomains

Also kann man HTTP/2 Server Push ausprobieren, ohne einen Server betreiben zu müssen.

png2vp9

Konvertiere einen Ordner voller .png in ein zur Web-Wiedergabe geeignetes VP9, das von allen wichtigen Browsern unterstützt wird.

ffmpeg -f image2 -pattern_type glob -i "img*.png" -c:v libvpx-vp9 -pass 1  \
    -b:v 1000K -threads 1 -speed 4 -tile-columns 0 -frame-parallel 0 \
    -auto-alt-ref 1 -lag-in-frames 25 -g 9999 -aq-mode 0 -an -f null -


ffmpeg -f image2 -pattern_type glob -i "img*.png" -c:v libvpx-vp9 -pass 2 \
    -b:v 1000K -threads 1 -speed 0 -tile-columns 0 -frame-parallel 0 \
    -auto-alt-ref 1 -lag-in-frames 25 -g 9999 -aq-mode 0 -c:a libopus -b:a 64k \
    -f webm video.webm

Für maximale Kompatibilität kann als Fallback noch ein MP4 erstellt werden.

ffmpeg -an -f image2 -pattern_type glob -i "img*.png" -vcodec libx264 \
    -pix_fmt yuv420p -profile:v baseline -level 3 video.mp4

Einbettung erfolgt mit:

<video>
  <source src="path/to/video.webm" type="video/webm; codecs=vp9,vorbis">
  <source src="path/to/video.mp4" type="video/mp4">
</video>