Zwei Werkzeuge liefern zwei Ergebnisse, weil sie unterschiedlich messen und weil keines von beiden zweimal dasselbe liefert. Googles Messwerkzeug Lighthouse, das auch hinter PageSpeed Insights steckt, bremst Netz und Prozessor in der Standardeinstellung nicht wirklich aus. Es lädt die Seite unter deinen Bedingungen und rechnet anschließend hoch, wie lange es auf einem langsamen Handy gedauert hätte. Ein echt gedrosselter Browser wartet dagegen tatsächlich. Dazu schwankt jeder einzelne Lauf. Eine einzelne Zahl ist deshalb keine Ladezeit, sondern eine Momentaufnahme.
Richtig ist ein Protokoll: mehrfach messen, den mittleren Wert und die Spanne nennen, einmal mit echter Drosselung gegenprüfen und das Ergebnis gegen die Werte echter Besucher halten. Dieser Beitrag zeigt, warum das nötig ist und wie es in zwanzig Minuten geht.
Die kurze Antwort: zwei Werkzeuge, zwei Messverfahren
Drei Dinge unterscheiden sich zwischen zwei Werkzeugen. Erstens die Drosselung, also das künstliche Ausbremsen von Netz und Prozessor, damit ein schneller Testrechner sich wie ein durchschnittliches Handy verhält. Zweitens, wer gemessen wird: ein Testgerät in einem Rechenzentrum oder echte Besucher mit ihren Geräten. Drittens, wann gemessen wird: jetzt, einmal, oder verteilt über Wochen.
Wenn zwei Werkzeuge also verschiedene Zahlen zeigen, widersprechen sie sich meistens nicht. Sie beantworten verschiedene Fragen. Das Problem beginnt dort, wo beide Ergebnisse mit demselben Wort beschrieben werden: Ladezeit.
Labordaten und Felddaten sind zwei verschiedene Fragen
Labordaten entstehen in einem Testlauf unter festgelegten künstlichen Bedingungen. Sie sind wiederholbar genug für eine Diagnose und zeigen dir eine Liste von Ursachen, aber sie beschreiben niemandes Besuch.
Felddaten entstehen bei echten Besuchen mit echten Geräten und echten Verbindungen. Google sammelt sie im Chrome User Experience Report, kurz CrUX, zeigt sie für einen rollierenden Zeitraum von 28 Tagen und bewertet nicht den Durchschnitt, sondern das 75. Perzentil, also den Wert, den drei von vier Aufrufen einhalten. Mobil und Desktop werden getrennt bewertet.
Die Arbeitsteilung ist damit klar: Felddaten sagen dir, ob du ein Problem hast. Labordaten sagen dir, woran es liegt. Wer über Ladezeit diskutiert, ohne diese beiden Begriffe zu trennen, diskutiert aneinander vorbei.
Warum Lighthouse hochrechnet statt zu bremsen
In der Standardeinstellung arbeitet Lighthouse mit simulierter Drosselung. Die Seite wird mit der echten Verbindung des Testgeräts geladen, danach schätzt ein Modell, wie lange dieselben Anfragen über eine langsame Mobilverbindung und auf einem langsameren Prozessor gedauert hätten. Das ist schnell und billig, und für einen Vergleich zweier Versionen derselben Seite oft gut genug.
Der Preis dafür: Es ist eine Rechnung, keine Messung. Alles, was sich schlecht modellieren lässt, wird ungenau. Skripte Dritter, die erst nachladen. Antwortzeiten, die der Server unter Last braucht. Dinge, die erst nach einer Interaktion passieren. Zwischenspeicher, die beim zweiten Lauf plötzlich warm sind. Google weist in der Dokumentation selbst darauf hin, dass die Werte schwanken und ein einzelner Lauf keine belastbare Aussage ist.
Die Gegenprobe heißt angewandte Drosselung und steckt in den Entwicklerwerkzeugen deines Browsers. Dort wartet der Browser wirklich und der Prozessor wird wirklich gebremst. Das dauert länger, kommt dem Erlebnis aber näher. Noch näher kommt nur ein echtes Mittelklasse-Handy im Mobilfunknetz, und genau das solltest du einmal pro Quartal in die Hand nehmen.
Woher die Schwankung zwischen zwei Läufen kommt
Dein Server hat Nachbarn, und deren Last ist nicht deine Entscheidung. Caches sind beim ersten Aufruf kalt und beim zweiten warm, sowohl auf dem Server als auch im CDN, also dem Netz aus verteilten Servern, die Inhalte näher am Besucher ausliefern. Skripte Dritter, etwa Chat-Fenster, Karten, Werbepixel oder das Einwilligungsbanner, antworten in jedem Lauf anders schnell. Auf deinem Rechner laufen Programme, die Rechenzeit belegen. Und wenn deine Seite personalisierte Inhalte oder einen Test zweier Varianten ausliefert, misst du nicht einmal zweimal dieselbe Seite.
Daraus folgt der Satz, der die meisten Ladezeit-Diskussionen beendet: Wer einmal misst, misst Zufall. Mit einem einzelnen Lauf lässt sich jede Position belegen, einmal die Zahl für alles in Ordnung, einmal die Zahl für alles kaputt.
So misst du richtig: mehrfach, Median, Spanne
Leg dir ein Protokoll fest und halte dich daran. Immer dieselbe Adresse, inklusive aller Parameter. Mobil und Desktop getrennt. Mindestens fünf Läufe, besser neun. Dann nennst du den Median, also den mittleren Wert einer sortierten Reihe, der robuster ist als der Durchschnitt, weil ein einzelner Ausreißer ihn nicht verzieht, dazu den kleinsten und den größten Wert als Spanne.
Danach ein Lauf mit angewandter Drosselung als Gegenprobe und ein Blick in die Felddaten. Notiere Datum, Werkzeug, Netz und ob der Zwischenspeicher leer war. Diese vier Angaben sind der Unterschied zwischen einer Messung und einem Screenshot.
So klingt dann eine Aussage, die hält: LCP mobil, Median aus neun Läufen, dazu kleinster und größter Wert, dazu der Feldwert der letzten 28 Tage, dazu das Datum. Das ist länger als eine Punktzahl und deutlich schwerer zu widerlegen.
Wenn du einen Startwert brauchst, ohne selbst neun Läufe zu fahren, nimm den Sichtbarkeits-Check. Du trägst Firma, Ziel, Website und ein Social-Profil ein und bekommst kostenlos ein PDF mit Ladezeit, Auffindbarkeit bei Google, Sichtbarkeit in Antwortmaschinen wie ChatGPT und Perplexity, Technik und Inhalt, dazu drei Sofortmaßnahmen. Als Ausgangspunkt reicht das; die eigene Messreihe ersetzt es nicht.
Die Messarten im Vergleich
Eine Zeile in der Tabelle braucht noch eine Erklärung: TTFB steht für Time to First Byte und bezeichnet die Zeit, bis der Server das erste Byte seiner Antwort schickt. Sie gehört nicht zu den bewerteten Kennzahlen, verrät aber, ob dein Problem beim Hosting oder im Browser liegt.
| Messart | Was wirklich gebremst wird | Was du erfährst | Wofür du es nutzt |
|---|---|---|---|
| Lighthouse in der Standardeinstellung | nichts, das Ergebnis wird hochgerechnet | grobe Diagnose und eine Liste möglicher Ursachen | Richtung, Vergleich zweier Versionen |
| angewandte Drosselung im Browser | Netz und Prozessor werden wirklich gebremst | realistischere Dauer eines Ladevorgangs | Gegenprobe für einzelne Werte |
| echtes Mittelklasse-Handy im Mobilfunknetz | nichts simuliert, alles echt | das Erlebnis deiner Besucher | Entscheidungen, die jemand anzweifelt |
| Felddaten aus CrUX | nicht gedrosselt, echte Besuche | wie gut es für drei von vier Aufrufen läuft | Bewertung, ob überhaupt ein Problem besteht |
| Serverantwort, TTFB | nichts | Zeit bis zum ersten Byte der Antwort | Hosting, Caching und Datenbank einordnen |
Welche Zahl du nennst und welche du reparierst
Nach außen nennst du zwei Dinge: den Feldwert und den Median deiner Messreihe mit Spanne. Die Punktzahl eines Messwerkzeugs ist eine gewichtete Zusammenfassung mehrerer Werte und keine Zeitangabe. Sie taugt als Trendlinie, nicht als Ziel, und sie ist der Grund, warum in Meetings über Farben statt über Sekunden geredet wird.
Reparieren tust du nach Ursache. Ein hoher LCP zeigt auf das größte Bild, auf die Serverzeit oder auf Dateien, die das Rendern blockieren. INP, kurz für Interaction to Next Paint, also die Verzögerung zwischen einer Eingabe und der sichtbaren Reaktion, gilt bis 200 Millisekunden als gut und steigt vor allem durch zu viel Skriptarbeit. CLS, die Summe unerwarteter Layoutsprünge, gilt bis 0,1 als gut und entsteht, wenn für Bilder, Banner und Schriften kein Platz reserviert wird.
Ein Teil davon sind Einstellungen, ein Teil ist Bauarbeit an Theme und Templates. Wo die Grenze liegt, merkst du daran, ob dein Baukasten die Änderung überhaupt zulässt; alles darunter ist Webentwicklung. In den Berichten von dato.marketing steht deshalb immer der Median mit Spanne und daneben der Feldwert, nicht die Punktzahl. Und bevor du Budget auf eine langsame Seite lenkst, lies die Zahlen zusammen mit den Kosten pro Anfrage aus dem Performance Marketing, denn dort zeigt sich der Effekt zuerst.
Häufige Fragen
Gestern 92 Punkte, heute 64: ist meine Seite kaputt?
Meistens nicht. So ein Sprung entsteht typischerweise durch die Streuung einzelner Läufe. Prüfe die Felddaten: Sind sie stabil, hat sich für deine Besucher nichts geändert. Wiederhole die Labormessung fünf bis neun Mal, bevor du jemanden alarmierst.
Reicht PageSpeed Insights allein?
Für die Richtung ja, für Entscheidungen nein. Nutze den Bericht, um Ursachen zu finden, und entscheide anhand von Felddaten plus eigener Messreihe. Der Vorteil des Werkzeugs ist, dass es beides auf einer Seite zeigt, sofern für deine Adresse genug Felddaten vorliegen.
Welche Werte soll ich anstreben?
Im Feld und für Mobil getrennt: LCP bis 2,5 Sekunden, INP bis 200 Millisekunden, CLS bis 0,1, jeweils am 75. Perzentil. Diese Schwellen sind von Google dokumentiert. Die Punktzahl darfst du danach ignorieren.
Fazit
Die meisten Ladezeit-Aussagen sind wertlos, weil sie aus einem einzigen hochgerechneten Lauf stammen. Du brauchst nur zwei Gewohnheiten, um das zu ändern: mehrfach messen und Median samt Spanne nennen, und die Werte echter Besucher als Maßstab behandeln. Danach redest du über Sekunden statt über Punkte, und Entscheidungen über Technik, Hosting und Budget halten der nächsten Nachfrage stand.
