Ich bin letzte Tage auf das Konzept von Stone Websites gestoßen, und zwar dank diesem Blogpost, der das Thema erläutert. Beide beziehen sich auf den Artikel „This Website is designed to last“. Es dreht sich also um die Langlebigkeit von Websites.
Ich werde das hier nicht alles wiederholen, lest am besten die verlinkten Posts selber durch. Ich mache hier nur eine Schnellzusammenfassung und gebe meinen Senf dazu. Es geht darum, dass Websites dauerhaft sein sollen, damit man auch Jahrzehnte später noch die Informationen darin lesen kann. Man hat damit also „Stone Websites“, das digitale Äquivalent davon, Texte in Stein zu meißeln.
Dafür hat Caio Lente ein paar Regeln aufgestellt:
- Use pure HTML/CSS.
- Don’t minimize HTML.
- Prefer one page over many.
- Stop hotlinking.
- Use native fonts.
- Compress your images.
- Reduce the risk of rotten links.
Use pure HTML/CSS
Kein Javascript, kein Webassembly, keine dynamisch geladenen Inhalte. Keine Abhängigkeiten. Das ist nicht immer machbar, aber wo es machbar ist, ist es gut. Mein Blog benutzt auch kein Javascript. Ich würde die Regel erweitern: Wenn Javascript, dann sollte es die Funktionalität der Website nicht beeinträchtigen, wenn es fehlt. Höchstens sollte dann ein paar Komfortfunktionen wegfallen. Ich habe mich schon vor 15 Jahren über Javascriptabhängigkeit aufgeregt. Ich habe seitdem beruflich gezwungenermaßen an Single-Page-Apps gearbeitet, die ohne Javascript nicht einmal eine Überschrift anzeigen konnten. Aber das ist eine andere Geschichte.
Wichtig ist: Je weniger komplex eine Website ist, desto einfacher wird es, sie über einen langen Zeitraum zu erhalten. In diesem Blog hatte ich zum Beispiel schon nach ein paar Jahren Ärger mit Ruby on Rails, während mein static site generator seit Jahren zuverlässig läuft und mein Blog weiter bestehen kann, selbst wenn der Generator über Nacht aufhören würde zu arbeiten.
Don't minimize HTML
Die Idee ist, dass minimalisiertes HTML (ohne technisch überflüssige Leerzeichen wie z.B. Einrückungen) schwieriger zu lesen, schwieriger zu debuggen und damit schwieriger zu warten ist, aber (wenn es auch noch komprimiert wird), kaum kleiner ist.
Ich sehe den Punkt. Aber als Gegenargument: Es ist wirklich leicht, einen HTML-Formatter zu finden (oder zu schreiben), besonders, wenn man gültiges HTML geschrieben hat. Man kann also jedes minifizierte HTML ohne Probleme wieder lesbarer machen.
In diesem Blog erzeugt die HTML-Template-Bibliothek automatisch HTML mit minimalen Leerzeichen. Einzig der Markdown-Renderer fügt regelmäßig Zeilenumbrüche (aber auch keine Einrückungen ein). Ich sehe da kein großes Problem.
Wenn ich mir mein CSS anschaue… Das ist eine andere Sache. Ich nutze derzeit SCSS, auch wenn ich es für diese Seite eigentlich nicht brauche. Das ist natürlich auch eine Abhängigkeit, aber es hat auch den Nebeneffekt, dass mein CSS minifiziert wird, und ich als Kompressionsfetischist will bei meinen knapp 2.2 kiB (686 Byte Brotli-komprimiert) jedes Byte einsparen!
Prefer one page over many
Es geht darum, dass eine Seite leichter zu warten ist als mehrere, und man leicht die Links dazwischen zerstört. Mein Blog hält diese Regel absolut nicht ein. Kategorienseiten, Tag-Seiten, Archivseiten, jeder Blogpost hat noch eine Seite, und es gibt die Seiten für die Quotes… Dank meines statis site generators alles gut managebar, aber sollte der einmal aufgeben (z.B. weil die Abhängigkeiten offline genommen werden), hätte ich ein Problem.
Stop Hotlinking
Hotlinking, also direktes Einbinden von Inhalten anderer Seiten (Bilder, Style-Dateien, Schriftarten, Javascript, you name it) sorgt dafür, dass deine Seite kaputt geht, wenn die Seite, auf die du verlinkst nicht mehr existiert oder ihre URLs ändert. Außerdem ist es ein potentielles Sicherheitsrisiko, wenn ein Angreifer eine der toten Links übernimmt und darüber z.B. gefährliches Javascript in deine Seite einschleust.
Dieses Blog hat kein Hotlinking. Direkt eingebundene Resourcen liegen auf demselben Server wie das Blog, ansonsten wird regulär verlinkt. Wenn dann die Seite dahinter kaputt geht, habe ich zwar einen toten Link, aber ansonsten ist meine Seite nicht beeinträchtigt.
Use native fonts
Heutzutage kann man einfach Schriftarten vom Server laden, wenn sie auf dem Zielrechner nicht existieren. Früher musst man hoffen, dass die Schriftart existiert, deswegen wurde oft geraten, sich auf Fonts zu verlassen, die auf praktisch jedem Rechner zu Verfügung stehen, oder man hat einfach Font-Familien angegeben (z.B. „serif“).
Heutzutage kann man Schriftarten dynamisch laden, aber sie neigen dazu, auch komprimiert noch groß zu sein. Zudem wird häufig die Hotlinking-Regel verletzt, wenn man sie z.B. von Google lädt.
Generell ist es eine gute Idee, eine Website so zu bauen, dass die auch dann gut aussieht, wenn nicht genau die richtige Schriftart gefunden wurde. Dieses Blog ist da recht unkompliziert, lädt keine Schriftarten nach und sieht selbst in einem textbasierten Browser noch in Ordnung aus.
Compress your images
Da rennt er bei mir offene Türen ein. Ich bin ein Kompressionsfetischist. Ich habe dazu oft genug geschrieben. Hat aber imho weniger mit Langlebigkeit zu tun, außer, dass die Seite dann einfacher zu archivieren ist.
Lustig ist, dass Lente zwar gegen HTML-Minimierung ist, aber SVG-Minimierung stark empfiehlt, wobei minimierte SVGs praktisch nicht mehr in eine gut lesbare Form zurückgewandelt werden können.
Reduce the risk of rotten links
Hier geht es darum, Warnmechanismen aufzubauen, falls bestimmte Pages oder die ganze Seite nicht mehr erreichbar ist. Habe ich nicht, aber wäre vielleicht mal wert, darüber nachzudenken. Auch, was externe Links angeht.
Aber was ist mit dem Server?
Meine Seite kann, meiner Meinung nach, rein technisch noch Jahrzehnte bestehen. Die größte Gefahr ist, dass aus irgendwelchen Gründen mal mein Server abgeschaltet wird (z.B. weil ich keine Lust mehr habe, ihn mir nicht mehr leisten kann oder mir etwas zugestoßen ist). In diesem Fall wäre die Seite weg.
Ich archiviere grundsätzlich jeden neuen Blogpost hier auf archive.org. So sind diese Posts auch noch verfügbar, wenn diese Seite nicht mehr existiert. Weil ich die Seite minimal gehalten und die Bilder gut komprimiert habe, nimmt sie dort auch nicht zu viel Speicher weg und kann im Gegensatz zu single-page-apps auch sehr effektiv archiviert werden.