Performance und Core Web Vitals
Die Seite Performance misst echte Core Web Vitals (PageSpeed Insights), zeigt Real-User-CrUX-Daten, Lighthouse-Diagnosen pro Seite und generiert das Entwickler-Ticket.
Die Seite Performance (Seitenleiste Website-Analyse → Performance) misst die echte Geschwindigkeit deiner Website mit Googles Core Web Vitals und verwandelt die Diagnosen in umsetzbare Anleitungen für den Entwickler. Sie wird vom SEO-Audit gespeist: jeder Scan nimmt eine Stichprobe von Seiten und misst deren Performance; während ein Audit läuft, zeigt die Seite den Fortschritt in Echtzeit. Der Tab Core Web Vitals des Berichts zeigt nur die zusammenfassende Tabelle, mit einem Button, um diese Seite zu öffnen.
Erforderlicher Plan: im SEO-Audit ab dem Plan Solo enthalten. Die Generierung von Entwickler-Tickets hat ein separates monatliches Budget (siehe Tabelle unten).
Wie Core Web Vitals gemessen werden
Die Daten sind echte Google-PageSpeed-Insights-Messungen (mobile Lighthouse), keine Schätzungen: jeder Audit nimmt eine Stichprobe der Startseite + einer Seite pro Typ/Pfad, bis zur Obergrenze des Plans, und misst für jede den Performance-Score, CLS, LCP und TBT.
| Plan | Stichprobenseiten pro Audit |
|---|---|
| Solo | 3 |
| Starter | 5 |
| Pro | 10 |
| Agency | 20 |
Was jede Spalte misst, und die Schwellenwerte, mit denen die App sie einfärbt (grün = gut, gelb = verbesserungswürdig, rot = schlecht):
| Kennzahl | Was sie misst | Gut | Schlecht |
|---|---|---|---|
| Performance-Score | Gesamter Lighthouse-Score (0-100) | ≥ 90 | < 50 |
| LCP — Largest Contentful Paint | Renderzeit des größten sichtbaren Elements | ≤ 2500 ms | > 4000 ms |
| CLS — Cumulative Layout Shift | Wie stark sich Elemente während des Ladens verschieben | ≤ 0,1 | > 0,25 |
| TBT — Total Blocking Time | Wie lange der Hauptthread blockiert und nicht auf Eingaben reagiert | ≤ 200 ms | > 600 ms |
| INP — Interaction to Next Paint | Reaktionsfähigkeit auf echte Eingaben (nur CrUX-Karte) | ≤ 200 ms | > 500 ms |
| TTFB — Time To First Byte | Wie lange der Server zum Antworten braucht (LCP-Diagnose-Spalte) | ≤ 600 ms | darüber: Hosting/Caching |
Lighthouse-Scores können zwischen Audits variieren, auch wenn sich die Website nicht geändert hat (um bis zu 20–30 %): das ist die normale Variabilität von Labor-Tests, von Google dokumentiert. Achte auf den Trend über mehrere Audits, nicht auf die Einzelzahl.
Echte Nutzererfahrung (Chrome UX Report)
Hat die Website genug Traffic, erscheint eine Karte mit CrUX-Daten: LCP, INP und CLS beim 75. Perzentil, gemessen bei echten Chrome-Besuchern der letzten 28 Tage, mit einem Urteil Gut / Verbesserungswürdig / Schlecht. Anders als Lighthouse-Scores sind sie stabil, und sie sind das, was Google für das Ranking nutzt. Das Badge „gesamte Website” bedeutet, dass die einzelne Seite nicht genug Traffic hat und sich die Daten auf die gesamte Domain beziehen.
Lighthouse-Diagnosen pro Seite
Unter den Kennzahlen findest du Lighthouses Rohdiagnosen pro Stichprobenseite: eine Layout-Shift-Map (Screenshot der Stichprobenseite mit den am deutlichsten sichtbaren Verschiebungen, mit Kästen über den Elementen, die sich während des Ladens verschieben — ein gestrichelter Rand um die gesamte Seite deutet auf einen globalen Reflow hin, z. B. durch Webfonts, mit durchgehend markierten Ursachenzonen), die LCP-Diagnose, Elemente, die CLS verursachen mit einer Spalte Ursache (unbemessenes Bild, Webfont, eingefügtes iFrame — Labels auf Englisch, wie von Lighthouse bereitgestellt), nicht optimierte Fonts (FOUT), Bilder ohne Dimensionen und rendering-blockierende Ressourcen.
Die Tabelle LCP-Diagnose zeigt für jede Stichprobenseite, welches Element das größte sichtbare ist (das, was den LCP bestimmt), seine Lade-Phasen — die dominante Phase sagt dir, wo du ansetzen solltest: hoher TTFB = Server oder Caching, Load Delay = Element spät entdeckt oder lazy-loaded, Render Delay = blockierendes CSS oder Fonts — und die Server-Antwortzeit. Sie erscheint nur für Audits, die nach Einführung der Funktion gestartet wurden: siehst du sie nicht, führe einen neuen Audit aus.
Nicht optimierte Fonts (FOUT) listet die Webfonts auf, die einen Flash of Unstyled Text verursachen: die Seite zeigt den Text zunächst in einer Fallback-Schrift und tauscht ihn dann aus, sobald der Webfont eintrifft, mit einem sichtbaren Sprung, der auch als Layout-Shift zählen kann. Meist wird das durch Hinzufügen von font-display: swap und einem preload für die Schrift behoben, oder indem sie von derselben Domain ausgeliefert wird.
Eine leere Tabelle ist kein Fehler. Der CLS-Wert und die Liste „Elemente, die CLS verursachen” stammen aus zwei unabhängigen Lighthouse-Mechanismen: ein hoher CLS ohne aufgelistete Elemente ist normal, typischerweise bei Seiten mit Drittanbieter-Widgets/Kommentaren/Embeds, die Lighthouse keinem bestimmten Knoten zuordnen kann. Ebenso bedeuten leere Tabellen für Bilder ohne Dimensionen oder rendering-blockierende Ressourcen nur, dass Lighthouse bei dieser Stichprobe keine erkannt hat.
Entwickler-Ticket generieren
Entwickler-Ticket generieren verwandelt die Diagnosen in ein Ticket in einfacher Sprache für jede Stichprobenseite, fertig zur Übergabe an einen Entwickler. Das Ticket beginnt mit der Grundursache, abgeleitet aus den Ladephasen, und kreuzt die Lighthouse-Daten mit dem echten HTML der Seite: es nennt die exakten Dateien und Attribute, die geändert werden sollen (zum Beispiel ein loading=lazy, das vom Hauptbild entfernt werden sollte, oder ein fehlendes Preload) und passt den Rat an die erkannte Plattform an, etwa das installierte WordPress-Theme oder Plugins. Es ist On-Demand, wird aber einmal pro Audit generiert (reaktiviert durch erneutes Ausführen des Audits), mit einem monatlichen Budget getrennt von der Seiten-Stichprobe — der Zähler ist unter dem Titel der Seite Performance und in Abonnement sichtbar:
| Plan | AI-Core-Web-Vitals-Tickets / Monat |
|---|---|
| Solo | 4 |
| Starter | 13 |
| Pro | 40 |
| Agency | 200 |
Möchtest du den vollständigen technischen Bericht durchgehen? Zurück zu Deinen ersten SEO-Audit starten →
Zuletzt aktualisiert: 5. September 2026