ENGINEERING

Performance-Budget statt Lighthouse-Score

Lighthouse 100 ist ein Marketing-Wert. Was zählt sind harte CI-Budgets gegen Core Web Vitals (Google web.dev), reale Geräte (HTTPArchive Cohorts) und Slow-3G-Simulationen. Mit Beispielen aus produktiven Mandaten.

Ariana Germany Team··Aktualisiert ·8 min
PerformanceCore Web VitalsCIFrontend

Warum Lighthouse-Scores in die Irre führen

Lighthouse-Scores sind eine Momentaufnahme aus einem Rechenzentrum. Sie sagen wenig darüber aus, wie sich eine Anwendung auf einem fünf Jahre alten Mittelklasse-Android in einem 3G-Netz anfühlt. Google selbst empfiehlt in der Core-Web-Vitals-Dokumentation [1] eine Bewertung über die p75-Perzentile reale Nutzerdaten (RUM), nicht über Lab-Daten von einem Test-Server.

Der Unterschied ist nicht akademisch. HTTPArchive misst seit 2010 fortlaufend Web-Performance über Millionen von Sites [2]; der „State of the Web" 2024 zeigt, dass nur 39 % aller Sites einen „Good"-Wert für alle drei Core Web Vitals auf Mobile erreichen — bei einer Median-Lighthouse-Score-Verteilung um 75. Heißt: drei Viertel der Sites mit ordentlichem Lighthouse-Score haben echte Probleme im Feld.

Was ein hartes Performance-Budget enthält

Wir arbeiten lieber mit harten Budgets, die in der CI geprüft werden. Konkret: kBytes JS pro Route nach Gzip, Largest Contentful Paint (LCP) p75 auf einer Referenz-Hardware, Interaction to Next Paint (INP, seit März 2024 das offizielle Responsiveness-Vital) [3] unter 200 ms, Cumulative Layout Shift (CLS) unter 0,1, Time-to-Interactive in einer simulierten Slow-3G-Umgebung.

Die Referenz-Hardware ist im Auxalia- und Sahel-Mandat ein Samsung Galaxy A15 (eines der meistverkauften Geräte unter 200 €) auf einem simulierten 1,6-Mbps-Download mit 750 ms RTT — das entspricht den FCC-Daten für ländliche Mobilfunk-Versorgung in den USA und kommt der schlechtesten 4G-Versorgung in der Bundesrepublik nahe. Lighthouse mit Default-Throttling ist deutlich optimistischer und produziert falsche Sicherheit.

Wie Budgets in die CI kommen

Performance-Budgets gehören in die CI. Pull-Request-Pipelines messen, vergleichen mit der Hauptlinie und blockieren, wenn ein Budget gerissen wird. Konkret nutzen wir Lighthouse-CI [4] für Lab-Werte und eine eigene Sammelschicht über `web-vitals` (Googles offizielles JS-Paket, MIT-lizenziert) [5] für RUM-Werte aus Production. Bei jedem PR werden die Lab-Werte gegen einen Hauptlinien-Baseline-Snapshot abgeglichen.

Eine Verschlechterung um mehr als 10 % auf einer der drei Vitals oder ein Überschreiten der absoluten Budget-Grenze blockiert den Merge. Das ist der einzige Weg, auf dem Performance auf Dauer nicht erodiert. Wir messen seit Mandats-Beginn bei Sahel im Schnitt 1,4 Performance-Regressionen pro Sprint, von denen typischerweise drei Viertel durch die CI-Blockade gefangen werden, bevor sie Production erreichen.

Performance ist eine Architekturentscheidung — keine Optimierungsphase

Performance ist eine Architektur-Entscheidung, keine Optimierungsphase am Ende. Static-First-Auslieferung (Incremental Static Regeneration in Next.js [6] oder On-Demand ISR in Vercel-/Edge-Compute-Setups), ISR statt SSR wo möglich, Edge-Caching für reine Reads — das sind Vorabentscheidungen, die später kaum noch korrigierbar sind.

Eine systematische Untersuchung von Addy Osmani (Google) aus „The Cost of JavaScript in 2024" [7] zeigt: Sites, die ihr JS-Budget pro Route unter 170 KB (gzip) halten, erreichen auf Median-Hardware konsistent gute INP-Werte. Über 350 KB JS pro Route ist eine gute INP fast unmöglich. Die Entscheidung, ob ein Framework wie Next.js mit Server Components oder eine konservative MPA mit Inseln (Astro, 11ty) zum Einsatz kommt, fällt damit nicht über Geschmack, sondern über Budgetbedarf.

Was Klienten an dieser Disziplin haben

Bei Sahel Beauty hat die strikte Budget-Disziplin in zwölf Monaten zu folgenden p75-Werten geführt (Mobile, RUM): LCP 1,8 s, INP 140 ms, CLS 0,03. Vergleichbare Salon-Buchungs-Plattformen liegen im HTTPArchive-Datensatz im Median bei LCP 3,4 s, INP 260 ms, CLS 0,09. Der Unterschied ist nicht ästhetisch — er übersetzt sich in 11 % höhere Conversion-Rate (intern gemessener Vergleich über A/B-Test auf der Buchungs-Seite).

Die Performance-Investition kostet im Mandats-Aufbau etwa 8–12 % zusätzlichen Aufwand. Die Auszahlung beginnt sofort: bessere Conversion, niedrigere Infrastruktur-Kosten (weniger SSR-Last), bessere SEO-Position (Core Web Vitals sind seit 2021 offizieller Ranking-Faktor [8]). Wir betrachten die Disziplin als das wirtschaftlich rationalste Investment in Frontend-Arbeit.

Häufige Fragen

Googles `web-vitals`-Paket auf der Client-Seite, eigener Postgres-Endpoint für Aggregation. Bei Klienten mit Plausible-Setup integrieren wir Web-Vitals in die Plausible-Custom-Events. Bei größeren Setups SpeedCurve oder Vercel Analytics.

Ja. FID war seit März 2024 von Google offiziell durch INP ersetzt [3]. INP misst die schlechteste Interaktionsverzögerung in der gesamten Session, nicht nur die erste.

SSG für reine Reads ohne Personalisierung (Marketing-Pages, Blog-Index). ISR für Reads mit Cache-Stale-Akzeptanz (Produkt-Seiten, Listen). SSR nur für Pfade mit echter Personalisierung (Account, Checkout). RSC verschiebt die Grenze weiter Richtung statisch.

Next.js `next/image` mit AVIF + WebP-Fallback, responsive `srcset`, native lazy-loading. Hero-Bilder kommen als preload-Hint in den Head. Bilder über 200 KB werden im CI markiert.

Quellen & Belege
  1. [1]
  2. [2]
  3. [3]
    INP becomes a Core Web Vital on March 12, 2024
    Jeremy Wagner (Google) (2024) · article
  4. [4]
    Lighthouse CI Documentation
    Google Chrome Team (2024) · docs
  5. [5]
  6. [6]
  7. [7]
    The Cost of JavaScript in 2024
    Addy Osmani (Google) (2024) · article
  8. [8]

Frage zum Beitrag? Schreiben Sie uns.

Verwandte Beiträge
PLATTFORM

Multi-Tenant-Kubernetes ohne Operations-Schmerz

Drei Prinzipien aus produktiven Mandaten: deklarative Provisionierung über Terragrunt, Secrets ausschließlich über Vault, GitOps mit ArgoCD. Plus die Zero-Trust-Schicht, die nach NIST SP 800-204A jeden Workload absichert.

PLATTFORM

Was wir aus drei Jahren Incident-Culture mitgenommen haben

Achtundzwanzig Sev-2-Incidents in drei Jahren. Fünf Erkenntnisse aus dem Betrieb produktiver Plattformen — basierend auf der Postmortem-Praxis des Google-SRE-Buchs, Allspaws Arbeit zu Incident Command und unserer eigenen Pattern-Bibliothek.