Platzhalterbilder

Große Bilder können die Ladezeit von Webseiten dramatisch verschlechtern. Schlimmer als weiße Flächen ist das sprungartige Verschieben des Textes, wenn weiter oben gerade ein Bild fertig geladen wurde. Allerdings müssen Bilder bei immer weiter steigenden Pixeldichten der Anzeigegeräte auch immer hochaufgelöster werden und gleichzeitig über langsame 3G-Verbindungen geladen werden.

Da der Eintrag über Fraktale einige recht große Bilder enthält, habe ich ein Pelican-Plugin geschrieben, das

  1. Vorschau-.jpg erzeugt, die in der Regel kleiner als 1 kB sind,
  2. jedes Bild durch die data-uri des Previews ersetzt und dies verschwommen anzeigt, bis das Originalbild per JavaScript nachgeladen ist.

Das sieht dann etwa so aus:

Glücklicherweise ist es recht einfach mit Python html zu parsen und data-uri zu erzeugen, sodass mein Plugin im Wesentlichen fertig generiertes html nimmt und folgendes tut:

import base64
from bs4 import BeautifulSoup

with open("file.html") as f:
    soup = BeautifulSoup(f, "html.parser")

    for img in soup.find_all("img"):
        thumbnail = create_thumbnail(img)
        b64 = base64.b64encode(open(thumbnail, "rb").read()).decode("utf-8")
        data_uri = f"data:image/jpeg;base64,{b64}"
        # TODO: replace img source by the data-uri

Nachdem alles vorbereitet ist, ist die clientseitige Logik mit ein paar Zeilen JavaScript und CSS recht simpel.

Die Idee ist, dynamisch die voll aufgelösten Bilder per javaScript zu laden und mit dem onLoad Event sichtbar zu machen.

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 auf 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.