# Metriken verstehen

Real User Monitoring sammelt einen umfassenden Satz an Leistungsmetriken von tatsächlichen Besuchern. Diese Anleitung erklärt jede Metrik, was sie bedeutet und wie sie verbessert werden kann.

### Core Web Vitals

Dies sind Googles offizielle Metriken zur Messung der Benutzererfahrung und werden als Ranking-Faktoren für Suchergebnisse verwendet.

#### Largest Contentful Paint (LCP)

**Was sie misst**: Die Zeit, wenn das größte sichtbare Inhaltselement (Bild, Video oder Textblock) im Viewport sichtbar wird.

**Warum sie wichtig ist**: LCP repräsentiert die wahrgenommene Ladegeschwindigkeit. Benutzer betrachten eine Seite als "geladen", wenn der Hauptinhalt sichtbar ist.

**Schwellenwerte**:

* 🟢 **Gut**: ≤ 2,5 Sekunden
* 🟡 **Verbesserungsbedarf**: 2,5 - 4,0 Sekunden
* 🔴 **Schlecht**: > 4,0 Sekunden

**Häufige Ursachen für schlechte LCP**:

* Große, nicht optimierte Bilder
* Langsame Server-Antwortzeiten
* Render-blockierendes JavaScript und CSS
* Langsame Ressourcen-Ladezeiten

**Wie verbessern**:

* Bilder optimieren und komprimieren
* smoxy's Bildoptimierungsfunktionen nutzen
* Browser-Caching aktivieren
* CDN verwenden (smoxy macht das automatisch)
* Lazy Loading für Below-the-Fold-Bilder implementieren
* Server-Antwortzeit minimieren (TTFB)

#### Interaction to Next Paint (INP)

**Was sie misst**: Die Reaktionsfähigkeit einer Seite auf Benutzerinteraktionen - wie schnell die Seite auf Klicks, Tipps und Tastatureingaben reagiert.

**Warum sie wichtig ist**: INP misst, wie schnell Benutzer mit der Seite interagieren können. Hohe INP bedeutet, dass Benutzer Verzögerungen beim Klicken auf Schaltflächen oder Links erleben, was zu Frustration führt.

**Schwellenwerte**:

* 🟢 **Gut**: ≤ 200 Millisekunden
* 🟡 **Verbesserungsbedarf**: 200 - 500 Millisekunden
* 🔴 **Schlecht**: > 500 Millisekunden

**Häufige Ursachen für schlechte INP**:

* Schwere JavaScript-Ausführung, die den Hauptthread blockiert
* Große JavaScript-Bundles
* Lang laufende Event-Handler
* Nicht optimierte Drittanbieter-Skripte

**Wie verbessern**:

* Lange JavaScript-Aufgaben aufteilen
* Web Workers für schwere Berechnungen nutzen
* Drittanbieter-Skripte minimieren
* Event-Handler optimieren
* JavaScript-Minifizierung in smoxy aktivieren
* Code-Splitting nutzen, um Bundle-Größen zu reduzieren

#### Cumulative Layout Shift (CLS)

**Was sie misst**: Visuelle Stabilität - wie viel sich der Inhalt unerwartet verschiebt, während die Seite lädt.

**Warum sie wichtig ist**: Unerwartete Layout-Verschiebungen führen dazu, dass Benutzer versehentlich auf falsche Elemente klicken oder ihre Leseposition verlieren, was eine frustrierende Erfahrung schafft.

**Schwellenwerte**:

* 🟢 **Gut**: ≤ 0,1
* 🟡 **Verbesserungsbedarf**: 0,1 - 0,25
* 🔴 **Schlecht**: > 0,25

**Häufige Ursachen für schlechte CLS**:

* Bilder ohne Dimensionen (width/height-Attribute)
* Anzeigen, Embeds oder iframes ohne reservierten Platz
* Web-Schriften, die zu Text-Reflow führen (FOIT/FOUT)
* Dynamisch eingefügte Inhalte
* Animationen, die Layout-Änderungen auslösen

**Wie verbessern**:

* Immer `width` und `height` Attribute für Bilder und Videos angeben
* Platz für Anzeigen und Embeds mit CSS reservieren
* `font-display: optional` oder `font-display: swap` für Web-Schriften nutzen
* Vermeiden, Inhalte über bestehendem Inhalt einzufügen
* CSS-Transforms für Animationen verwenden statt Eigenschaften, die Layout auslösen

### Seiten-Timing-Metriken

#### Time to First Byte (TTFB)

**Was sie misst**: Die Zeit von der Browser-Anfrage bis zum Empfang des ersten Bytes der Antwort vom Server.

**Warum sie wichtig ist**: TTFB repräsentiert die Server-Verarbeitungszeit und Netzwerklatenz. Sie ist die Grundlage für alle anderen Leistungsmetriken.

**Schwellenwerte**:

* 🟢 **Gut**: < 200 Millisekunden
* 🟡 **Akzeptabel**: 200 - 500 Millisekunden
* 🔴 **Schlecht**: > 500 Millisekunden

**Wie verbessern**:

* Server-seitigen Code und Datenbankabfragen optimieren
* Server-seitiges Caching nutzen
* HTTP/2 oder HTTP/3 aktivieren
* CDN verwenden (smoxy stellt das bereit)
* Origin-Server-Leistung optimieren
* Server-seitige Verarbeitungszeit reduzieren

#### First Contentful Paint (FCP)

**Was sie misst**: Die Zeit, wenn das erste Inhaltsstück (Text, Bild, SVG oder Canvas) auf dem Bildschirm gerendert wird.

**Warum sie wichtig ist**: FCP gibt Benutzern Feedback, dass die Seite lädt, und reduziert die wahrgenommene Ladezeit.

**Schwellenwerte**:

* 🟢 **Gut**: < 1,8 Sekunden
* 🟡 **Verbesserungsbedarf**: 1,8 - 3,0 Sekunden
* 🔴 **Schlecht**: > 3,0 Sekunden

**Wie verbessern**:

* Render-blockierende Ressourcen reduzieren
* Kritisches CSS inline einfügen
* Wichtige Ressourcen vorladen
* Server-Antwortzeit minimieren
* Text-Komprimierung aktivieren (smoxy macht das automatisch)

#### Total Blocking Time (TBT)

**Was sie misst**: Die Gesamtzeit während des Seitenladens, wenn der Hauptthread lange genug blockiert war, um die Eingabe-Reaktionsfähigkeit zu verhindern.

**Warum sie wichtig ist**: Hohe TBT bedeutet, dass die Seite geladen erscheint, aber nicht auf Benutzereingaben reagiert.

**Schwellenwerte**:

* 🟢 **Gut**: < 200 Millisekunden
* 🟡 **Verbesserungsbedarf**: 200 - 600 Millisekunden
* 🔴 **Schlecht**: > 600 Millisekunden

**Wie verbessern**:

* JavaScript-Ausführungszeit reduzieren
* Lange Aufgaben in kleinere aufteilen
* Ungenutztes JavaScript entfernen
* Drittanbieter-Code minimieren
* Code-Splitting und Lazy-Loading nutzen

### Ressourcen-Timing-Metriken

#### Seitenladezeit

**Was sie misst**: Die Gesamtzeit vom Navigationsstart bis zum vollständigen Laden der Seite (einschließlich aller Ressourcen).

**Warum sie wichtig ist**: Gesamtleistungsindikator der Seite.

**Ziel**: < 3 Sekunden für gute Benutzererfahrung

#### Server-Antwortzeit

**Was sie misst**: Zeit, die auf den Server gewartet wird, um die initiale HTML-Antwort zu generieren und zu senden.

**Warum sie wichtig ist**: Langsame Server-Verarbeitung verzögert alles andere.

**Wie verbessern**:

* Datenbankabfragen optimieren
* Server-seitiges Caching nutzen
* Bei Bedarf Server-Ressourcen erweitern
* Application-Performance-Monitoring implementieren

#### Content-Transfer-Zeit

**Was sie misst**: Zeit, die für das Herunterladen des initialen HTML-Dokuments benötigt wird.

**Warum sie wichtig ist**: Große HTML-Dateien verlangsamen das initiale Rendering.

**Wie verbessern**:

* HTML-Größe minimieren
* Gzip/Brotli-Komprimierung aktivieren (smoxy macht das)
* Inline-Skripte und -Styles reduzieren

#### Gesamtgröße in Bytes

**Was sie misst**: Gesamtgröße aller auf der Seite geladenen Ressourcen (HTML, CSS, JavaScript, Bilder, Schriften usw.).

**Warum sie wichtig ist**: Größere Seiten brauchen länger zum Herunterladen, besonders bei langsameren Verbindungen. Jedes Megabyte zählt für mobile Benutzer.

**Schwellenwerte**:

* 🟢 **Gut**: < 1 MB
* 🟡 **Akzeptabel**: 1-3 MB
* 🔴 **Schwer**: > 3 MB

**Wie verbessern**:

* Bilder mit smoxy's Bildoptimierung optimieren und komprimieren
* CSS und JavaScript minifizieren (in smoxy-Einstellungen aktivieren)
* Ungenutzten Code entfernen
* Moderne Bildformate nutzen (WebP, AVIF) (smoxy konvertiert Bilder automatisch)
* Lazy-Loading implementieren
* Responsive Images mit `srcset` nutzen

### Netzwerk-Timing-Metriken

#### DNS-Lookup-Zeit

**Was sie misst**: Zeit zum Auflösen des Domainnamens zu einer IP-Adresse.

**Warum sie wichtig ist**: DNS-Lookups fügen Latenz hinzu, bevor die Verbindung beginnen kann.

**Typische Werte**:

* Gecacht: 0ms
* Erster Besuch: 20-120ms

**Wie verbessern**:

* Schnellen DNS-Anbieter nutzen
* DNS-Prefetching für externe Domains implementieren: `<link rel="dns-prefetch" href="//example.com">`
* Anzahl verschiedener Domains reduzieren, von denen die Seite Ressourcen lädt

#### Initiale Verbindungszeit

**Was sie misst**: Zeit zum Aufbau einer TCP-Verbindung zum Server.

**Warum sie wichtig ist**: Jede neue Verbindung fügt Latenz hinzu.

**Typische Werte**: 20-200ms abhängig von geografischer Entfernung

**Wie verbessern**:

* HTTP/2 oder HTTP/3 für Verbindungswiederverwendung aktivieren
* CDN nutzen, um geografische Entfernung zu reduzieren (smoxy stellt das bereit)
* Anzahl der Domains minimieren
* Connection-Prewarming implementieren: `<link rel="preconnect" href="//example.com">`

#### SSL-Zeit

**Was sie misst**: Zeit zum Abschließen des SSL/TLS-Handshakes.

**Warum sie wichtig ist**: HTTPS fügt Overhead hinzu, ist aber für Sicherheit und HTTP/2 notwendig.

**Typische Werte**: 50-200ms

**Wie verbessern**:

* TLS 1.3 aktivieren (schnellerer Handshake)
* OCSP-Stapling nutzen
* TLS-Session-Resumption implementieren
* Moderne Cipher-Suites verwenden

### Geräte- & Kontext-Daten

#### Gerätetyp

Daten werden automatisch segmentiert nach:

* **Desktop**: Traditionelle Computer
* **Mobile**: Smartphones
* **Tablet**: Tablet-Geräte

**Warum es wichtig ist**: Verschiedene Geräte haben sehr unterschiedliche Leistungsmerkmale. Mobile Geräte haben typischerweise langsamere CPUs und Netzwerkverbindungen.

**Best Practice**: Leistung immer über alle Gerätetypen prüfen, da Mobile oft deutlich schlechter abschneidet.

### Geografische Daten

#### Land, Stadt, Standort

RUM verfolgt, wo sich Benutzer befinden.

**Warum es wichtig ist**:

* Benutzer weiter von Servern entfernt erleben höhere Latenz
* Regionale Leistungsprobleme können identifiziert werden
* CDN-Effektivität kann gemessen werden

**Wie diese Daten nutzen**:

* Regionen mit schlechter Leistung identifizieren
* CDN-Konfiguration optimieren
* Regionale Server-Platzierung für wichtige Märkte erwägen
* Zielgruppen-Verteilung verstehen

### Netzwerkdaten

#### ISP & ASN (Autonomous System Number)

Informationen über den Internet Service Provider des Benutzers.

**Warum es wichtig ist**: Einige ISPs haben konsistent bessere oder schlechtere Leistung zu Servern.

**Wie diese Daten nutzen**:

* ISPs mit schlechter Konnektivität identifizieren
* Regionale Netzwerkprobleme troubleshooten
* Routing für wichtige ISPs optimieren

### Daten interpretieren

#### Das 75. Perzentil

smoxy RUM verwendet das 75. Perzentil (p75) für Core Web Vitals, gemäß Googles Empfehlungen.

**Was das bedeutet**: 75% der Benutzer erleben diesen Wert oder besser. Dies bietet eine ausgewogene Ansicht, die nicht durch Ausreißer verzerrt ist, aber dennoch Benutzer mit langsameren Erfahrungen berücksichtigt.

**Beispiel**: Wenn das LCP p75 bei 2,0 Sekunden liegt:

* 75% der Benutzer sehen LCP von 2,0s oder schneller
* 25% der Benutzer sehen LCP langsamer als 2,0s

#### Gut vs. Schlecht Klassifizierung

Jede Metrik hat Schwellenwerte, die die Leistung klassifizieren:

* **Gut**: Empfohlene Ziele werden erreicht
* **Verbesserungsbedarf**: Nahe an Zielen, könnte aber besser sein
* **Schlecht**: Mindeststandards werden nicht erfüllt

Fokus zuerst darauf, "Schlechte" Metriken auf "Verbesserungsbedarf" zu bringen - diese haben den größten Einfluss auf Benutzererfahrung und SEO.

### Was zuerst optimieren?

#### Prioritätsreihenfolge

1. **Core Web Vitals (LCP, INP, CLS)**
   * Direkter SEO-Einfluss
   * Starke Korrelation mit Benutzerzufriedenheit
2. **TTFB & Server-Antwortzeit**
   * Grundlage für alle anderen Metriken
   * Oft am einfachsten mit Caching zu verbessern
3. **Gesamtgröße in Bytes**
   * Großer Einfluss auf mobile Benutzer
   * Verbessert mehrere Metriken
4. **Blocking-Zeit & INP**
   * Kritisch für Interaktivität
   * Beeinflusst Benutzer-Engagement

#### Quick Wins

Mit diesen wirkungsvollen, einfachen Optimierungen starten:

✅ Bildoptimierung in smoxy aktivieren\
✅ HTML/CSS/JS-Minifizierung in smoxy aktivieren\
✅ `width` und `height` zu allen Bildern hinzufügen\
✅ Browser-Caching aktivieren\
✅ Große Bilder vor dem Upload komprimieren\
✅ Ungenutzte Drittanbieter-Skripte entfernen

### Nächste Schritte

* [Das Dashboard verwenden](https://docs.smoxy.eu/real-user-monitoring/das-dashboard-verwenden) - Lernen, RUM-Daten in smoxy zu navigieren
* [Benutzerdefinierte Dashboards mit Grafana](https://docs.smoxy.eu/real-user-monitoring/benutzerdefinierte-dashboards-mit-grafana) - Eigene Visualisierungen erstellen