Web-Archiv Teil 3: Wallabag-Tuning

Wie die Grundlegende Konfiguration des Reverse Proxy im Synology NAS funktioniert, habe ich in einem anderen Text schon erläutert. Das Setup für Wallabag ist gleich: SSL via Letsencrypt mit HTTP/2, welches man via (Sub)domain auf einen internen Port des NAS umleitet.

Hat man seine (Sub)domain eingerichtet, kann man die Container-Umgebungsvariable SYMFONY__ENV_DOMAIN_NAME nun mit dem korrekten FQDN (dem kompletten Domain-Namen) anpassen. Dies passt dann die internen Wallabag-Links zu CSS und Grafiken entsprechend an. Nach einem Container-Neustart sollte Wallabag nun aus dem Internet unter der gewählten (Sub)domain erreichbar sein.

Dieses Setup funktioniert schnell und ohne viel Fummelei, allerdings ist die Konfiguration nicht wirklich optimal. Zum einen werden die Daten nicht komprimiert an die Clients gesendet, was gerade dann ein Problem sein kann, wenn der Upstream des eigenen Internet-Anschlusses nicht besonders schnell ist: Wallabag lädt dann zwar, aber schnarchlahm. Zum anderen wird kein „Cache-Control“-Header mitgesendet, der einem Browser signalisiert, gewisse unveränderliche Sachen wie CSS und JS-Dateien zu speichern, sodass diese bei einem erneuten Besuch nicht nochmals abgerufen werden müssen.

Beides kann man relativ leicht korrigieren, allerdings nur manuell in der nginx-Konfiguration und nicht in der Synology-GUI.
Schauen wir uns zunächst den Status Quo an. Hierfür bietet sich GTMetrix an, welches die fehlende GZIP-Komprimierung und den Cache bestätigt. GZIP kann man in der nginx-Konfiguration mittels eines kurzen Blocks hinzufügen.

Hierzu öffnet man diese mittels vi /etc/nginx/app.d/server.ReverseProxy.conf und sucht nach dem Wallabag-Domainnamen. Unter den Block mit ssl_certificate_key und add_header fügt man nun den unten gezeigten gzip-Block (i drücken, um in den Einfüge-Modus zu wechseln) ein. Der Beginn des server { sieht nun so aus:

server {
listen 443 ssl http2;
listen [::]:443 ssl http2;

server_name deinname.tld;

ssl_certificate /usr/syno/etc/certificate/ReverseProxy/xxx/fullchain.pem;

ssl_certificate_key /usr/syno/etc/certificate/ReverseProxy/xxx/privkey.pem;

add_header Strict-Transport-Security "max-age=15768000; includeSubdomains; preload" always;

gzip_min_length 1000;
gzip_buffers 4 8k;
gzip_http_version 1.0;
gzip_disable "msie6";
gzip_types text/plain text/css text/xml application/javascript text/javascript application/x-javascript application/xml;
gzip_vary on;
gzip on;
gzip_proxied any;

Diese Werte weisen nginx an, alles vom Typ Javascript, HTML, CSS, XML etc. on the fly zu komprimieren. Die Konfigurations-Datei speichert man nun ab (ESC, dann :wq!) und nach einem nginx-Neustart via sudo nginx -s reload sollte GTmetrix nun anzeigen, dass die gzip-Konfiguration funktioniert. Alternativ kann man dies auch in den Developer-Tools des Lieblings-Browsers sehen. Der msie6-Tag? Hey, gratuliere, wenn du dich an den noch erinnern kannst.

Das Browser-Caching (also die Anweisung an den Browser, sich nicht ändernde Inhalte für eine gewisse Zeit zu speichern) ist ein klein wenig komplizierter, weil man es für die beiden Speicherorte /wallassets/ und /assets/ getrennt angeben muss 1.
Diesen Block fügt man nun unter den eben erstellten gzip-Block ein:

location /wallassets/ {
expires 30d;
add_header Pragma public;
add_header Cache-Control "public";
proxy_pass http://localhost:8887/wallassets/;
proxy_set_header Host $host;
proxy_buffering off;
}
location /assets/ {
expires 30d;
add_header Pragma public;
add_header Cache-Control "public";
proxy_pass http://localhost:8887/assets/;
proxy_set_header Host $host;
proxy_buffering off;
}

Alles, was nun in den beiden Ordnern /assets/ und /wallassets/ liegt, wird nun vom Browser für einen Monat zwischengespeichert. Ein enormer Gewinn bei den Ladezeiten! Der Port muss eventuell anpasst werden, ich verwende 8887.

Danach wieder mittels sudo nginx -s reload nginx neu starten und via GTMetrix checken. Hier sollte nun ein „A“-Note stehen — prima!
Das Problem an dieser Proxy-Config ist, dass das NAS sie bei jedem Neustart wieder überschreibt. Meine (zugegebenermaßen nicht besonders elegante) Lösung sieht so aus:
Nach erfolgreicher Änderung der Konfiguration kopiert man sich diese an einen sicheren Ort, hier bspw. /etc/nginx/:

cp /etc/nginx/app.d/server.ReverseProxy.conf /etc/nginx/server.ReverseProxy.maw

Diese geänderte Konfiguration schreibt man dann mittels eines kleinen Cron-Scripts bei jedem Neustart via Synology-Cron (als root) zurück:

cp /etc/nginx/server.ReverseProxy.maw /etc/nginx/app.d/server.ReverseProxy.conf
nginx -s reload

Achtung: Änderungen, die über die Synology-GUI am Reverse-Proxy-Script getätigt werden, werden hierdurch natürlich ignoriert, außerdem löschen Änderungen via GUI auch die manuelle GZIP-/Cache-Konfiguration, die man dann wieder nachholen muss. Damit solche Änderungen auch einfließen, muss man die Config wieder an einen anderen Ort kopieren und dann wieder zurück schreiben.

Die folgenden Themen werden in der Wallabag-Artikelserie behandelt:
Einleitung —  Auf Vorrat gespeichert: Das eigene Web-Archiv auf dem NAS
Teil 1: Was kann Wallabag?
Teil 2: Wallabag via Docker auf Synology NAS
Teil 3: Wallabag-Tuning
Teil 4: Wallabag und Paywalls
Teil 5: Wallabag-Backup und Versionsupdates
Teil 6: RSS-Import zu Wallabag
Teil 7: Wallabag und eReader
Teil 8: Archivebox und Wallabag

  1. Wenn jemand hier eine bessere Lösung kennt, gerne her damit. Ich bin kein nginx-Profi

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.