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

Last updated

Was this helpful?