Statische Seiten

Hier hatte ich vor einigen Tagen zum ersten Mal über Publii berichtet, einem freien (GPL) Desktop CMS für statische Webseiten und (in Grenzen) auch für Blogs. Nun wurde von den Machern ein neues Update angekündigt, das unter anderem Verbesserungen auf der Publikationsseite enthält, so daß ich (m)eine Publii-Site nun auch zu meinem lokalen MAMP-Server hochladen kann und zum anderen ein neues Starter Theme vorgestellt, daß als Basis für die Entwicklung eigener Templates dienen kann. Außerdem habe ich zwischenzeitlich herausbekommen, wie ich das Arbeitsverzeichnis meiner Installation in die Dropbox oder mein Git legen kann. Weiteren Experimenten mit diesem vielversprechenden Werkzeug für statische Seiten steht also nichts entgegen.

Momentan nutze ich ja neben RubyFrontier, mit dem dieses Blog Kritzelheft und auch mein Wiki erstellt werden, vor allen Dingen MkDocs zum Erstellen statischer Seiten, wie zum Beispiel meinen Seiten zu Processing.py. Aber da viele Wege nach Rom führen, ist nicht nur Publii eine Alternative. So wird hier zum Beispiel über ein interessantes Experiment berichtet: »Starting a Rmarkdown Blog with Blogdown + Hugo + Github«. Denn es muß in diesem Zusammenhang nicht immer Jekyll sein, Experimente, die eine unserer Auszubildenden hier am Institut durchgeührt hatte, zeigten, daß Hugo unschlagbar schnell ist. Und wenn man Blogdown damit verbinden kann, wäre das durchaus auch etwas für den Schockwellenreiter, der ob seines Umfanges für viele andere Static Site Tools einfach zu fett ist. Ich sollte mir diese Strategie daher mal gründlicher anschauen, es wäre vielleicht ein Start ins reproducible Blogging.

Einen ähnlichen Ansatz verfolgt übrigens auch Lorenzo Busetto, der ihn in seinem Artikel »Building a website with pkgdown: a short guide« erläutert. Auch hier werden GitHub Pages als Webserver benutzt, eine Methode, die mehr und mehr Sympathie bei mir findet.

Zum Schluß noch etwas Unangenehmes: Google hat mir eine ziemlich unverschämte Mail geschickt, in der sie ankündigen, daß Chrome ab Oktober (in Version 62) dieses Blog Kritzelheft als »NICHT SICHER« anzeigen wird und behauptet kackfrech

Unter den folgenden URLs auf Ihrer Website befinden sich Texteingabefelder wie < input type="text" > oder < input type="email" >. Diese lösen die neue Chrome-Warnung aus. Anhand der Beispiele sehen Sie, wo die Warnungen angezeigt werden, und können so entsprechende Maßnahmen zum Schutz der Nutzerdaten ergreifen. Diese Liste ist nicht vollständig.

Der Schockwellenreiter besteht aus statischen Seiten und er hat gar keine Texteingabefelder, auch nicht unter den in der Email angegeben URLs. Ein paar Zeilen weiter erfahre ich dann den wahren Grund:

Die neue Warnung ist Bestandteil eines langfristigen Plans, alle über HTTP bereitgestellten Seiten als »nicht sicher« zu kennzeichnen.

Dieser langfristige Plan ist ein Angriff auf das freie Web! Denn das teure Sicherheitstheater HTTPS kann sich ein kleiner Webseitenbetreiber gar nicht leisten. Denn woher soll dieser eine lückenlose Zertifikatskette bis zu einem Root-Zertifikat auf aktueller Sicherheitsstufe (SHA-3) überhaupt bekommen? Von der ständigen Notwendigkeit, diese Zertifikate für teures Geld auch noch zu erneuern, will ich gar nicht erst reden.

Dave Winer hat diese unverschämte Mail von Google übrigens auch bekommen und scheint noch empörter als ich. Und sein Fazit ist das gleiche wie meines: Solange Amazon keine einfache (und kostengünstige) Möglichkeit bietet, HTTPS von Amazon S3 (wo sowohl Winer wie auch ich unsere Seiten hosten) zu fahren, kann uns Google am Arsch lecken.

Das obige Bild hat natürlich nicht wirklich etwas mit diesem Thema zu tun. Es ist nur meiner festen Überzeugung geschuldet, daß wir in diesen prüden Zeiten und auch Google zum Trotz mehr Wegguckbilder brauchen.

---

4 (Email-) Kommentare

---

Ich verwende seit Oktober 2016 Hugo als Plattform zur Erstellung meiner Webseiten. Ist zwar nicht von dem Kaliber ihrer Webseite aber bisher konnte ich all meine Wünsche damit umsetzten. https://www.bananas-playground.net/tags/hugo/
Nur dir Suche konnte ich nicht damit abbilden. Da musste ich leider was dynamisches erstellen. https://www.bananas-playground.net/2016/10/static-publishing-und-die-suche/

– Johannes K. (Kommentieren) (#)

---

Sie schrieben: "Hier hatte ich vor einigen Tagen zum ersten Mal über Publii berichtet, einem freien (GPL) Desktop CMS für statische Webseiten und (in Grenzen) auch für Blogs."
Mein Reden, statische Seiten genügen völlig und sind nicht angreifbar. Ich verwende Delphi und sqlite. Das Design steckt in einer Maske in html.
Mit weniger Faulheit wäre es schon schöner, trotzdem, mehr brauche ich nicht. http://thumulla.com/home/__index.html
Wenn es hübscher ist wird es öffentlich.

– Carsten T. (Kommentieren) (#)

---

Schön zu sehen, wenn die Projekte hier weitergehen. Ich hatte mir Publii auch mal kurz angeschaut, zögerte aber den Schritt zu gehen, weil ich meine Daten nicht in Anbieter-Clouds lagern möchte. Irgendwo hier im Kritzelheft habe ich dann meine Empfehlung für https://ipfs.io bekommen, habe das mit http://casual-effects.com/markdeep/ verknüpft und habe meinen persönlichen Meilenestein meiner "Raus aus den Datensilos" geschafft. (Damit möchte ich mich auch bei dir bedanken, Jörg, der mich erst auf diese Reise gebracht hat). Zwar ist das alles noch ziemlich Alpha und mit DNS etc. muss ich mich auch noch erst auseinandersetzen, bin aber bisher vollkommen zufrieden. Ich würde mich freuen, wenn auch in Zukunft noch einige Artikel bezüglich Publii hier erscheinen würde, da ich gerne über den besagten Tellerrand schaue. :)
Entschuldigung, Link zu meinem Projekt vergessen. http://hackerb.it

– Robert J. T. (Kommentieren) (#)

---

Dieser langfristige Plan ist ein Angriff auf das freie Web!
Von HTTPS für alles und jeden halte ich auch nichts, denn so kann man bestens z.B. alte Inhalte verschwinden lassen, das wird ein ähnlicher "Erfolg" werden wie das Abschalten von geocities.
Denn das teure Sicherheitstheater HTTPS kann sich ein kleiner Webseitenbetreiber gar nicht leisten. Denn woher soll dieser eine lückenlose Zertifikatskette bis zu einem Root-Zertifikat auf aktueller Sicherheitsstufe (SHA-3) überhaupt bekommen? Von der ständigen Notwendigkeit, diese Zertifikate für teures Geld auch noch zu erneuern, will ich gar nicht erst reden.
Dafür gibts ja Let’sEncrypt & Konsorten, bei Domain Validated ist sogar die Angabe einer Email-Adresse optional. Mit der richtigen Software ist das sogar einigermaßen wartungsfrei, aber (ich wiederhole mich) nicht für die wartungsfreie Ewigkeit, sein Testament im Web auf ewige Zeiten kann man so nicht hinterlassen.
Der Schockwellenreiter besteht aus statischen Seiten und er hat gar keine Texteingabefelder, auch nicht unter den in der Email angegeben URLs.
Deine HTML-Seite hat übrigens doch inputs, nämlich für das DuckDuckGo-Suche-Formular… wenn du die rausbaust, kann sich Google nicht mehr beschweren.
Z.36:<input type=hidden name=sites value=blog.schockwellenreiter.de>
Z.37:<input type=text class=search-query name=q maxlength=255 placeholder=DuckDuckGo-Suche>
Dave Winer hat diese unverschämte Mail von Google übrigens auch bekommen und scheint noch empörter als ich. Und sein Fazit ist das gleiche wie meines: Solange Amazon keine einfache (und kostengünstige) Möglichkeit bietet, HTTPS von Amazon S3 (wo sowohl Winer wie auch ich unsere Seiten hosten) zu fahren, kann uns Google am Arsch lecken.
Wer ins Silo zieht, darf sich nicht beschweren, wenn es dort nach Silo riecht…. ;)
vServer + NGINX + https://github.com/hlandau/acme bringt Spaß und Leistung, und man kann auch (und gerade bei statischen Seiten!) die Dokumente und Assets vor-komprimieren und mit gzip_static und brotli_static ausliefern.
Beispiel: aus /thema/index.html wird mittels minify, zopfli und brotli
/thema/index.html
/thema/index.html.gz
/thema/index.html.br
und im gleichen Aufwasch kann man auch noch:
- Bilder kleinrechnen mit moz_jpeg oder guetzli, optipng, gifsicle
- PDFs kleinquetschen mit pdftk
- Meta-Informationen aus Bildern und Dokumenten entfernen
- Wasserzeichen &&|| copyright-Hinweise hinzufügen
- etc.pp.
Auf dem vServer liegen im Webroot alle vorkomprimierten Sachen und werden mit minimalem CPU-Aufwand geserved, zu Hause oder auf dem Laptop hat man sein Setup, was zugleich als Backup und VCS-master dient, samt allen Originalen (Fotos, Dokumente).
Weil es Dein eigener vServer ist und du auch selbst mit Let’sEncrypt redest, kannst du auch gleich einen asset host für deine css, js, und Bilder einrichten.
für den vServer:
- http://nginx.org/en/download.html
- http://nginx.org/en/docs/http/ngx_http_gzip_static_module.html
- https://github.com/google/ngx_brotli https://github.com/hlandau/acme
für die Dokumentenpipeline:
- https://github.com/tdewolff/minify
- https://github.com/google/zopfli
- https://github.com/google/brotli
- https://github.com/mozilla/mozjpeg
- https://github.com/google/guetzli
- http://optipng.sourceforge.net/
- https://www.pdflabs.com/tools/pdftk-the-pdf-toolkit/
Die Dokumentenpipeline kann dir Dein Praktikant sicher als GNUmakefile implementieren, einfach immer mit Kopien arbeiten und nie etwas in situ ersetzen, dann ist es supereinfach und man braucht auch keine ständigen reruns und PHONY targets, und es werden auch immer nur die neuen Dateien verarbeitet. Im Netz behaupten manche Leute dass zopfli -6 und brotli -4 reichen; das stimmt für die meisten vServer, wenn man die Dokumente dynamisch komprimieren liesse.
Hier aber machen wir das statisch und da der Rechner zu Hause dicke reicht und mit Makefile auch unbeaufsichtigt komprimieren und deployen kann, kann man da auch ordentlich hinlangen und mit den maximal(er)en Einstellungen arbeiten - es hilft nämlich jedem Kunden, Zeit und Traffic zu sparen und bringt Punkte beim Ranking in den Google-Treffern.
Den Rest, HTTP einfach als unsicher zu ranken, das muss man politisch beseitigen, ein Götz-Zitat bringt da keinen mm Landgewinn.
Testdaten von dieser kommentierten Seite:
Dein HTML: 19891 B
Minifiziert: 17459 B (87.8%)
Minifiziert+zopfli: 6187 B (31.1%)
Minifiziert+brotli: 5602 B (28.2%)
Dein CSS: 118128 B
Minifiziert: 97563 B (82.6%)
Minifiziert+zopfli: 14855 B (12.6%)
Minifiziert+brotli: 13340 B (11.3%)
d.h. ein aktueller Chrom(e|ium) oder verwandter Browser (alle Androids, Opera, etc) hätte nur ~ ein Fünftel der jetzigen Zeit und Bandbreite gebraucht, um das HTML geladen zu haben, ABER nur über HTTPS, weil nur dann die Verwendbarkeit von brotli angezeigt wird.

– Peter F. (Kommentieren) (#)

---

(Kommentieren)