Ladezeit einer Website richtig messen

Die Ladezeit einer Website misst du richtig, wenn du zwei Arten von Daten kombinierst: Labortests, die deine Seite unter kontrollierten Bedingungen laden und bei der Fehlersuche helfen, und Felddaten, die zeigen, wie schnell die Seite bei echten Besuchern ist. Vor und nach jeder Änderung testest du mit denselben Tools, Seiten und Einstellungen, wiederholst jeden Test mehrmals und bewertest das Ergebnis anhand des Medians und der Nutzerdaten statt eines einzelnen Scores. Hier liest du, welches Tool wofür taugt und wie ein belastbarer Vorher-nachher-Vergleich aussieht.

Labordaten und Felddaten

Fast jedes Missverständnis rund um die Ladezeit entsteht, weil diese beiden Datenarten durcheinandergeraten.

Labordaten stammen aus einem einzelnen Testlauf mit einem Gerät, einem Netzwerkprofil und einem Standort. Das bekannteste Beispiel ist Lighthouse. Es steckt hinter den PageSpeed-Insights-Daten von Google, die auch corewebvitals.page nutzt, und ist in die Chrome DevTools eingebaut. Labortests sind wiederholbar und liefern detaillierte Diagnosen. Deshalb eignen sie sich ideal, um Ursachen zu finden und zu prüfen, ob eine Korrektur wirkt. Trotzdem bleibt jeder Labortest eine Simulation: ein Aufruf, mit einer festen Drosselung, von dem Ort aus, an dem der Test läuft.

Felddaten, auch Real User Monitoring (RUM) genannt, kommen von tatsächlichen Besuchern auf ihren eigenen Smartphones, Laptops und Leitungen. Google sammelt sie bei Chrome-Nutzern im Chrome UX Report (CrUX). Du findest sie in der Search Console, und Tools wie corewebvitals.page zeigen sie für jede beliebige URL an. Auf diese Daten stützt sich Google bei der Bewertung der Page Experience, und sie bilden die Wirklichkeit ab, samt langsamer Geräte und weit entfernter Besucher. Der Haken: Felddaten reagieren träge. CrUX wertet ein gleitendes Fenster von 28 Tagen aus, eine Änderung von heute schlägt also erst nach Wochen voll durch.

Mit Labordaten arbeitest du, mit Felddaten entscheidest du, ob sich die Arbeit gelohnt hat.

Die passenden Tools

Einen großen Werkzeugkasten brauchst du nicht. Vier Tools decken so gut wie alles ab.

corewebvitals.page

corewebvitals.page zeigt dir beide Datenarten für Mobilgeräte und Desktop, auf Basis der PageSpeed-Insights-Daten von Google: die Felddaten aus CrUX der letzten 28 Tage, sofern genug Traffic vorhanden ist, und einen Lighthouse-Lauf. Lies zuerst die Felddaten. Der Performance-Score von 0 bis 100 gehört nur zum Labortest und ist nicht das, was Google fürs Ranking heranzieht.

Search Console

Der Bericht „Core Web Vitals" in der Google Search Console gruppiert deine URLs anhand der Felddaten nach Status: gut, verbesserungswürdig, schlecht. Dort erkennst du am besten, welche Seitenvorlagen auf der ganzen Website Probleme haben, statt URLs einzeln durchzutesten.

Chrome DevTools

Die Panels „Performance" und „Network" zeigen genau, was beim Laden passiert: welche Anfrage das Rendern blockiert, welches Skript den Main Thread belegt und wie lange der Server für die Antwort braucht. Im Panel „Lighthouse" läuft dieselbe Art von Labortest, nur lokal. Teste in einem Inkognito-Fenster, damit Browser-Erweiterungen das Ergebnis nicht verfälschen.

Kommandozeile

Für die Antwortzeit des Servers liefert curl eine saubere, wiederholbare Zahl ohne Browser-Overhead:

for i in 1 2 3 4 5; do
  curl -o /dev/null -s -w "%{time_starttransfer}\n" https://example.com/
done

Das gibt die Time to First Byte für fünf aufeinanderfolgende Anfragen aus. Besonders nützlich ist das, wenn du Änderungen am Caching oder am Server prüfst. Wie du diese Zahl weiter aufschlüsselst, erklärt der Ratgeber TTFB verbessern.

Welche Kennzahlen zählen

Konzentrier dich auf wenige Werte, die beschreiben, was Besucher tatsächlich erleben:

• Largest Contentful Paint (LCP): Wann erscheint der Hauptinhalt? Gut sind bis zu 2,5 Sekunden.
• Interaction to Next Paint (INP): Wie schnell reagiert die Seite auf Klicks und Tipps? Gut sind bis zu 200 Millisekunden. Messbar nur in Felddaten.
• Cumulative Layout Shift (CLS): Wie stark springt das Layout? Gut ist ein Wert bis 0,1.
• Time to First Byte (TTFB): Wie schnell beginnt der Server zu antworten? web.dev empfiehlt 0,8 Sekunden oder weniger.

Google bewertet die drei Core Web Vitals am 75. Perzentil der Seitenaufrufe, getrennt für Mobilgeräte und Desktop. Drei von vier Aufrufen sollten den Grenzwert also einhalten. Was hinter jeder Kennzahl steckt und wie du sie verbesserst, steht im Ratgeber Core Web Vitals verbessern.

Gesamtgröße der Seite und „vollständig geladen" sind weniger aussagekräftig, als sie wirken. Eine Seite kann spät fertig werden, weil ein Chat-Widget nachlädt, das niemand bemerkt. Ein langsames Titelbild dagegen fällt jedem auf, verändert die Gesamtladezeit aber kaum.

Warum deine Ergebnisse schwanken

Liefert derselbe Labortest dreimal drei verschiedene Scores, ist nichts kaputt. Die üblichen Gründe:

• Kalter oder warmer Cache. Die erste Anfrage nach einem Deployment oder dem Leeren des Caches ist oft deutlich langsamer als die folgenden, auf deinem Server genauso wie in einem CDN.
• Serverlast. Ein Test in Stoßzeiten konkurriert mit echten Besuchern.
• Skripte von Drittanbietern. Werbung, Tag Manager und Chat-Widgets laden jedes Mal andere Inhalte.
• Teststandort. Labortests auf Basis der PageSpeed-Insights-Daten von Google, auch die auf corewebvitals.page, laufen aus einem Google-Rechenzentrum. Steht dein Server auf einem anderen Kontinent, misst der Test vor allem diese Entfernung.
• Der Testrechner. Lighthouse in den DevTools hängt von der CPU deines eigenen Rechners ab und davon, was sonst gerade darauf läuft.

Ein Vorher-nachher-Vergleich, dem du trauen kannst

Stellst du etwas um, etwa das Caching, das Theme oder ein CDN, hältst du dich am besten an eine feste Routine. Nur so bleibt der Vergleich fair.

1. Repräsentative Seiten auswählen. Nimm je eine Seite pro wichtiger Vorlage: Startseite, Kategorie- oder Übersichtsseite, Produkt- oder Artikelseite. Deine meistbesuchte Landingpage gehört auch dazu.
2. Bedingungen notieren. Gleiches Tool, gleiches Geräteprofil (Mobil und Desktop getrennt), gleicher Teststandort und nach Möglichkeit dieselbe Tageszeit.
3. Erst aufwärmen, dann messen. Ruf jede Seite einmal auf und verwirf dieses Ergebnis, außer du willst gezielt den Erstaufruf messen. Danach machst du mindestens fünf Tests pro Seite.
4. Den Median verwenden. Nimm den mittleren Wert deiner Läufe, nicht den besten. Halte bei Labortests LCP, CLS, TTFB und Total Blocking Time fest.
5. Immer nur eine Sache ändern. Wechselst du Hosting und Theme gleichzeitig, weißt du hinterher nicht, was geholfen hat.
6. Nach der Änderung exakt gleich messen. Vergleiche die Mediane Seite für Seite.
7. Mit Felddaten bestätigen. Beobachte in den folgenden Wochen die Felddaten auf corewebvitals.page und in der Search Console. Was im Labor besser aussieht, bei echten Nutzern aber nicht ankommt, ist kein echter Gewinn.

Nutzt du ein CDN oder einen Edge-Cache, prüf bei den Nachher-Messungen, ob die Seite wirklich aus dem Cache kam. Sonst misst du deinen Ursprungsserver und nicht die Änderung.

So hilft dir fast.site

fast.site sitzt als Edge-Netzwerk mit Caching, Bildoptimierung und Sicherheitsfunktionen vor deinem bestehenden Hosting. Dein Hoster bleibt, du stellst die Nameserver deiner Domain auf fast.site um. Nach der Verifizierung laufen die Anfragen über den Edge.

Für das Messen sind zwei Dinge hilfreich. Erstens trägt jede Antwort Header, die zeigen, was passiert ist: fs-cache meldet HIT, MISS oder BYPASS, und fs-cache-age sowie fs-cache-hits verraten, wie lange und wie oft die gecachte Kopie schon im Einsatz ist. So stellst du leicht sicher, dass dein Nachher-Test wirklich aus dem Cache kam. Wie das geht, zeigt der Artikel Cache prüfen.

Zweitens zeigen die Analytics im Dashboard Anfragen, Cache-Trefferquote, Traffic vom Edge und vom Ursprungsserver, TTFB und Fehlerraten für deine eigenen Besucher. Zusammen mit den Felddaten auf corewebvitals.page ergibt das einen Vorher-nachher-Vergleich, der auf echtem Traffic beruht und nicht auf einem einzelnen Testlauf.

Am besten beurteilst du die Wirkung, indem du sie mit der Routine oben auf deiner eigenen Website misst, zum Beispiel in einer kostenlosen 7-Tage-Testphase. Tarife und inklusive Traffic findest du auf der Preisseite.

Häufige Fragen

Warum ist mein PageSpeed-Score jedes Mal anders?

Der Performance-Score stammt aus einem einzelnen Labortest, und den beeinflussen Serverlast, Cache-Zustand, Drittanbieter-Skripte und Schwankungen im Netz. Kleine Unterschiede zwischen zwei Läufen sind normal. Mach mehrere Tests, nimm den Median und verlass dich für das echte Bild auf die Felddaten.

Brauche ich einen PageSpeed-Score von 100?

Nein. Der Score fasst nur den Labortest zusammen und ist kein Rankingsignal. Entscheidend ist, ob echte Besucher gute Core Web Vitals erleben, und das zeigen die Felddaten. Die letzten Punkte zu jagen kostet oft viel Aufwand, ohne dass jemand einen Unterschied merkt.

Warum gibt es für meine Website keine Felddaten?

CrUX meldet nur Daten, wenn eine URL oder Domain in den letzten 28 Tagen genug Aufrufe von Chrome-Nutzern hatte. Kleinere Websites und neue Seiten erreichen diese Schwelle oft nicht. Dann verlässt du dich auf Labortests und dein eigenes Monitoring, bis genug Daten vorliegen.

Wie lange dauert es, bis Verbesserungen in der Search Console sichtbar sind?

Felddaten werden über ein gleitendes Fenster von 28 Tagen gesammelt, eine Verbesserung zeigt sich also schrittweise und erst nach rund vier Wochen vollständig. Die Search Console braucht unter Umständen noch etwas länger, um gruppierte URLs neu zu bewerten. Labortests zeigen die Wirkung sofort, deshalb prüfst du einen Fix zuerst dort.

Soll ich mobil oder am Desktop testen?

Beides, und zwar getrennt. Google bewertet die beiden separat, und mobil fallen die Ergebnisse wegen langsamerer Prozessoren und Netze meist schlechter aus. Hast du nur für eins Zeit, fang mit Mobil an.