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.

jsnake

Bisher habe ich immer nur kurze Fragmente in JavaScript geschrieben, die meist nur Gimmicks bezweckten oder Bibliotheken aufrufen. JavaScript ist im Moment möglicherweise die wichtigste Sprache: Schließlich ist sämtlicher clientseitiger Code des Webs JavaScript — und dank Node wohl auch nennenswerte Teile des Servercodes. Zumindest macht man nichts falsch, wenn man sich etwas mit JavaScript vertraut macht. Deshalb ist das neuste — und simpelste — Mitglied meiner Snake Sammlung [1, 2, 3, 4] in JavaScript gehalten.

Ausprobieren kann man es gleich hier:

In der Spielwelt herrschen helikale Randbedingungen, hauptsächlich weil es etwas anderes ist als gewöhnliche periodische Ränder. Außerdem hat es den Vorteil, dass man keinen Pause-Modus braucht, weil diese Randbedingungen dafür sorgen, dass die Schlange sich nicht beißt, wenn man sie einfach geradeaus laufen lässt.

Ich habe gehört, dass JavaScript sich in den letzten Jahren stark weiterentwickelt hat. Tatsächlich scheint mir diese Sprache einige interessante Sprachelemente erhalten zu haben, wie arrow functions x => x*x für lambdas oder den spread operator ... den ich am ehesten mit Pythons splat * vergleichen möchte. Ich will nicht behaupten, dass das folgende kartesische Produkt der beste Code oder leserlich wäre, aber interessant allemal:

let SIZE = 3;
let numbers = [...Array(SIZE).keys()];
let a = [].concat(
    ...numbers.map(
        x => numbers.map(
            y => [x, y]
        )
    )
);
console.log(a);

Anscheinend gibt es mit der nächsten geplanten Version (ES6) noch mehr nette Sprachelemente. Unter anderem Module. Ich bin geradezu sprachlos, dass man bisher keine Sprachunterstützung für die Verteilung des Quellcodes über mehrere Dateien hatte. Anscheinend bin ich noch zu sehr von den Konzepten der „C-artigen“ Sprachen beeinflusst.

Da jsnake nur ein paar Zeilen in einer Datei sind und sich ein ganzes GitHub Repository deshalb nicht lohnt, habe ich es in einen Gist hochgeladen.

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.