Vor einiger Zeit wurde ich in den Kommentaren gefragt wie mein aktuelles Hosting für den Blog aussieht und darüber möchte ich heute mal ein paar Worte verlieren. Ich nutze derzeit einen Linux vServer open_in_new mit Ubuntu, da ich dort die Freiheiten habe die ich benötige. Ich setzte auf einen vServer, da ich die Performance eines vollwertigen Root-Servers derzeit nicht benötigte.
Der Server ist mit zwei virtuellen CPUs unterwegs, verfügt über 4GB RAM und kann 200GB Speicherplatz verarbeiten. Alles in allem ein sehr kleines, aber funktionales Modell. Web-Hosting Angebote kommen für mich nicht in Frage, da ich sowohl bei den Anforderungen an den Server, wie auch bei den Anforderungen bezüglich der Domain-Konfiguration einige Sonderwünsche habe.
Über die letzten Wochen und Monate habe ich meine Build-Pipeline für den Blog optimiert und erweitert und würde sie zum jetzigen Zeitpunkt als fertiggestellt betrachten. Verbesserungen kann man natürlich immer vornehmen, aber aktuell fallen mir zumindest keine mehr ein.
Das Ganze läuft komplett via Git ab, sodass ich als Nutzer lediglich einen Commit und Push durchführe und alles weitere automatisiert geschieht. Dabei werden direkt beim Commit neue Bilder optimiert, sodass der Server keine unnötige Arbeit durchführen muss. Sobald der Push durchgeführt wird, wird ein Git-Hook open_in_new ausgelöst und startet den Hugo open_in_new Build Prozess. Dieser sorgt durch Minification automatisiert für kleinere und optimierte Dateien. Anschließend kopiert das Script die Dateien ins Deploy Verzeichnis.
Seit dem Release meiner aktuellen Blog Version 8.0 habe ich diverse kleine Optimierungen vorgenommen, sodass die Seite von nun an auf die Version 8.1 hören darf. Doch was hat sich denn genau getan?
Ich habe alle Bilder innerhalb des Blogs optimiert, CSS + JS + HTML Dateien minified, den Code aufgeräumt, kleinere CSS Optimierungen vorgenommen und alle generellen HTML Fehler behoben. Dadurch sollte die Seite schnell laden, fehlerfrei sein und sehr rund laufen.
Im Rahmen der Fehlerbehebung wurden unter anderem Zoomprobleme unter Chrome auf mobilen Geräten behoben. Verschiedene Fehlerhafte HTML Tags wurden entfernt und Aufrufe für fehlende Ressourcen gelöscht. Zusätzlich wurden Meta-Tags optimiert, was vor allem die Einbindung in sozialen Netzwerken verbessern sollte. Dies sollte sowohl die Darstellung, wie auch die Anzahl der nötigen Request minimieren.
Darüber hinaus gab es kleine Anpassungen an den externen Diensten, welche für die Suche und die Kommentare eingebunden werden. Diese sollten nun noch etwas verlässlicher arbeiten und sind für mich nun via Monitoring kontrollierbar. Alles in allem bedeutet dies einen Score von über 90 bei PageSpeed Insights open_in_new, eine stabile Build Chain + Monitoring für mich und wesentlich mehr Zeit für weitere Projekte mit z.B. Flutter.
Während ich aktuell dabei bin meine zusätzlichen Dienste, die ich in meinem Blog nutze (Suche und Kommentare), zu optimieren, habe ich mir vor einigen Tagen die Zeit genommen und die Seite selbst evaluiert. Sie ist nun seit einigen Monaten online, alles läuft wie gewünscht und ich dachte mir ein wenig finale Pflege könnte nicht schaden.
Allem voran war mein Plan HTML Fehler zu beheben, wofür ich den Nu Html Checker nutzte und nun alle generellen Fehler beheben konnte. Dies gilt für die Hauptseite, sowie für einige Beiträge die ich getestet habe. Es kann natürlich sein das in einigen Beiträgen weiterhin kleine Fehler versteckt sind, allgemein sollte nun aber alles sehr rund laufen.
Weiterhin wollte ich die Ladezeit noch etwas optimieren. Durch eine Reduktion der Seitengröße, welche ich durch die Optimierung der zu ladenden Bilder erreichen wollte, sollte dies geschehen. Bei meiner alten Seite nutzte ich dafür ein Script auf dem Server. Dies macht nun natürlich keinen Sinn mehr, denn die Bilder sollten einfach schon ordentlich im Git Repository landen. Aus diesem Grund schnappte ich mir OptiPNG und jpegoptim für Windows und ließ die Tools ihre Arbeit tun. Die Aufrufe mache ich aktuell noch manuell, ich plane aber sie als post-commit Hooks direkt auf neue Bilder anzuwenden.
Alles in allem konnte ich so Fehler beheben und etwas Geschwindigkeit rausholen. Das meiste dürfte eher Perfektionismus sein, aber auch Kleinvieh macht bekanntlich Mist. Als nächste gibt es wie eingangs erwähnt vor allem Optimierungen bei den externen Diensten, doch dazu später mehr.
Ein weiterer Beitrag zu meinen Erfahrungen mit dem Static Site Generator Hugo im Rahmen der Entwicklung meines Blogs steht an. Das Thema ist kurz und knapp, aktualisiert Hugo häufig und passt euren Code entsprechend der letzten Änderungen an. Selbiges tat ich gestern, auf die aktuelle Version v0.48 und das Ergebnis ist ein Viertel weniger Build-Zeit und wesentlich sauberer Code an diversen stellen.
Dabei half vor allem das letzte Update, welches es ermöglicht Variablen zu überschreiben open_in_new. Bis dato war dafür die Nutzung von .Scratch Variablen open_in_new nötig, was ich persönlich etwas anstrengend fand. Zusätzlich setze ich umfangreich auf resources.Get, was die Basis für die Minification von CSS und JS Dateien open_in_new ist. Außerdem verwende ich nun .Site.GetPage open_in_new an diversen Stellen. Dadurch kann man schnell und einfach für einen konkreten Pfad die gesamte Seite, inklusive des jeweiligen Kontexts, laden und verwenden. Letzteres half mir z.B. dabei fehlerhafte Links zu beheben, welche durch Slashes in Kategorien oder Tags auftraten.
Die Generierung meiner Seite ist nun zusätzlich mit einem weiteren Parameter versehen. Ich führe den Build-Prozess nun mittels hugo –minify open_in_new aus. Dies sorgt dafür das alle möglichen Ressourcen, wie z.B. HTML Seiten, verkleinert werden. Dies minimiert die Ladezeiten, da die eigentliche Seite kleiner ist.
Alles in allem habe ich nun ordentlicheren Code, welcher entsprechend besser wartbar ist und zusätzlich sollte die Seite schneller laden und weniger Fehler beinhalten. All diese Verbesserungen basieren grundlegend auf den Verbesserungen an Hugo bzw. der Programmiersprache Go. Solltet ihr also Hugo nutzen, habt ruhig ein Auge auf die Releases im Github Projekt, welche ihr in den Related Links findet. Selbige sind immer recht umfangreich beschrieben und vermitteln schnell eine Idee, ob das Update für einen selbst hilfreich sein könnte.
Während der Entwicklung meines neuen Blogs bin ich natürlich über diverse Dinge gestolpert, vor allem im Bereich der Entwicklung mit Hugo. Dies bezieht sich sowohl auf das Tool selbst, wie auch auf die Templating-Engine. In diesem Beitrag möchte ich etwas auf beide Themen eingehen.
Beginnen möchte ich mit Hugos Command Line Interface (CLI) open_in_new, denn dies ist der Weg um Hugo zu steuern. Für die Entwicklung nutze ich meistens hugo server. Dadurch wird ein Server erstellt der schnell und flexibel, mit automatischem Reload bei Änderungen, eure Website lokal verfügbar macht. Solltet ihr umfangreichere Änderungen machen, die vielleicht nicht immer komplett erkannt werden, kann durch hugo server –disableFastRender der schnelle Rendering Modus deaktiviert werden. Dadurch dauert das erneute bauen etwas länger, Änderungen werden aber besser erkannt und umgesetzt. Solltet ihr einfach nur neuen Content hinzufügen und nicht am Template arbeiten, reicht übrigens meistens hugo server.
Um die Seite zu bauen reicht es hugo aufzurufen, dadurch wird im /public Ordner die gesamte Seite erstellt, sodass ihr sie direkt hochladen könnt. Bevor ihr dies tut kann man übrigens mittels hugo benchmark und hugo –templateMetrics herausfinden wie lange eure Seite und die einzelnen Komponenten zum Bauen brauchen. Dadurch findet man Bottlenecks und kann entsprechend optimieren. Ich konnte meine Build-Zeit dadurch vor kurzem von 140 Sekunden auf 40 drücken, wofür ich nur Änderungen in weniger als zehn Zeilen brauchte.
Das Aussehen einer Website definiert maßgeblich ob Benutzer selbige aktiv nutzen oder schnell wieder verschwinden. Der Inhalt ist natürlich auch wichtig, aber der erste Eindruck muss eben auch passen.
Aus diesem Grund habe ich viel Arbeit in mein aktuelles Design oder im Hugo-Kontext Theme fließen lassen. Initial dachte ich darüber nach ein fertiges Theme zu nutzen und es vielleicht nur anzupassen. Da ich aber relativ spezielle Anforderungen habe, baute ich schlussendlich doch alles selbst. Inspiriert wurde ich aber vom Hugo AMP Design open_in_new, wie man vielleicht am schrägen Header erkennt.
Erstellt habe ich alles von Grund auf neu, unter Zuhilfenahme meiner alten HTML Struktur, kombiniert mit dem moderneren Ansatz aus dem oben genannten Theme.
Hugo ist zum einen ein Getränk und zum anderen aber auch ein verdammt guter Open-Source Static-Site-Generator. Für mich wurde er vor allem interessant da es keine Abhängigkeiten gibt, welche über Paketmanager oder manuell geladen werden müssen. Denn ich möchte mich auf die Entwicklung konzentrieren und nicht darauf den Build-Prozess mal wieder zu reparieren.
Wie ich Hugo initial gefunden habe weiß ich gar nicht mehr, aber ich war von Anfang an durchaus interessiert, als ich vor knapp zwei Jahren das praktische Tool entdeckte. Doch durch den durchaus großen Aufwand einen kompletten HTML / CSS / PHP / MySQL Stack wegzuwerfen und von Grund auf in einer unbekannten Technik neu zu schreiben, dauerte es noch etwas bis zur eigentlichen Umsetzung.
Heute möchte ich mit der Newssammlung zu meiner neuen Blogversion beginnen. Die Entwicklung hat lange gedauert, die Umstellung war umfangreich und zwischendurch kam noch die DSGVO zu Besuch. Alles in allem ergaben sich daraus zwar einige Schwierigkeiten, aber ich konnte auch extrem viel Neues lernen und zumindest mich macht das Ergebnis sehr zufrieden.
In der nun startenden Sammlung möchte ich unter anderem auf Hugo open_in_new eingehen, den Static-Site-Generator meiner Wahl. Dieser bildet die Basis für meinen nun statischen Blog. Das Tool funktioniert wirklich gut, hat extrem praktische Funktionen und wird vor allem sehr aktiv weiterentwickelt. Erst vor kurzem gab es ein Update, welches Bildoptimierung und das Verkleinern von CSS, JS usw. erlaubt. Auf diese Version muss ich noch upgraden und meine Build-Chain entsprechend anpassen.
