Feedback

Methodik: So misst PerfDelta Core Web Vitals und Pagespeed

Stand: 9. Oktober 2026. Verantwortlich: Christian Schreiber.

Diese Seite beschreibt, woher jede Zahl im Report stammt, unter welchen Bedingungen sie gemessen wird und wo die Messung an Grenzen stößt. Den Test selbst starten Sie im Website Speed Test. Was die einzelnen Metriken bedeuten und wie Sie sie verbessern, erklärt der Ratgeber Core Web Vitals.

Datenquellen: PageSpeed Insights, CrUX und CrUX-Verlauf

Der Report verbindet drei öffentliche Google-Schnittstellen. Sie unterscheiden sich darin, ob sie eine einzelne Seite oder die ganze Domain beschreiben, für welche Geräte sie gelten und welchen Zeitraum sie abdecken. Genau daraus entstehen die meisten Abweichungen zwischen den Abschnitten des Reports.

SchnittstelleEbeneGeräteklasseZeitraumAbschnitt im Report
PageSpeed Insights API, Lighthouseeinzelne SeiteMobil und Desktop getrenntein Lauf zum TestzeitpunktLaborkennzahlen, Seitengewicht, Optimierungshinweise
PageSpeed Insights API, Felddateneinzelne Seite, ersatzweise DomainMobil und Desktop getrenntrollierend 28 TageFelddaten
CrUX APIDomain (Origin)alle Geräte zusammenrollierend 28 Tage, jüngster TagesstandWettbewerbsvergleich
CrUX History APIDomain (Origin)alle Geräte zusammenwöchentliche 28-Tage-Fenster, rund sechs MonateCrUX-Trend

Welche Seiten gemessen werden

Die eingegebene URL ist immer die erste Seite. Danach liest PerfDelta die in der robots.txt angegebene Sitemap, ersatzweise /sitemap.xml und /sitemap_index.xml, und wählt strukturell unterschiedliche Seiten aus: Die URLs werden nach dem ersten Pfadsegment gruppiert, und aus jeder Gruppe wird der Reihe nach eine Seite gezogen. Ein kostenloser Test umfasst drei Seiten. Sie können die weiteren Seiten auch selbst angeben, sie müssen dann auf derselben Domain liegen. Wurde eine Domain schon einmal getestet, misst PerfDelta wieder dieselben Seiten, damit die Ergebnisse über die Zeit vergleichbar bleiben. Blockiert die Website den Abruf der Sitemap oder hat sie keine, wird nur die Startseite gemessen, und der Report weist darauf hin.

Jede Seite wird zweimal gemessen, einmal mit dem Mobil- und einmal mit dem Desktop-Profil der PageSpeed Insights API. Beide Ergebnisse stehen im Report nebeneinander.

Felddaten aus dem Chrome UX Report je Seite und Gerät

Die Felddaten stammen aus dem Chrome UX Report (CrUX), dem Datensatz, den Google von Chrome-Nutzern mit aktivierter Statistikfreigabe sammelt. PerfDelta zeigt das 75. Perzentil von Largest Contentful Paint, Interaction to Next Paint und Cumulative Layout Shift und liest zusätzlich First Contentful Paint und Time to First Byte aus. Das 75. Perzentil bedeutet: Drei Viertel der Seitenaufrufe waren mindestens so schnell wie der angezeigte Wert. CrUX rechnet über ein rollierendes Fenster von 28 Tagen und enthält nur Seiten mit ausreichend Chrome-Traffic.

Fehlen Daten für eine einzelne URL, greift der Report auf die Werte der gesamten Domain zurück und kennzeichnet das als „Domain-Daten“. Liegen auch dafür keine Daten vor, steht im Report „Keine Felddaten verfügbar“. Das passiert häufig nur für eine Geräteklasse: Eine Website mit wenig mobilem Traffic hat dann Desktop-Werte, aber keine mobilen. Für die Domain über alle Geräte zusammen reicht der Traffic trotzdem oft, deshalb kann der Wettbewerbsvergleich Werte zeigen, während die Felddaten-Tabelle für Mobil leer bleibt.

Labordaten aus Lighthouse und die Testbedingungen

Die Labordaten stammen aus einem einzelnen Lighthouse-Lauf über die PageSpeed Insights API (Kategorie Performance). Dazu gehören Largest Contentful Paint, First Contentful Paint, Cumulative Layout Shift, Total Blocking Time, Speed Index, Time to Interactive und die Serverantwortzeit, außerdem das Seitengewicht nach Ressourcentyp und die Drittanbieter-Skripte mit der meisten Rechenzeit im Haupt-Thread.

Lighthouse misst unter festen, simulierten Bedingungen. Die Werte beschreiben deshalb ein Referenzgerät und keinen bestimmten Besucher:

ProfilEmuliertes GerätNetzwerkProzessor
MobilMoto G Power, Bildschirm 412 × 823 px150 ms Latenz, 1,6 Mbit/svierfach verlangsamt
DesktopBildschirm 1350 × 940 px40 ms Latenz, 10 Mbit/sohne Verlangsamung

Die Drosselung wird rechnerisch simuliert (Lighthouse-Standard „simulate“), die Seite selbst lädt auf Googles Infrastruktur. Quelle der Werte ist die Lighthouse-Konfiguration im öffentlichen Quellcode des Projekts. Ein einzelner Laborlauf kann von Messung zu Messung schwanken; die Felddaten sind das stabilere Signal.

Felddaten und Labordaten weichen aus drei Gründen ab

Wer die Abschnitte eines Reports nebeneinander liest, findet für dieselbe Metrik oft unterschiedliche Werte. Sie gehen auf drei Unterschiede zwischen den Datenquellen zurück:

Ein Beispiel aus einem Report vom 2. Oktober 2026: Die Startseite einer Agentur-Website hatte am Desktop einen LCP von 1557 ms. Der Wettbewerbsvergleich zeigte für die ganze Domain über alle Geräte 1500 ms, der CrUX-Trend für die letzte Woche 1412 ms. Alle drei Werte sind korrekt, sie beantworten nur unterschiedliche Fragen.

Zwischen Feld und Labor kommt ein vierter Unterschied hinzu: Lighthouse misst einen einzelnen Ladevorgang auf einem Referenzgerät, die Felddaten fassen echte Besuche auf sehr unterschiedlichen Geräten und Verbindungen zusammen. Ein guter Laborwert garantiert deshalb keine guten Felddaten und umgekehrt.

Schwellenwerte und Bestehensregel

Metrik (Feld, 75. Perzentil)GutVerbesserungswürdigSchlecht
Largest Contentful Paint≤ 2,5 s≤ 4,0 s> 4,0 s
Interaction to Next Paint≤ 200 ms≤ 500 ms> 500 ms
Cumulative Layout Shift≤ 0,1≤ 0,25> 0,25

Das sind die Core-Web-Vitals-Schwellen von Google. Eine Seite besteht, wenn alle drei Werte im guten Bereich liegen. Eine Metrik, die CrUX für eine Seite nicht ausweist, etwa INP bei zu wenigen Interaktionen, wird nicht gegen die Seite gewertet. Eine Seite ganz ohne Felddaten besteht nicht. „x von y Seiten bestehen“ zählt je Gerätetyp über die Seiten, für die Felddaten vorliegen.

Die Laborwerte werden nach den Lighthouse-Schwellen bewertet, unter anderem First Contentful Paint 1,8 s / 3,0 s, Total Blocking Time 200 ms / 600 ms und Speed Index 3,4 s / 5,8 s (gut / schlecht).

Wettbewerbsvergleich über die CrUX-Domainwerte

Wettbewerber-Domains werden nicht im Labor getestet. Für sie fragt PerfDelta die CrUX API für die gesamte Origin ab und zeigt das 75. Perzentil von LCP, INP und CLS, zusammengefasst über alle Gerätetypen. Die eigene Domain steht mit demselben Wert in der ersten Zeile, damit der Vergleich auf gleicher Grundlage läuft. Liefert die Domain ohne „www.“ keine Daten, wird die Variante mit „www.“ abgefragt, weil CrUX beide als getrennte Origins führt.

Wie viele Wettbewerber ein Report zeigt, hängt vom Tarif ab: zwei im kostenlosen Test, drei bei Solo, fünf bei Agency und zehn bei Scale.

Vergleichszeilen ergänzen die Tabelle:

Unter der Tabelle steht Ihre Position: der Anteil der gemessenen Websites, deren Wert schlechter ist als Ihrer, je Metrik, unter allen Domains und unter den Domains Ihrer Plattform. Er wird aus 21 Punkten der Verteilung (jedes fünfte Perzentil) interpoliert und zwischen 1 und 99 Prozent angegeben.

Eine zweite Tabelle zeigt die Felddaten nur von Smartphones, weil Google sie für die mobile Suche heranzieht, für Ihre Domain und Ihre Wettbewerber. Der Trend vergleicht den jüngsten Wochenwert mit dem Wert zwölf Wochen davor; Veränderungen unter fünf Prozent gelten als stabil. Die Werte stammen aus denselben zwischengespeicherten CrUX-Abfragen wie der kostenlose Core Web Vitals Benchmark.

CrUX-Trend: wöchentliche 28-Tage-Fenster über sechs Monate

Der CrUX-Trend stammt aus der CrUX History API und zeigt die Domain über alle Geräte zusammen. Jeder Punkt ist ein eigenes 28-Tage-Fenster, das am Ende der jeweiligen Woche schließt. Benachbarte Punkte überlappen sich deshalb zum großen Teil, und der Verlauf reagiert auf eine Änderung an der Website langsam und gleichmäßig. Google stellt aktuell rund 25 Wochen bereit, das entspricht etwa sechs Monaten.

Die Farbe jedes Punkts zeigt die Bewertung dieser Woche nach den Schwellen oben: grün für gut, gelb für verbesserungswürdig, rot für schlecht. Die grün gestrichelte Linie markiert die Grenze zu „gut“ und liegt immer im sichtbaren Bereich. Die rot gestrichelte Linie zur Grenze „schlecht“ erscheint, sobald die Werte sie erreichen. Ohne diese Linien würde die automatisch skalierte Achse kleine Schwankungen guter Werte wie große Ausschläge aussehen lassen.

Der Wert oben rechts in jeder Karte ist der jüngste Wochenwert. Er kann leicht vom Wettbewerbsvergleich abweichen, weil dieser den jüngsten Tagesstand nutzt.

Weltweiter Benchmark, Branchen- und Plattform-Benchmarks

Als weltweiter Vergleichswert dient der Anteil der Websites, die alle drei Core Web Vitals bestehen: 48 Prozent mobil und 56 Prozent am Desktop, laut HTTP Archive Web Almanac 2025 auf Basis von CrUX-Daten (Stand November 2025). Die Bestehensquoten aus den eigenen Messungen von PerfDelta zeigen die Website-Speed-Statistiken.

Für die Branchen-Benchmarks wird jede gemessene Domain einer von 18 Branchen zugeordnet: zuerst anhand des schema.org- und Open-Graph-Markups, dann über eine Einordnung des Seiteninhalts durch ein Sprachmodell (Titel, Beschreibung, Überschriften und ein kurzer Textauszug) und erst zuletzt anhand des Technologie-Stacks. Domains aus den kuratierten Messlisten von PerfDelta, die sich so nicht zuordnen lassen, behalten die Branche aus der Liste. Im Abgleich stimmten Liste und Sprachmodell bei neun von zehn Domains überein. Die Zuordnung ist eine Schätzung und wird alle 30 Tage oder bei geändertem Inhalt erneuert. Je Branche fließt der jeweils jüngste Test jeder Domain ein. PerfDelta berechnet daraus einmal täglich die Bestehensquote, den durchschnittlichen mobilen Lab-Score und das 25., 50. und 75. Perzentil jeder Metrik und speichert einen Wert je Monat für die Historie. Eine Branchenseite erscheint erst, wenn mindestens 30 Domains einfließen. Beispielmessungen stehen dort ohne Domainnamen. Für den Plattformvergleich, etwa nach CMS, gelten dieselben Regeln. Die aktuellen Bestehensquoten je Plattform zeigt der Core Web Vitals Benchmark.

Optimierungshinweise und KI-Auswertung

Die Empfehlungen im Report beruhen auf den Lighthouse-Optimierungsmöglichkeiten mit einer möglichen Einsparung von mindestens 100 ms, der längsten Phase des Largest Contentful Paint auf der Seite mit dem langsamsten LCP, den Drittanbietern und Skript-Bundles mit der meisten Hauptthread-Zeit oder dem meisten ungenutzten Code, langer Skriptausführung als Laborersatz für die Interaction to Next Paint und den Elementen, die Layout-Verschiebungen auslösen. Weist Lighthouse nur Bytes aus, rechnet PerfDelta die Einsparung mit der Übertragungsrate einer langsamen 4G-Verbindung in Zeit um und kennzeichnet sie als Schätzung. Die Zahl am Titel sagt, was sie misst: geschätzte Einsparung, ungenutzte Bytes, Hauptthread-Zeit, Blockierzeit, Dauer einer LCP-Phase oder den CLS-Wert.

Die Reihenfolge richtet sich zuerst nach den Felddaten: Maßnahmen für einen Core-Web-Vitals-Wert, der bei echten Nutzern durchfällt, stehen oben, danach zählt die größere mögliche Einsparung.

Die Texte stammen aus der Maßnahmen-Bibliothek von PerfDelta: kuratierte Texte für jede Art von Befund, mit Varianten für Plattformen wie WordPress und Shopify. Fehlende Varianten für eine Plattform oder einen Drittanbieter schreibt ein Sprachmodell; sie werden in der Bibliothek gespeichert und lassen sich dort prüfen, der nächste Report mit demselben Befund nutzt den gespeicherten Text. Das Modell erhält nur die Art des Befunds, die erkannte Plattform und den Namen des Dienstes, keine URLs und keine Messwerte, und fügt keine Zahlen hinzu. Zahlen, Dateien, Seiten und Geräte stammen immer aus der Messung. Die Modelle stammen von Mistral AI und, für im Hintergrund geschriebene Texte, von OVHcloud AI Endpoints. Die Branchenzuordnung übernimmt Mistral AI.

Die Vergleichswerte unter einer Maßnahme stammen aus den eigenen Messungen: wie häufig der Befund auf den gemessenen Websites vorkommt und welche Einsparung dort typisch ist. Taucht eine Maßnahme aus einer Messung in der nächsten Messung derselben Seiten nicht mehr auf, hält PerfDelta die Veränderung der zugehörigen Laborkennzahl fest (LCP, Total Blocking Time für INP, CLS). Ab zehn solchen Beobachtungen zeigt der Report den Median der Veränderung. Das ist eine Beobachtung und kein Ursachennachweis, weil sich zwischen zwei Messungen auch anderes ändern kann.

Hat eine Messung einen Vorgänger mit gespeicherten Seitendaten, nennen Report und Monitoring-Alerts, was sich zwischen beiden geändert hat: Seitengewicht je Ressourcentyp, neue oder schwerere Drittanbieter und Skript-Bundles, ein anderes LCP-Element, LCP-Phasen, Serverantwortzeit und neue Befunde.

Den Technologie-Stack erkennt PerfDelta aus dem HTML und den Headern der Startseite anhand der offenen Signaturen des Projekts webappanalyzer; Skripte und die gerenderte Seite werden dabei nicht ausgewertet.

Monitoring, Monatsbudget und wiederholte Messungen

Ein kostenloser Test ist eine einzelne Messung. Reports bleiben 365 Tage abrufbar und werden danach gelöscht. Ohne Konto lässt sich eine Domain höchstens einmal in 60 Minuten neu messen. Ein kostenloses Konto erlaubt eine Messung pro Tag mit bis zu drei Seiten.

In den bezahlten Tarifen misst PerfDelta die URLs eines Projekts automatisch und mit genau dem Verfahren, das auf dieser Seite beschrieben ist. Grundlage ist ein Monatsbudget an Pagespeed-Abfragen. Jede Abfrage ist ein Lighthouse-Lauf für eine URL auf einem Gerät, eine URL auf Mobil und Desktop kostet also zwei. Aus demselben Budget buchen das Monitoring, manuelle Messungen in der App, Messungen über MCP und, ab Agency, über die REST-API.

TarifURLsPagespeed-Abfragen pro MonatWählbarer TaktManuell höchstens pro Tag
Solobis 25600täglich, wöchentlich120
Agencybis 1504.000alle sechs Stunden, täglich, wöchentlich800
Scalebis 50012.000alle sechs Stunden, täglich, wöchentlich2.400

Takt und Gerät (Mobil, Desktop oder beide) legen Sie je Projekt fest. Reicht das Budget nicht für alle Einstellungen, bekommt zuerst jede überwachte URL eine wöchentliche Messung, danach werden die URLs in der Reihenfolge, in der sie angelegt wurden, auf den gewählten Takt hochgestuft. Was nicht mehr passt, misst PerfDelta seltener; die Projektseite zeigt das je URL an. Wöchentliche Messungen verteilen sich über die Wochentage, damit nicht alle am selben Tag laufen.

Das Monitoring hat Vorrang: Eine manuelle Messung, auch über MCP oder die API, startet nur, wenn sie den Bedarf des Monitorings bis Monatsende nicht anschneidet. Zusätzlich gilt für manuelle Messungen ein Tagesdeckel von einem Fünftel des Monatsbudgets. Am Monatsersten steht das Budget wieder voll bereit.

Verschlechtert oder verbessert sich eine überwachte URL deutlich, geht eine E-Mail an den Kontoinhaber. Auf Wunsch fasst ein Wochenreport die Entwicklung eines Projekts zusammen; er liest nur gespeicherte Messwerte und löst keine zusätzlichen Messungen aus. Die Felddaten ruft PerfDelta für jede überwachte URL täglich direkt über die CrUX-API ab, auch für selten gemessene URLs; sie kosten keine Pagespeed-Abfrage, und Google aktualisiert CrUX einmal am Tag.

Grenzen der Messung

Fragen zur Methode beantworte ich gern über das Kontaktformular.

Häufige Fragen zur Messmethode

Warum zeigt PageSpeed Insights andere Werte als PerfDelta?

PerfDelta fragt dieselbe PageSpeed Insights API ab. Unterschiede entstehen, weil jeder Lighthouse-Lauf leicht schwankt und weil sich die Felddaten täglich mit dem 28-Tage-Fenster verschieben. Zwei Abrufe zu verschiedenen Zeitpunkten liefern deshalb selten identische Zahlen.

Warum fehlen mobile Felddaten, obwohl die Domain Werte hat?

CrUX weist Werte nur aus, wenn genug Chrome-Nutzer eine Seite besucht haben. Für eine einzelne Geräteklasse reicht der Traffic oft nicht, für die gesamte Domain über alle Geräte zusammen dagegen schon. Der Wettbewerbsvergleich zeigt diesen Domainwert.

Warum ändert sich der Lighthouse-Score bei jedem Test?

Lighthouse simuliert ein Gerät und eine Verbindung, misst aber auf echter Hardware in einem Google-Rechenzentrum. Serverlast, Netzwerk und Drittanbieter-Skripte verändern sich von Lauf zu Lauf. Schwankungen von einigen Punkten sind normal.

Wie schnell zeigt sich eine Verbesserung in den Felddaten?

Die Felddaten fassen die letzten 28 Tage zusammen. Eine Verbesserung wirkt deshalb schrittweise und ist nach etwa vier Wochen vollständig sichtbar. Im CrUX-Trend lässt sich der Verlauf Woche für Woche verfolgen.

Was zählt für das Google-Ranking, Felddaten oder Labordaten?

Google nutzt für die Core Web Vitals als Rankingsignal die Felddaten aus dem Chrome UX Report. Die Labordaten erklären, woran eine langsame Seite liegt, fließen aber nicht direkt in das Ranking ein.

Eigene Werte testen

Ein kostenloser Scan misst Ihre Seiten genau so, wie hier beschrieben.

Kostenlosen Test starten