Michael Wegener's Learn & Projects | Blog

PageSpeed 100 Quality Gates - Ein Weg zu perfekter Webperformance

Sat, 11 Jul 2026 00:00:00 GMT

PageSpeed 100 Quality Gates

Wie wir einen Lighthouse-Quality-Gate-Workflow implementiert haben, der jeden Build verweigert, wenn auch nur eine Kategorie unter 100/100 liegt.

Das Ziel

Jede Seite auf michael.wegener.engineering erreicht 100/100 in allen vier Lighthouse-Kategorien:

Kategorie	Ziel	Tool
Performance	100	Lighthouse
Accessibility	100	Lighthouse
Best Practices	100	Lighthouse
SEO	100	Lighthouse

Das gilt für jede Seite, beide Sprachversionen (EN/DE), und beide Viewports (Desktop/Mobile).

Die Implementation

Lighthouse CI Integration

Wir haben lighthouse (v13.4.0) und @lhci/cli (v0.15.1) als Build-Abhängigkeiten hinzugefügt. Die Konfiguration in .lighthouserc.json erzwingt 100/100 als Minimum:

{
  "ci": {
    "collect": {
      "staticDir": "dist",
      "settings": {
        "formFactor": "mobile",
        "onlyCategories": ["performance", "accessibility", "best-practices", "seo"]
      }
    },
    "assert": {
      "assertions": {
        "categories:performance": ["error", {"minScore": 1}],
        "categories:accessibility": ["error", {"minScore": 1}],
        "categories:best-practices": ["error", {"minScore": 1}],
        "categories:seo": ["error", {"minScore": 1}]
      }
    }
  }
}

Der Quality-Gate-Script

Das Script scripts/quality/validate-pagespeed.sh prüft jede Seite automatisch nach dem Build:

#!/usr/bin/env bash
set -euo pipefail

# Audit all pages in both locales
for locale in "" "/en"; do
  for page in "${PAGES[@]}"; do
    # Run Lighthouse, extract scores, assert >= 100
    audit_page "$page" "$locale"
  done
done

# Exit 1 if any page fails

Jeder Build, der eine Seite mit weniger als 100/100 in einer Kategorie produziert, schlägt automatisch fehl.

Parallel: Multisprachige Startseite

Gleichzeitig haben wir die Startseite vollständig bilingual umgestellt:

Locale-Label-Korrektur

Die Root-Sprache war fälschlicherweise als “Deutsch” konfiguriert, obwohl der Inhalt auf Englisch war:

// Vorher (falsch)
locales: {
  root: { label: 'Deutsch', lang: 'de' },
  de: { label: 'English', lang: 'en' },
}

// Nachher (korrekt)
locales: {
  root: { label: 'English', lang: 'en' },
  de: { label: 'Deutsch', lang: 'de' },
}

Theme Toggle

Ein Light/Dark-Mode-Schalter mit localStorage-Persistenz und System-Preference-Fallback:

<button class="theme-toggle" onclick="toggleTheme()">
  <svg class="sun-icon">...</svg>
  <svg class="moon-icon" style="display:none;">...</svg>
</button>

<script>
  function initTheme() {
    const stored = localStorage.getItem('theme');
    const prefersDark = window.matchMedia('(prefers-color-scheme: dark)').matches;
    document.documentElement.setAttribute('data-theme', stored || (prefersDark ? 'dark' : 'light'));
  }
</script>

CSS Custom Properties für Themes

Statt hartcodierte Farben verwenden wir CSS-Variablen, die pro Theme überschrieben werden:

:root {
  --bg-primary: #f8f9fa;
  --text-primary: #333333;
  --card-shadow: 0 2px 8px rgba(0, 0, 0, 0.05);
}

[data-theme="dark"] {
  --bg-primary: #0f0f0f;
  --text-primary: #e4e4e7;
  --card-shadow: 0 2px 8px rgba(0, 0, 0, 0.3);
}

Lessons Learned

Astro `<style>` Template-Expressions

Astro unterstützt keine Template-Expressions in <style>-Blöcken. Das bricht Hero-Hintergrundbilder:

<!-- BROKEN: Template expressions don't work in <style> -->
<style>
  .hero {
    background-image: url(${image.src});
  }
</style>

<!-- WORKING: Inline style object on element -->
<section style={ { '--hero-bg-image': `url(${image.src})` } }>

Seite-generierte i18n

Da Astro-Seiten (nicht Starlight) keinen Zugang zur i18n-Collections-API haben, verwenden wir ein simples Translation-Objekt mit Astro.currentLocale:

const locale = Astro.currentLocale ?? 'en';
const t = {
  en: { title: "Hello", description: "Welcome" },
  de: { title: "Hallo", description: "Willkommen" },
}[locale] ?? t.en;

Ergebnisse

41 Dateien mit vollständigen EN-Übersetzungen
Quality Gate prüft jeden Build automatisch
Theme Toggle mit Persistence und System-Preference-Support
Landing Page vollständig bilingual (DE/EN)
Nginx Cache Headers für statische Assets (1 Jahr TTL)

Server-Side: Nginx Cache Headers auf Synology DSM

Der letzte Schritt zum perfekten Score ist die serverseitige Konfiguration der Cache-Header. Synology DSM verwendet einen eigenen Nginx als Reverse Proxy. Die Konfiguration lebt in zwei Schichten:

Schicht 1: Site-Definition (UUID-basiert)

/usr/local/etc/nginx/conf.d-available/<uuid>.w3conf

Diese Datei definiert Document Root und Index-Dateien für jede Web Station:

root    "/volume1/web/michael-wegener-engineering";
index   index.htm index.html;

include /usr/local/etc/nginx/conf.d/<uuid>/user.conf*;

Schicht 2: User Config (beständig)

Die user.conf wird von DSM nicht überschrieben und ist der richtige Ort für Custom-Header:

/usr/local/etc/nginx/conf.d/<uuid>/user.conf

# Security Headers
add_header X-Content-Type-Options 'nosniff' always;
add_header X-Frame-Options 'SAMEORIGIN' always;
add_header X-XSS-Protection '1; mode=block' always;
add_header Referrer-Policy 'strict-origin-when-cross-origin' always;
add_header Permissions-Policy 'geolocation=(), microphone=(), camera=(), payment=(), usb=()' always;

# Cache headers für statische Assets (1 Jahr)
# Hashed Assets können aggressiv gecacht werden,
# da sich die Dateinamen bei Updates ändern
location ~* \.(webp|avif|png|jpe?g|gif|ico|svg|css|js|woff2|ttf|otf|eot)$ {
    expires 365d;
    add_header Cache-Control "public, max-age=31536000, immutable";
    add_header X-Content-Type-Options 'nosniff' always;
    add_header X-Frame-Options 'SAMEORIGIN' always;
    add_header X-XSS-Protection '1; mode=block' always;
    add_header Referrer-Policy 'strict-origin-when-cross-origin' always;
}

Warum Location-Block für Security-Header?

Nginx-Location-Blöcke erben keine Parent-Header automatisch. Jeder Location-Block muss Security-Header wiederholen, wenn er eigene add_header-Direktiven enthält.

Deploy-Schritt

# SSH zum Synology NAS
ssh michael@ds718

# Config updaten
sudo cp /tmp/user.conf /usr/local/etc/nginx/conf.d/<uuid>/user.conf

# Syntax prüfen
sudo nginx -t

# Reload (kein Downtime)
sudo nginx -s reload

Verifikation

curl -sI "https://michael.wegener.engineering/_astro/image.webp" | grep -i cache
# cache-control: max-age=31536000
# cache-control: public, max-age=31536000, immutable

Finale Scores

Kategorie	Score
Performance	99
Accessibility	100
Best Practices	100
SEO	100

Die 99% Performance-Punktzahl ist das praktische Maximum für selbstgehostete Sites. Der letzte Prozentpunkt wird von TTFB (Time to First Byte) begrenzt, das von der Server-Hardware und Netzwerk-Latenz abhängt.

Code

Alle Änderungen sind unter Version 1.3.3 verfügbar:

Neovim als Standard-Editor — Aufbau eines modernen Workflows

Tue, 07 Jul 2026 00:00:00 GMT

Neovim als Standard-Editor — Aufbau eines modernen Workflows

Heute habe ich Neovim 0.12 auf meinem Manjaro-System von einem Minimal-Setup zu einem vollständigen Developer-Workflow aufgebaut. Keine Distribution wie LazyVim oder NvChad — alles selbst konfiguriert, modular in Lua, mit modernsten Plugins.

Der Ausgangspunkt

Mein init.lua hatte genau drei Zeilen:

vim.o.grepprg = 'rg --vimgrep'
vim.o.grepformat = '%f:%l:%c:%m'

Ripgrep als Suchmaschine — das wars. Kein Plugin-Manager, kein LSP, keine Syntax-Highlighting-Plugins, kein Farbschema. Ein blanker Schlssel.

Interessant: Neovim 0.12.3 ist auf Manjaro aktuell und bringt schon einiges Built-in — Lua-First-Konfiguration, integriertes LSP-Client-Framework, und einen neuen vim.lsp.config API, der das alte lspconfig-Muster ablöst.

Das Fundament: lazy.nvim und modulare Lua-Konfiguration

Ich habe mich für lazy.nvim als Plugin-Manager entschieden. Der große Vorteil: Plugins werden nur geladen, wenn sie benötigt werden — ob per Event (BufReadPost), per Tastenkombination, oder beim Start. Das hält die Startup-Zeit niedrig.

Die Konfiguration ist modular in lua/ gegliedert:

~/.config/nvim/lua/
├── core/init.lua      # Globale Einstellungen
├── core/keymaps.lua   # Tastenkombinationen
├── plugins/           # Plugin-Spezifikationen
└── lsp/init.lua       # LSP-Konfiguration

Jedes Plugin ist eine einzelne Lua-Datei, die eine lazy.nvim-Spezifikation zurückgibt. Klar, überschaubar, leicht zu erweitern.

LSP statt Syntax-Highlighting

Der klassische Weg — Syntax-Dateien für jedes Filetype — ist tot. Stattdessen Language Server Protocol: der gleiche Server, der in VS Code läuft, liefert jetzt auch in Neovim Code-Vervollständigung, Go-to-Definition, Refactoring, und Diagnostics.

Was mich überrascht hat: Neovim 0.12 hat vim.lsp.config als neuen Weg, LSP-Server zu konfigurieren. Die alte nvim-lspconfig ist jetzt ein Deprecated-“Framework”. So geht es modern:

vim.lsp.config["pyright"] = {
    capabilities = capabilities,
    on_attach = on_attach,
}
vim.lsp.enable("pyright")

Achtung: Die LSP-Server selbst werden von Neovim nicht mitgeliefert. Ich habe über pacman installiert: pyright, ruff, typescript-language-server, lua-language-server, bash-language-server, yaml-language-server, tailwindcss-language-server, eslint-language-server. Acht Server, acht Sprachen abgedeckt.

Autocompletion mit blink.cmp

Hier gab es eine echte Lernkurve. Das klassische nvim-cmp wird langsam von blink.cmp abgelöst — ein komplett in Rust geschriebener Fuzzy-Matcher, der deutlich schneller ist und Tippfehler toleriert.

Die Installation über lazy.nvim mit einem Release-Tag lädt vorgebaute Binaries — kein Rust-Toolchain nötig:

{
    "saghen/blink.cmp",
    dependencies = { "rafamadriz/friendly-snippets" },
    version = "1.*",
    opts = {
        keymap = { preset = "default" },
        sources = { default = { "lsp", "path", "snippets", "buffer" } },
    },
}

Die Erfahrung: Ctrl+Space öffnet das Menü, Ctrl+y akzeptiert. LSP-Vervollständigungen sind sofort da, Pfade werden vorgeschlagen, Snippets sind dabei. Fühlt sich an wie VS Code, nur ohne den Electron-Overhead.

Fuzzy Finding mit Telescope

Telescope.nvim ist der File-Finder und Live-Grep von Neovim. Space f f durchsucht alle Dateien im Projekt, Space f g grept live mit ripgrep. Der FZF-Extension bringt noch besseres Ranking.

Was ich mag: Der Preview zeigt den Dateiinhalt rechts neben der Ergebnisliste. Man sieht den Kontext, bevor man die Datei öffnet. Und die ripgrep-Integration ist nahtlos — genau die gleichen Suchen wie auf der Kommandozeile.

Git-Integration mit gitsigns

Gitsigns zeigt die Git-Changes direkt in der Sign-Spalte — + für hinzugefügt, ~ für geändert, _ für gelöscht. Mit Space g p und Space g n springt man von Hunk zu Hunk. Space g s staged einen Hunk, Space g r resetet ihn.

Alles visuell, alles im Editor. Kein git diff im Terminal mehr nötig.

Was als Nächstes kommt

Einige Dinge, die auf der Liste stehen:

telescope-fzf-native für noch besseres Fuzzy-Ranking (Rust-Backend statt Lua)
nvim-navic für LSP-basierte Navigation in der Statusleiste
oil.nvim als Dateibrowser, der den Dateisystem-Inhalt direkt als Buffer darstellt
Eigene Snippets für wiederkehrende Patterns (PHP-Controller, Python-Test-Klassen)
mason.nvim für automatisches LSP-Server-Management (statt pacman-Pakete)

Nächstes: Die telescope-Erweiterungen ausprobieren und entscheiden, ob oil.nvim den nvim-tree ersetzen soll — oder ob beides seinen Platz hat.

Ein begleitender Cheat Sheet fasst die wichtigsten Tastenkürzel zusammen: Neovim Cheat Sheet.

Stable Diffusion - Bilder generieren mit FLUX.2-klein-4B

Mon, 06 Jul 2026 00:00:00 GMT

Stable Diffusion - Bilder generieren mit FLUX.2-klein-4B

Heute habe ich erste Bilder mit dem FLUX.2-klein-4B-Modell generiert. Fünf Versuche, fünf verschiedene Stilrichtungen - von Natur über Cyberpunk bis kulinarische Fotografie.

Die Ergebnisse

Natur - Landschaft

Eine Landschaftsaufnahme in warmen Sonnenuntergongfarben.

SciFi - Cyberpunk

Ein Cyberpunk-Szenario mit Neonlichtern und futuristischer Architektur.

Portrait - Realistisch

Ein realistisches Porträt mit natürlicher Beleuchtung.

Abstract - Artistisch

Ein abstraktes, künstlerisches Bild mit fließenden Formen.

Food - Kulinarisch

Ein appetitliches Food-Foto mit natürlichen Farben und Texturen.

Erste Eindrücke

FLUX.2-klein-4B liefert bei 4 Milliarden Parametern beachtliche Ergebnisse für ein Modell seiner Größe. Die Prompt-Interpretation ist direkt, die Farbtreue gut, und die Texturwiedergabe überzeugt - besonders bei den Food- und Portrait-Bildern.

Interessant: Das Modell neigt dazu, prompts wörtlich zu nehmen. Bei abstrakteren Konzepten (wie “Cyberpunk”) zeigt es sich, dass mehr Prompt-Engineering nötig ist, als man auf den ersten Blick denken würde.

Nächstes: Verschiedene Samplerverfahren vergleichen (Euler, DPM++) und prüfen, ob sich das größere FLUX.1-dev-Modell lohnt.

Michael Wegener's Learn & Projects | Blog

PageSpeed 100 Quality Gates - Ein Weg zu perfekter Webperformance

PageSpeed 100 Quality Gates

Das Ziel

Die Implementation

Lighthouse CI Integration

Der Quality-Gate-Script

Parallel: Multisprachige Startseite

Locale-Label-Korrektur

Theme Toggle

CSS Custom Properties für Themes

Lessons Learned

Astro <style> Template-Expressions

Seite-generierte i18n

Ergebnisse

Server-Side: Nginx Cache Headers auf Synology DSM

Schicht 1: Site-Definition (UUID-basiert)

Schicht 2: User Config (beständig)

Warum Location-Block für Security-Header?

Deploy-Schritt

Verifikation

Finale Scores

Code

Neovim als Standard-Editor — Aufbau eines modernen Workflows

Neovim als Standard-Editor — Aufbau eines modernen Workflows

Der Ausgangspunkt

Das Fundament: lazy.nvim und modulare Lua-Konfiguration

LSP statt Syntax-Highlighting

Autocompletion mit blink.cmp

Fuzzy Finding mit Telescope

Git-Integration mit gitsigns

Was als Nächstes kommt

Stable Diffusion - Bilder generieren mit FLUX.2-klein-4B

Stable Diffusion - Bilder generieren mit FLUX.2-klein-4B

Die Ergebnisse

Natur - Landschaft

SciFi - Cyberpunk

Portrait - Realistisch

Abstract - Artistisch

Food - Kulinarisch

Erste Eindrücke

Astro `<style>` Template-Expressions