Lighthouse 100 mit Vibe Coding: Performance ohne Build-Tools

Lighthouse bewertet vier Kategorien: Performance, Accessibility, Best Practices, SEO. Der Performance-Score setzt sich aus fünf gewichteten Metriken zusammen: Total Blocking Time (TBT) 30%, Largest Contentful Paint (LCP) 25%, Cumulative Layout Shift (CLS) 25%, First Contentful Paint (FCP) 10% und Speed Index 10%. TBT allein macht fast ein Drittel aus — und ist der strukturelle Vorteil von Vanilla JS. Und genau hier scheitern Build-Tools: Webpack-generierte Long-Tasks können TBT sprengen. Vanilla JS hat dieses Problem nicht.

Der Median-Lighthouse-Score aller Websites weltweit liegt bei etwa 34 von 100. Weniger als die Hälfte aller Sites besteht alle drei Core-Web-Vital-Schwellenwerte. Das macht die Benchmark-Anforderung eigentlich lösbar — die Baseline ist erschreckend niedrig. Next.js erzielt laut Benchmark im Schnitt 98,6 — das klingt gut, gilt aber für optimierte Setups. In der Praxis liegt der typische Score ohne explizite Optimierung bei 70 bis 90. Vanilla JS liefert 100 mit weniger Aufwand. Zur Einordnung: Der Lighthouse-Median aller Websites weltweit liegt bei etwa 34 von 100. Weniger als die Hälfte aller Sites besteht alle drei Core Web Vital Thresholds. Grove Foundry dokumentiert ein Projekt mit 100/100/100/100 unter 35 KB Seitengewicht — ohne React, ohne Astro, ohne Build-Tools. Der Unterschied: Das JavaScript das du schreibst ist das JavaScript das ausgeliefert wird.

Der Pure Performance Stack

Ein Stack der in der Praxis 100/100/100/100 erreicht — dokumentiert, verifiziert, reproduzierbar:

HTML5 und CSS3 Custom Properties — kein Tailwind, kein Bootstrap, nur semantisches Markup. CSS Grid statt Flexbox für komplexe Layouts. Vanilla JavaScript — kein Compilation-Step, keine Hydration, keine Framework-Runtime. Vercel Edge Network — Content vom nächstgelegenen Node, automatische Kompression, HTTP/2.

Die 7 konkreten Optimierungen

1. Bilder als WebP mit lazy loading. loading="lazy" auf alle Bilder außer dem Hero. WebP spart 25-35 Prozent gegenüber JPEG bei gleicher Qualität.

2. Kein render-blocking JavaScript. defer auf alle externen Scripts. Aber Achtung bei Three.js: Inline-Scripts die auf das CDN angewiesen sind müssen danach kommen, nicht mit defer — diesen Bug haben wir bei while.chat in 15 Artikeln produziert bevor er entdeckt wurde.

3. CSS inline für Above-the-Fold. Critical CSS direkt im Head verhindert Flash of Unstyled Content. Wenn das CSS in den ersten TCP-Round-Trip passt (ca. 14 KB compressed), beginnt der Browser mit dem Rendering etwa 200 Millisekunden nach dem Request. Grove Foundry dokumentiert ein Projekt mit 100/100/100/100 — ohne jedes Framework, unter 35 KB Gesamtgewicht. Wenn das CSS in den ersten TCP-Round-Trip passt (ca. 14 KB compressed), beginnt der Browser mit dem Rendering etwa 200 Millisekunden nach dem Request. Der Rest kann per link rel="stylesheet" nachgeladen werden.

4. Font-Loading-Strategie. display: swap in der Google Fonts URL. preconnect für fonts.googleapis.com und fonts.gstatic.com. Kein @import in CSS — das blockiert den Render.

5. Ressourcen-Hints. preconnect für CDN-Domains (esm.sh für Three.js, cdnjs für Libraries). Spart 100-300ms Verbindungsaufbau.

6. Code-Ausführung verzögern. Alles was nicht sofort gebraucht wird in IntersectionObserver-Callbacks auslagern. Animationen erst starten wenn die Sektion sichtbar wird.

7. Accessibility = Performance. Alle img mit alt-Attributen, Kontrast mindestens 4,5:1, semantische Überschriftenhierarchie, alle interaktiven Elemente per Keyboard erreichbar. Lighthouse-100 in allen vier Kategorien erfordert Accessibility-100. Aber Achtung: Lighthouse fängt nur 30-40 Prozent der Accessibility-Issues durch automatisierte Tests. Manuelle Tests mit Screenreadern bleiben nötig.

Warum Build-Tools den Score gefährden

Webpack generiert Long-Tasks — JavaScript-Blöcke die den Main Thread für mehr als 50ms blockieren. Das ist der TBT-Killer. Die Scores folgen einer log-normalen Kurve: Der Aufwand von 90 auf 95 ist ähnlich gross wie von 95 auf 100. Jeder zusätzliche Drittanbieter-Script verzögert das Page-Rendering um circa 200 Millisekunden. Code-Splitting via dynamic import() kann den initialen Bundle um bis zu 70 Prozent reduzieren. In einem Vanilla-Stack sind diese Techniken unnötig — was nicht geladen wird, kann nicht verlangsamen. Vanilla JS hat per Definition keine Long-Tasks: Dein Code ist so klein dass er in einem Frame parsed und ausgeführt wird.

Der zweite Faktor: Hydration. React-basierte Seiten müssen nach dem Server-Side-Render nochmal auf dem Client "hydriert" werden — der gesamte DOM wird ein zweites Mal durchlaufen. Bei Vanilla JS gibt es keinen Hydration-Overhead. Was der Server liefert, zeigt der Browser an. Punkt.