Performance & Core Web Vitals
Google bewertet seit 2021 die Page Experience als Ranking-Signal — und Nutzer brechen ab, wenn Seiten langsam reagieren. XICTRAQ misst Performance regelmäßig per synthetischem Lighthouse-Lauf (Desktop und Mobil), ergänzt das um reale Browser-Messungen (Web Vitals) Ihrer Besucher — diese werden nach Gerät, Seite und Land aufgeschlüsselt — und zeigt Trend-Charts pro Seite.
# Lighthouse-Scores & Core Web Vitals
Lighthouse Scores
vor 4 Std · DE-1Core Web Vitals
# Funktionen
Synthetisches Monitoring per Lighthouse
XICTRAQ führt Lighthouse selbst in einem Headless-Chromium aus, in zwei Läufen: mit der Desktop-Voreinstellung von Lighthouse und mit dessen Mobil-Vorgabe (Mittelklasse-Handy, simulierte Drosselung). Jeder Lauf ergibt die vier Scores Performance, Accessibility, Best Practices und SEO (je 0–100). Fällt Lighthouse aus, springt eine schnellere Näherung ein, die nur Desktop und ohne Drosselung misst; ihre Noten sind mit denen von Lighthouse nicht gleichzusetzen. Free-Plan alle 24 h, Starter/Business/Agency alle 12 h — der Lauf ist rechenintensiv, daher keine feinere Staffelung. Für Ad-hoc-Läufe steht der manuelle Scan unter /app/scan bereit.
Core Web Vitals aus dem synthetischen Lauf
Jeder Lighthouse-Lauf legt ein cwv-Objekt ab: lcp_ms (Largest Contentful Paint), cls (Cumulative Layout Shift), tbt_ms (Total Blocking Time), si_ms (Speed Index), fcp_ms (First Contentful Paint) und ttfb_ms (Antwortzeit des Hauptdokuments), je für den Desktop- und den Mobil-Lauf. INP setzt eine Interaktion voraus, die ein Labor-Lauf nicht auslöst; festgehalten wird stattdessen tti_ms (Time-to-Interactive). Diese Felder treiben die Core-Web-Vitals-Karte in der Website-Übersicht und sind die Vergleichsgrundlage für Performance-Budgets.
Real User Monitoring (RUM) per Tracker
Ist der XICTRAQ-Tracker installiert, werden TTFB (Server-Antwortzeit), FCP (erstes sichtbares Element), LCP, INP, CLS sowie die vollständige Ladezeit zusätzlich aus den echten Browsern Ihrer Besucher gemessen (per PerformanceObserver, ohne Cookie) und am Engagement-Ping übermittelt — millisekundengenau. Die aggregierte Auswertung folgt dem Google-Standard am 75. Perzentil (p75) und ist nach Gerät, Seite und Land aufgeschlüsselt — mit einer Rausch-Untergrenze von mindestens 3 Messpunkten je Segment. Zusätzlich erscheinen die Werte pro Sitzung direkt im Besucher-Log und in den Performance-Karten. So sehen Sie nicht nur, wie XICTRAQ Ihre Site misst, sondern wie Ihre Nutzer sie erleben.
Feld-Daten aus dem Chrome UX Report (CrUX)
Ergänzend zieht XICTRAQ — sofern für die Origin genügend Daten vorliegen — die öffentlichen p75-Felddaten des Chrome UX Reports: LCP, INP, CLS, FCP und TTFB. Die Aufschlüsselung nach Smartphone, Desktop und Tablet (form_factor) wird zusätzlich abgefragt, erscheint aber nur, wenn CrUX für die einzelne Geräteklasse genug Verkehr hat — eine deutlich höhere Schwelle als für den Gesamtwert der Origin. Hat eine Origin zu wenig Traffic für CrUX, bleibt dieser Block leer und Sie verlassen sich auf den synthetischen Lauf und Ihr eigenes RUM.
Performance-Budgets mit Alert
Pro Website definieren Sie ein Performance-Budget mit beliebiger Kombination dieser fünf Felder: min_score (Lighthouse-Performance ≥ X), max_lcp_ms (LCP ≤ X ms), max_inp_ms (INP ≤ X ms), max_cls (CLS ≤ X) und max_ttfb_ms (TTFB ≤ X ms). max_inp_ms wird gespeichert, aber nur geprüft, wenn ein Lauf einen INP-Wert liefert; der synthetische Lauf liefert keinen, ein reines INP-Budget löst darum weder Alarm noch Entwarnung aus. Geprüft wird gegen die Werte des synthetischen Laufs: mit viewport „desktop“ (Vorgabe) gegen den Desktop-Lauf (lighthouse_scores.cwv), mit „mobile“ gegen den Mobil-Lauf (lighthouse_scores.mobil.cwv), mit „both“ gegen beide. Reißt ein Lauf einen oder mehrere Schwellwerte, legt der Budget-Cron einen Alert vom Typ „performance_budget“ an — Severity „critical“ ab drei verletzten Schwellen, sonst „warning“. Ein 24-Stunden-Dedupe verhindert eine Dauerflut bei anhaltendem Breach: Solange ein offener Performance-Alert jünger als 24 h existiert, wird kein zweiter erzeugt.
Alarm bei eingebrochenem Lighthouse-Score
Auch ohne eigenes Budget meldet XICTRAQ, wenn der Performance-Score deutlich fällt: Liegen zwei Lighthouse-Läufe in Folge mindestens 15 Punkte unter dem Median der bis zu fünf Läufe davor, entsteht ein Alarm vom Typ lighthouse_drop, getrennt nach Mobil und Desktop. Ein einzelner schwacher Lauf löst nichts aus, und verglichen wird nur innerhalb derselben Lighthouse-Version. Liegt ein Lauf wieder höchstens 7 Punkte unter diesem Median, wird der Alarm automatisch aufgelöst. Abbestellen lässt er sich unter Einstellungen → Benachrichtigungen → Performance und JS-Fehler.
Skriptlaufzeit nach Herkunft
Zu jedem Lighthouse-Lauf zeigt die Website-Ansicht, welche Skripte den Hauptthread belegen: die 15 teuersten Skripte über 50 ms, zusammengefasst nach Herkunft und getrennt nach Desktop und Mobil. Aus dem Pfad der Adresse ordnet XICTRAQ Plugins und Themes von Shopware 5 und 6, WordPress, Magento, PrestaShop und Gambio zu, dazu den Kern des Shopsystems, eigene Dateien, Drittanbieter und die Inline-Skripte der Seite. Drittanbieter stehen zusätzlich mit ihrer Übertragungsgröße da. Jede Gruppe lässt sich bis zur einzelnen Datei aufklappen.
Pro-Seite-Tracking (monitored_paths)
Standardmäßig wird die als Website-URL hinterlegte Seite gemessen. Unter Website → Einstellungen → Unterseiten-Monitoring können Sie weitere wichtige URLs hinzufügen (z. B. /produkt, /checkout, /kategorie/schuhe) — für jede läuft dann ein separater Uptime-Zyklus. Die maximale Anzahl richtet sich nach Ihrem Plan: Free 1, Starter 5, Business 25, Agency 100. Über das Limit hinaus lehnt die API mit Status 422 ab.
# Budget definieren
Das Budget wird als JSON-Objekt an der Website gespeichert (Feld performance_budget). Sie setzen nur die Schwellwerte, die Sie überwachen möchten — alle Felder sind optional. Ein Beispiel mit allen fünf Feldern:
{
"min_score": 90, // Lighthouse-Performance-Score >= 90
"max_lcp_ms": 2500, // Largest Contentful Paint <= 2500 ms
"max_inp_ms": 200, // Interaction to Next Paint <= 200 ms (nur mit INP-Messwert)
"max_cls": 0.1, // Cumulative Layout Shift <= 0.1
"max_ttfb_ms": 800 // Time to First Byte <= 800 ms
} Wertebereiche der API-Validierung: min_score 0–100, die ms-Felder 0–60000, max_cls 0–5. Der Budget-Cron läuft alle 6 Stunden und vergleicht die zuletzt gemessenen synthetischen Werte gegen Ihr Budget.