Ein routinemäßiger Lighthouse-Durchlauf auf der eigenen Seite hat drei unabhängige, kleine Funde zutage gefördert — keiner davon spektakulär für sich allein, aber in Summe ein Nachmittag, der sich gelohnt hat. Kein Redesign, keine neue Architektur: drei gezielte Fixes an drei völlig unterschiedlichen Stellen.
Auf den Punkt: Ein Menü-Button, der für Tastatur und Screenreader nicht sauber funktionierte. Eine CSS-Datei, die unminifiziert ausgeliefert wurde. Ein Logo, das dem Browser nicht mitteilte, dass es die wichtigste Ressource auf der Seite ist. Alle drei Funde kamen aus einem einzigen Lighthouse-Audit, alle drei Fixes waren in wenigen Zeilen Code erledigt.
Fund 1: Ein Button, der keiner war
Das Hamburger-Menü im Header war im Markup ein <div> mit aria-label="Menü öffnen" und aria-expanded="false" — sieht nach einem interaktiven Element aus, ist aber keins. Die axe-Prüfregeln aria-allowed-attr und aria-prohibited-attr markierten das zu Recht: bestimmte ARIA-Attribute dürfen nur auf Elementen mit passender nativer Rolle stehen, ein bloßes <div> bringt diese Rolle nicht mit.
Der Fix war ein Element-Tausch: <div> wurde zu einem echten <button>. Damit kommen Fokus-Reihenfolge, Tastaturbedienung (Enter/Leertaste) und die korrekte Rolle für Screenreader automatisch vom Browser — ohne eine einzige Zeile zusätzliches JavaScript. Der einzige Nebenaufwand: das Projekt fährt bewusst kein Tailwind-Preflight, also brauchte .hamburger ein paar manuelle Browser-Default-Resets (Hintergrund, Rahmen, Schriftart), damit der Button nicht plötzlich wie ein Standard-Button aussieht.
Fund 2: 100 KB CSS, die niemand angefordert hatte
public/css/main.css wurde bislang unverändert ausgeliefert — Kommentare, Einrückungen, alles inklusive. Lighthouse hatte hier rund 20% Einsparpotenzial angemerkt. Der Fix war ein neuer Build-Schritt (scripts/minify-public-css.mjs), der nach dem Astro-Build die CSS-Dateien im dist/-Output über esbuild minifiziert — eine Dependency, die über Vite ohnehin schon im Projekt steckt, kein neues Paket nötig. Die Quelldateien in public/css/ bleiben unangetastet und weiterhin von Hand editierbar.
Die realen Zahlen aus dem aktuellen Build:
Mobile & Desktop
Live nachgemessen aus dem aktuellen Produktions-Build. PSI-Werte: PageSpeed Insights, Desktop-Emulation, Live-Messung vom 12. September 2026 — Barrierefreiheit steht dort auf allen vier gemessenen Seiten (Mobile wie Desktop) konstant bei 100/100.
Fund 3: Das wichtigste Bild der Seite lud wie jedes andere
Lighthouse identifiziert auf jeder Seite ein Largest-Contentful-Paint-Element — bei uns durchgehend das Header-Logo. Die Diagnose "LCP request discovery" stand aber auf 0: Der Browser bekam keinen Hinweis, dass genau dieses Bild bevorzugt geladen werden sollte, und reihte es stattdessen neben Fonts und anderen Requests mit normaler Priorität ein.
Der Fix war ein einziges HTML-Attribut: fetchpriority="high" auf dem <img>-Tag des Header-Logos in Header.astro — bewusst nur dort, nicht am Footer-Logo, das im initialen Viewport ohnehin nie relevant ist.
Was das heute bedeutet — und was wir bewusst nicht angefasst haben
Eine aktuelle Live-Messung auf Desktop zeigt das Gesamtbild: Leistung, Barrierefreiheit, Best Practices und SEO stehen alle bei 100/100. Auf Mobile bleiben Barrierefreiheit, Best Practices und SEO ebenso stabil bei 100/100/100 — nur der reine Leistungs-Zeitwert schwankt zwischen zwei aufeinanderfolgenden Läufen spürbar (in unseren Messungen zwischen 68 und 87), weil die simulierte Drosselung auf gedrosseltem 4G störanfällig für die aktuelle Serverlast bei Google ist. Das ist kein Widerspruch zu den Fixes — es zeigt nur, dass regelbasierte Prüfungen (Barrierefreiheit, SEO) deterministisch sind, während Zeit-Messungen unter simulierter Last es nie ganz sind.
Nicht angefasst haben wir bewusst zwei andere Lighthouse-Hinweise: "unused JavaScript" (die React/Astro-Client-Runtime auf interaktiven Inseln) und "unused CSS" (ein gemeinsames main.css für alle Seiten). Beides sind bewusste Architekturentscheidungen und keine Bugs — client:load sorgt dafür, dass Navigation und Theme-Switch sofort interaktiv sind, und ein gemeinsames Stylesheet spart mehr Requests, als es an ungenutztem CSS kostet. Ein Audit ernst zu nehmen heißt nicht, jeden gelben Balken wegzuklicken — es heißt, die Funde zu verstehen und gezielt die zu beheben, die tatsächlich etwas kosten.