In den letzten Jahren habe ich immer wieder aus verschiedenen Gründen die Blogsoftware gewechselt. Dieses Mal bin ich von Wordpress zu Jekyll umgezogen. Mein Vorgehen und Gründe möchte ich in diesem Beitrag erläutern.

Was ist Jekyll?

Jekyll ist eine Blogsoftware bzw. ein sogenannter Static Site Generator. Primär wird Jekyll von GitHub Pages verwendet. Die meisten Tutorials die man so im Internet finden beziehen auch genau darauf. Grundlegend baut die Software Markdown-Dateien zu statischen HTML Dateien um diese mit einem einfachen Webserver ausliefern zu können. Im bequemsten Fall sogar mit dem integriertem.

Gründe für meinen Wechsel

Gründe könnten mannigfaltig sein. Schlussendlich läuft es aber darauf hinaus, dass Wordpress immer mächtiger wird. Das hat seine Vor- und Nachteile. Sicherlich ist es sehr praktisch für jeden Anwendungsfall Wordpress verwenden zu können, denn die verschiedenen Plugins und Themes machen das möglich. Viele großen Webseiten basieren auf Wordpress und mit dem notwendigen Know-How und Ressourcen lassen sich auch sehr Performance Webseiten bauen. Der Nachteil der Erweiterbarkeit liegt entsprechend auch in der Pflege und den Bemühungen einen guten Wert für den LCP zu erreichen. Mir ist es im Laufe der Zeit nicht gelungen einen guten Wert zu erreichen. Am HosterNetcup (externer Link) liegt es nicht, da ich hier auch verschiedene ausprobiert habe. Zudem bin ich im Moment dabei mich von verschiedenen großen Softwareprodukten zu trennen und auf freiere Software zu setzen.

In der Webentwicklung steht LCP für “Largest Contentful Paint”. Es handelt sich um eine wichtige Metrik für die Ladeleistung einer Webseite. LCP misst die Zeit, die benötigt wird, um den größten sichtbaren Inhalt im Viewport eines Nutzers während des Seitenladens zu rendern. Ein guter LCP-Wert ist wichtig, um sicherzustellen, dass Webseiten schnell und reibungslos geladen werden und Benutzer eine bessere Erfahrung haben. {:.note title=“Was ist LCP?”}

Installation von Jekyll

Die Installation von Jekyll kann unter verschiedenen Betriebssystemen durchgeführt werden. Allerdings ist Windows nicht mit dabei. Wenn man allerdings den Umweg über WSL2 geht, kann man der regulären Linux Installation für die verwendete Linux-Distribution folgen. In dieser Anleitung gehe ich erst mal auf die Installation unter MacOS ein, da ich persönlich dieses Betriebssystem verwende. Alternative Installationen finden sich natürlich in der offiziellen Dokumentation. Gern kann dort diese entsprechend verwendet werden.

Installation unter MacOS

Installation des Paketmanagers brew

MacOS Nutzer haben in der Regel schon den Paketmanagerbrew installiert. Falls du das noch nicht getan hast, lässt sich das mittels

/bin/bash -c"$(curl -fsSL https://raw.githubusercontent.com/Homebrew/install/HEAD/install.sh)"

erledigen. Grundsätzlich sollte aber immer beim Ausführen von Programmen direkt aus dem Internet vorsichtig sein! Sobald das erledigt ist, brauchen wir jetzt den Ruby Installer denn Jekyll ist in der entsprechenden Programiersprache geschrieben.

Installation von ruby

brew install chruby ruby-install xz

Dies kann durchaus ein paar Minuten dauern, das ist nicht ungewöhnlich. Nun installieren wir noch ruby selbst.

ruby-install ruby 3.2.2

Beachte, dass die Version 3.2.2 die zum Zeitpunkt des Artikels die aktuellste Version ist, dass kann zum jetzigen Zeitpunkt anders sein. Der nächste Schritt ist, dass wir ruby und die ganzen Environment Variablen noch aktivieren und in die MacOS Konfiguration speichern

echo"source$(brew --prefix)/opt/chruby/share/chruby/chruby.sh" >> ~/.zshrcecho"source$(brew --prefix)/opt/chruby/share/chruby/auto.sh" >> ~/.zshrcecho"chruby ruby-3.2.2" >> ~/.zshrc# run 'chruby' to see actual version

Installation von Jekyll

Endlich kommen wir zu dem Punkt, dass wir Jekyll selbst installieren können.

gem install jekyll

Auch der Schritt kann einige Zeit lang brauchen. Anschließend haben wir Jekyll installiert.

Jekyll Webseite anlegen

Sobald wir also eine lauffähige Version von Jekyll haben, können wir nun eine Webseite anlegen. Wir suchen uns also einen entsprechenden Ordner aus in dem die Installation durchgeführt werden soll. Ich mache sowas immer in einem Unterordner in meinem Homeverzeichnis.

cd ~

Den Namen den wir im install Befehl mitgeben wird auch der Name des Ordners sein. Natürlich kann der Prozess beliebig oft ausgeführt werden, falls euch das nicht gefällt.

jekyll new blog

Es entsteht dann eine ungefähr solche Ausgabe

Running bundle install in /Users/teqqy/blog... Bundler: Fetching gem metadata from https://rubygems.org/............ Bundler: Resolving dependencies... Bundler: Fetching rouge 4.1.3 Bundler: Installing rouge 4.1.3 Bundler: Bundle complete!7 Gemfile dependencies,33 gems now installed. Bundler: Use`bundle info[gemname]` to see where a bundled gem is installed.New jekyll site installed in /Users/teqqy/blog.[21:31:33][cost 3.162s] jekyll new blog

Nun wechseln wir in das Verzeichnis und gucken mal was so für Dateien und Ordner dort hinterlegt sind.

[21:32:50][~/blog] ❱❱❱ ls -ltotal48-rw-r--r--1 teqqy staff41931 Jul 21:31 404.html-rw-r--r--1 teqqy staff130931 Jul 21:31 Gemfile-rw-r--r--1 teqqy staff205231 Jul 21:31 Gemfile.lock-rw-r--r--1 teqqy staff207931 Jul 21:31 _config.ymldrwxr-xr-x3 teqqy staff9631 Jul 21:31 _posts-rw-r--r--1 teqqy staff53931 Jul 21:31 about.markdown-rw-r--r--1 teqqy staff17531 Jul 21:31 index.markdown

Wie man sieht, sind das nicht viele Dateien. Nun sollten wir die_config.yml anpassen. Die Begriffe sollten selbsterklärend sein. Die Werte sind aber erst mal keine Pflicht. Um jetzt die HTML Dateien bauen zu lassen verwenden wir folgenden Befehl

jekyll serve

Es erscheinen diverse Fehlermeldungen und Warnungen auf Grund von veralteten Abhängigkeiten. Leider sind diese immer noch nicht sauber gefixt. Die letzte Ausgabe sollte etwas in der Art von

Run in verbose mode to see all warnings.done in 0.401 seconds. Auto-regeneration: enabledfor'/Users/teqqy/blog' Server address: http://127.0.0.1:4000/ Server running... press ctrl-c to stop.

Enthalten. Jetzt könnt ihr euren Browser öffnen und die URLhttp://127.0.0.1:4000 verwenden.

Wir brechen dann wieder den laufenden Server mitCTRL-C ab. Wenn wir jetzt nochmal die Verzeichnisse auflisten sehen wir, dass dort ein neuer Ordner_site erstellt worden ist.

[21:40:43][~/blog] ❱❱❱ ls -ltotal48-rw-r--r--1 teqqy staff41931 Jul 21:31 404.html-rw-r--r--1 teqqy staff130931 Jul 21:31 Gemfile-rw-r--r--1 teqqy staff205231 Jul 21:31 Gemfile.lock-rw-r--r--1 teqqy staff207931 Jul 21:31 _config.ymldrwxr-xr-x3 teqqy staff9631 Jul 21:31 _postsdrwxr-xr-x8 teqqy staff25631 Jul 21:35 _site-rw-r--r--1 teqqy staff53931 Jul 21:31 about.markdown-rw-r--r--1 teqqy staff17531 Jul 21:31 index.markdown

Dieser Ordner ist nun schlussendlich das wichtige. Dieser kann auf einen Webserver kopiert und ausgeliefert werden.

Webseite bereitstellen

Viele Tutorials im Internet verwenden denjekyll serve Befehl um die Webseite auszuliefern und richten einen Webserver wie NGINX oder apache2 als reverse proxy ein. Dies ist allerdings nicht der vom Hersteller empfohlene Weg. Ich für meinen Teil habe das Verzeichnis auf meinen Webserver kopiert und liefere es mit einem Nginx Docker-Container aus. Dieser hat entsprechende Traefik Labels, welches sich um die Zertifikate etc kümmert. Sicherlich kein Setup für jeden.

Nginx Docker Container

Meine verwendetedocker-compose.yaml Datei kannst du natürlich übernehmen wenn du möchtest. Du müsstest nur die Werte entsprechend anpassen.

---version:"3.8"services:nginx:image:nginxcontainer_name:nginxvolumes:-./_site:/usr/share/nginx/html-./nginx.conf:/etc/nginx/conf.d/www_nginx.conflabels:-"traefik.enable=true"-"traefik.http.middlewares.nginx-https.redirectscheme.scheme=https"-"traefik.http.middlewares.nginx-compress.compress=true"-"traefik.http.routers.nginx-http.entrypoints=web"-"traefik.http.routers.nginx-http.rule=Host(`www.example.com`) || Host(`example.com`)"-"traefik.http.routers.nginx-http.middlewares=teqqy-https@docker"-"traefik.http.routers.nginx.entrypoints=websecure"-"traefik.http.routers.teqqy.rule=Host(`www.example.com``) || Host(`example.com``)"-"traefik.http.routers.nginx.tls=true"-"traefik.http.routers.nginx.tls.certresolver=default"-"traefik.http.routers.nginx.middlewares=secHeaders@file"-"traefik.http.routers.nginx.middlewares=teqqy-compress"-"traefik.http.services.nginx.loadbalancer.server.port=80"networks:-teqqywp-traefik_proxynetworks:traefik_proxy:external:name:traefik_proxyteqqywp:driver:bridge

Nginx Konfiguration

Ich binde noch eine eigenenginx.conf Datei ein in der ich noch Anpassungen für Caching und anderes mache.

server {
listen 80;
server_name example.com www.example.com
root /usr/share/nginx/html;
index index.html index.htm;
if (!-f "${request_filename}index.html") {
rewrite ^/(.*)/$ /$1 permanent;
}
if ($request_uri ~* "/index.html") {
rewrite (?i)^(.*)index\.html$ $1 permanent;
}
if ($request_uri ~* ".html") {
rewrite (?i)^(.*)/(.*)\.html $1/$2 permanent;
}
error_page 404 /404.html;
location / {
try_files $uri $uri.html $uri/ =404;
}
location ~* \.(?:ico|css|js|gif|jpe?g|png)$ {
expires 30d;
add_header Pragma public;
add_header Cache-Control "public";
}
# reduce the data that needs to be sent over network -- for testing environment
gzip on;
# gzip_static on;
gzip_min_length 10240;
gzip_comp_level 1;
gzip_vary on;
gzip_disable msie6;
gzip_proxied expired no-cache no-store private auth;
gzip_types
# text/html is always compressed by HttpGzipModule
text/css
text/javascript
text/xml
text/plain
text/x-component
application/javascript
application/x-javascript
application/json
application/xml
application/rss+xml
application/atom+xml
font/truetype
font/opentype
application/vnd.ms-fontobject
image/svg+xml;
# allow the server to close connection on non responding client, this will free up memory
reset_timedout_connection on;
# request timed out -- default 60
client_body_timeout 10;
# if client stop responding, free up memory -- default 60
send_timeout 2;
# server will close connection after this time -- default 75
keepalive_timeout 30;
# number of requests client can make over keep-alive -- for testing environment
keepalive_requests 100000;
}

Nun kann der Container gestartet werden und nach kurzer Zeit könnt ihr die Seite über die angegebene URL aufrufen.

Wordpress Daten exportieren

Für den Export habe ich das Wordpress PluginWordpress to Jekyll Exporter (externer Link) verwendet. Es nicht das beste Plugin aber für mich hat es gereicht. In Wordpress können wir dann unterWerkzeuge den Export ausführen und bekommen eine ZIP-Datei zum Download. Die Inhalte können wir direkt in unser Jekyll Verzeichnis kopieren und die Seiten neu genierieren lassen.

jekyll serve

Nun können wir den Ordner_site wieder auf unseren Webserver kopieren. Den Container müssen wir nicht neu starten, denn nginx liefert die Dateien direkt aus. Ein einfacher reload im Browser reicht dafür aus.

Jekyll anapssen

Jetzt liegt es an euch, Jekyll entsprechend den Bedürfnissen anzu passen. Heißt ein Theme herunter zu laden oder mit Plugins zu erweitern.

WordPress ist eine der beliebtesten CMS Systeme. Leider ist die Geschwindigkeit häufig nicht gut. Mit meinen drei Tipps kannst du die WordPress Docker Performance ein gutes Stück verbessern.

Im Internet gibt es nicht wirklich viele Informationen zu dem Problem. Meist wird behauptet, dass es am Hostsystem liegen soll. Da ich das bereits ausschließen konnte wurden viele Beiträge obsolet.

Anfangen sollte man aller erstes aber mit der Messung von harten Zahlen. Eine subjektive Meinung hilft bei der Geschwindigkeit meist wenig. Ob eine Seite schnell oder langsam lädt ist auch ein Rankingfaktor bei Google, also wichtig für das SEO.

Ich überprüfe die Geschwindigkeit häufig mitGoogle PageSpeed Insights (externer Link) . Es gibt zwar noch viele weitere Tools um die Ladezeiten einer Webseite zu messen, aber ich habe mich sehr an das Tool gewöhnt. Schlussendlich bleibt es aber dir überlassen, welches du nimmst. Wichtig ist nur, dass du vorher und nachher das die gleiche Software verwendest und damit nicht Äpfel mit Birnen vergleichst.

In den Tiefen Wurzeln von Google (quasi ab Seite 4) entdeckte ich dann einen Beitrag der darauf hin wies, dass die Verwendung von bind mounts unterDocker häufig zu Performance Problemen führen kann. Gerade bei Webseiten soll, so die Informationen, immer nur eine Datei gleichzeitig geöffnet werden. Das beeinträchtigit die WordPress Docker Performance dann sehr.

Ich wollte diesen Blog also nicht direkt umstellen, sondern testete erst einmal mit einer neuen Installation und siehe da: Es rannte!

Entsprechend habe ich in meinerdocker-compose.yaml (externer Link) Datei ein zweites Volume hinzugefügt und den Stack neu gestartet. Anschließend über die CLI unter Linux die Dateien vom bind mount in das Volume kopiert.

Docker bietet zwar mitdocker cp ein eigenen CLI Befehl, allerdings wollte ich das direkt am Linux System machen. Ob das gut ist, wird sich noch raus stellen.

Mittels

cp -R{bind mount pfad}/* /var/lib/docker/volumes/{volume id}/_data/wp-content/chown www-data. -R /var/lib/docker/volumes/{volume id}/_data/

die Daten kopiert und die Rechte angepasst. Nach Neustart des Stacks merke man schon einen deutlichen Performanceboost.

WordPress Docker Performance mit Redis verbessern

Anschließend habe ich direkt noch Redis als Cache hinzugefügt. Mit demPlugin Redis Object Cache (externer Link) wird das dann unter WordPress aktiviert. In meiner Compose Datei habe ich natürlich erst noch den Redis Container hinzugefügt:

wordpress-cache:image:redis:latestcontainer_name:teqqyde-cacherestart:unless-stoppeddepends_on:-wordpress-appnetworks:-default

Unter Docker findet das Plugin den Redis Server nicht. Also muss noch die wp-config.php Datei angepasst werden

vim /var/lib/docker/volumes/{volume id}/_data/wp-config.php

Dort fügen wir unter den ganzen anderen „define“ Variablen noch die Zeile

define( 'WP_REDIS_HOST', 'wordpress-cache');

hinzu. Nun wieder den Stack komplett neu starten und das Plugin aktivieren. Nach kurzer Zeit gibt es auch bereits die ersten Informationen in den Metriken.

Sicherlich gibt es noch weitere Punkte um die WordPress Docker Performance zu verbessern, allerdings reicht mir diese erst einmal aus.

WordPress Docker Performance messen

Um nun zu überprüfen ob die Performance gestiegen ist, können wir erneut mit dem Google Page Speed Insights die Webseite messen. In meinem Fall bin ich in fast allen Punkten in kleines Stück besser geworden. Natürlich benötigt man noch weitere Optimierungen, aber für den Anfang ist schon vieles gemacht.

]]>selfhostedwordpressdocker