Einführung: Performance als Anforderung, Nicht als Optional
Web-Performance ist kein Aspekt, den man optimiert, „wenn Zeit ist“. Jede Millisekunde Ladeverzögerung bedeutet verlorene Nutzer. Performance Budgets verwandeln Performance von einem vagen Ziel in eine messbare und automatisierte Einschränkung in der CI/CD-Pipeline.
Was Sie in Diesem Artikel Lernen Werden
- Was Performance Budgets sind und warum sie wichtig sind
- Wie man Budgets in
angular.jsonkonfiguriert - Wie man Lighthouse CI (lhci) installiert und konfiguriert
- Wie man Lighthouse CI mit GitHub Actions integriert
- Wie man Scores über die Zeit verfolgt
- Wie man die Bundle-Größe überwacht
- Wie man den Build bei Regressionen fehlschlagen lässt
1. Was Sind Performance Budgets
Performance-Budget-Metriken
| Metrik | Beschreibung | Empfohlenes Budget |
|---|---|---|
| Bundle-Größe | Gesamtgröße der JS- und CSS-Dateien | Initiales JS < 300 KB (gzip) |
| LCP | Largest Contentful Paint | < 2,5 Sekunden |
| FID/INP | Interaction to Next Paint | < 200 ms |
| CLS | Cumulative Layout Shift | < 0,1 |
2. Performance Budgets in angular.json
3. Lighthouse CI Setup
Unterschied zwischen Error und Warn bei Assertions
Assertions mit Stufe error lassen den Build fehlschlagen. Assertions mit warn erzeugen eine Warnung, blockieren aber nicht die Pipeline.
4. Integration mit GitHub Actions
5. Scores Über die Zeit Verfolgen
6. Überwachung der Bundle-Größe
7. Vergleich mit Alternativen Werkzeugen
8. Build bei Regressionen Fehlschlagen Lassen
Schrittweise Implementierungsstrategie
- Woche 1: Lighthouse CI im
warn-Modus ausführen, um eine Baseline zu sammeln - Woche 2: Schwellenwerte basierend auf der Baseline festlegen (Durchschnitt - 5%)
- Woche 3: Kritische Metriken (LCP, CLS) auf
errorsetzen - Woche 4: Branch Protection Rules aktivieren, um den Lighthouse-Check zu erfordern
Fazit
Wir haben ein vollständiges Performance-Überwachungssystem in der CI/CD-Pipeline aufgebaut.
Im letzten Artikel behandeln wir Überwachung und Alerting für Webanwendungen.







