Website-Ladezeit testen: So mache ich es heute (und diese Zahlen ignoriere ich)

Im April 2020 habe ich meine eigene Website durch fünf Speed-Tests gejagt und diesen Artikel darüber geschrieben. GTmetrix gab wunderlandmedia.com einen PageSpeed Score von A (99%), einen YSlow Score von 97% und eine Fully Loaded Time von 0,7 Sekunden. Ich war ziemlich zufrieden mit mir.

Sechs Jahre später habe ich den Artikel wieder aufgemacht. Eines der fünf Tools ist nicht mal mehr erreichbar. YSlow gibt es nicht mehr. Die Metrik, auf die damals alle gestarrt haben, First Input Delay, hat Google im März 2024 abgeschafft. Und die Einleitung klang, als hätte sie eine Content-Fabrik geschrieben. Darauf bin ich nicht stolz.

Also habe ich ihn neu geschrieben. So teste ich die Website-Ladezeit heute, diesen Zahlen vertraue ich, und diese schaue ich mir gar nicht mehr an.

Ladezeit ist die falsche Zahl

Die 0,7 Sekunden von 2020 haben mir gesagt, wann die letzte Datei auf einem GTmetrix-Testserver in London fertig geladen war. Darüber, was jemand mit einem Mittelklasse-Handy und wackeligem Netz erlebt, haben sie nichts gesagt. Das sind zwei sehr unterschiedliche Dinge, und ich habe sie jahrelang als eins behandelt.

Google bewertet dich auch nicht nach "Ladezeit". Google schaut auf die Core Web Vitals, gemessen bei echten Chrome-Nutzern:

• Largest Contentful Paint (LCP): wann das größte sichtbare Element (meist ein Hero-Bild oder die Überschrift) gerendert ist. Gut sind 2,5 Sekunden oder weniger.
• Interaction to Next Paint (INP): wie schnell die Seite reagiert, wenn jemand tippt, klickt oder schreibt. Gut sind 200 Millisekunden oder weniger. INP hat First Input Delay im März 2024 ersetzt.
• Cumulative Layout Shift (CLS): wie sehr die Seite beim Laden herumspringt. Gut ist 0,1 oder weniger.

Google nimmt dabei das 75. Perzentil der echten Besuche. Wenn also drei Viertel deiner Besucher eine gute Erfahrung haben und das langsamste Viertel nicht, stehst du genau auf der Kippe.

Die alte Version dieses Artikels hat auch die berühmte Amazon-Zahl zitiert, nach der jede 100 Millisekunden Verzögerung 1% Umsatz kosten. Dort stand "Mikrosekunden", was um den Faktor tausend daneben liegt, und die Zahl stammt sowieso aus der Zeit um 2006. Ich tue nicht so, als würde eine 20 Jahre alte interne Statistik eines Onlinehändlers etwas über das Kontaktformular deiner Bäckerei aussagen. Geschwindigkeit ist wichtig, weil eine langsame Seite Leute warten lässt, und wer warten muss, geht. Dafür brauchst du keine dramatische Statistik.

Felddaten schlagen Labordaten, jedes Mal

Öffne PageSpeed Insights und du bekommst auf einer Seite zwei sehr unterschiedliche Blöcke mit Zahlen. Die meisten scrollen am oberen direkt vorbei zum großen bunten Score. Das ist genau falsch herum.

Der obere Block sind Felddaten aus dem Chrome UX Report (CrUX): was echte Chrome-Nutzer in den letzten 28 Tagen auf deiner Seite erlebt haben. Der untere Block sind Labordaten: ein einzelner Lighthouse-Lauf auf einem simulierten, gedrosselten Handy in einem Google-Rechenzentrum.

Labordaten sind gut zum Debuggen, weil sie reproduzierbar sind und dir sagen, was du reparieren sollst. INP können sie aber überhaupt nicht messen, weil während eines Labortests niemand irgendwo klickt. Lighthouse zeigt stattdessen die Total Blocking Time an. Das ist ein Hinweis, nicht der echte Wert.

Wenn sich beide widersprechen, gewinnen die Felddaten. Deinen Besuchern ist egal, was ein simuliertes Handy in einem Rechenzentrum denkt.

Der Haken: Kleine Websites haben oft keine Felddaten. Wenn CrUX nicht genug Besuche für deine Seite hat, sagt PageSpeed Insights dir das, und du bekommst nur den Labortest. Für einen lokalen Betrieb mit ein paar hundert Besuchen im Monat ist das normal. Dann schaue ich auf die Daten für die gesamte Domain (Origin), falls es die gibt, und sonst nehme ich die Laborwerte als grobe Orientierung, mehr nicht.

Schritt 1: PageSpeed Insights, zuerst die obere Hälfte

Hier fängt jeder Test bei mir an, weil PageSpeed Insights Feld- und Labordaten nebeneinander zeigt und am nächsten an Googles eigenem Blick auf deine Seite dran ist.

Ich schaue zuerst auf den Mobile-Tab. Google indexiert die mobile Version deiner Website, und auf dem Handy fallen die meisten Seiten durch. Ich lese die Felddaten für die Seite, dann für die Origin, und erst danach scrolle ich runter zum Lighthouse-Teil.

Seit Lighthouse 13 im Oktober 2025 erschienen ist, sieht die untere Hälfte anders aus als in älteren Anleitungen. Google hat die alten Audits wie "Render-blockierende Ressourcen" oder "Bilder richtig dimensionieren" zu Performance Insights zusammengelegt, denselben, die du auch in den Chrome DevTools siehst. Wenn eine Anleitung dir sagt, du sollst nach einem bestimmten Audit suchen, und du findest es nicht, liegt es daran.

Lass den Test mehr als einmal laufen, weil der Lighthouse Score zwischen zwei Läufen ein paar Punkte schwankt, auch wenn sich nichts geändert hat. Und teste neben der Startseite deine wichtigsten Templates: einen Blogartikel, eine Leistungsseite, eine Kontaktseite. Die Startseite ist meistens die Seite, die schon mal jemand optimiert hat.

Schritt 2: Search Console zeigt dir, welche Seiten durchfallen

PageSpeed Insights testet eine URL. Die Google Search Console zeigt dir die ganze Website. Ihr Core-Web-Vitals-Bericht (unter "Nutzerfreundlichkeit") sortiert deine URLs in Gut, Optimierung erforderlich und Schlecht, getrennt nach Mobil und Desktop, auf Basis derselben CrUX-Felddaten.

Das Nützliche ist die Gruppierung. Search Console fasst ähnliche Seiten zusammen. Statt "Seite 47 ist langsam" siehst du also "diese 80 Blogartikel haben alle ein LCP-Problem". Das deutet fast immer auf ein Template-Problem hin: ein zu großes Beitragsbild, eine Schrift, die zu spät lädt, ein Cookie-Banner, das alles nach unten schiebt. Reparier das Template, und die ganze Gruppe bewegt sich.

Wenn deine Website pro URL-Gruppe nicht genug Traffic hat, weicht Search Console auf eine Origin-Gruppe für die ganze Domain aus. Gleiche Einschränkung wie oben, nur eine Ebene höher.

Das gehört bei mir zu jedem technischen SEO-Check. Es sind Googles eigene Daten, und der Bericht wird leicht übersehen.

Schritt 3: CrUX Vis für den Verlauf

Felddaten sind ein rollierendes 28-Tage-Fenster, und das bringt Leute nach einem Fix durcheinander. Du komprimierst am Montag deine Bilder, testest am Dienstag mit PageSpeed Insights, und die Felddaten bewegen sich kaum. Kaputt ist nichts. Die alten, langsamen Besuche sind einfach noch im Fenster.

Um zu sehen, ob ein Fix wirklich gewirkt hat, schaue ich auf den Verlauf. CrUX Vis ist Googles Tool dafür. Du gibst eine URL oder Origin ein und bekommst den Verlauf von LCP, INP, CLS und ein paar weiteren Metriken. Es hat das alte CrUX Dashboard in Looker Studio ersetzt, das Google Ende November 2025 abgeschaltet hat. Falls du das Dashboard als Lesezeichen hattest: Es ist weg.

Ich gebe einer Änderung ungefähr vier Wochen, bevor ich sie bewerte. Alles davor ist hauptsächlich Rauschen.

Schritt 4: GTmetrix und WebPageTest, wenn ich das Warum sehen muss

Felddaten sagen mir, dass eine Seite langsam ist. Um herauszufinden, warum, brauche ich einen Wasserfall: die Liste aller Dateien, die die Seite lädt, in Reihenfolge, mit der Zeit, die jede gebraucht hat.

GTmetrix ist die freundlichere Variante. Das ist der Bericht von 2020, über den ich mich so gefreut habe:

Die Hälfte dieses Screenshots gibt es nicht mehr. GTmetrix hat die PageSpeed- und YSlow-Scores abgeschafft und läuft jetzt auf Lighthouse, du bekommst also eine GTmetrix Grade plus Web Vitals. Mit einem kostenlosen Account kannst du den Teststandort (Standard ist Vancouver) und die Verbindungsgeschwindigkeit wählen. Nimm einen Standort in der Nähe deiner echten Besucher. Eine deutsche Website, getestet aus Kanada, sieht langsamer aus, als sie ist.

WebPageTest, inzwischen von Catchpoint betrieben, mache ich auf, wenn GTmetrix nicht reicht. Du brauchst heute einen kostenlosen Account und die Oberfläche ist voller, aber die Filmstrip-Ansicht ist das Nützlichste in diesem ganzen Artikel. Sie zeigt Screenshots davon, was der Besucher in jedem Moment des Ladevorgangs sieht. Wenn sich eine Seite "langsam anfühlt", zeigt dir der Filmstrip, wo: eine Sekunde weißer Bildschirm, dann ein Hero-Bild, das spät aufploppt.

Schritt 5: Chrome DevTools für INP

INP ist die Metrik, mit der Labortools Probleme haben, weil sie davon abhängt, dass jemand mit der Seite interagiert. Also teste ich sie von Hand.

Öffne die Chrome DevTools, geh in den Performance-Tab, und du landest bei den Live Metrics: dein lokaler LCP, CLS und INP, die sich aktualisieren, während du die Seite benutzt. Öffne das Menü, klapp das Akkordeon auf, tipp etwas ins Suchfeld, leg etwas in den Warenkorb. Jede Interaktion aktualisiert den INP-Wert. Im selben Panel kannst du auch die CrUX-Felddaten einschalten und deine lokalen Werte mit denen echter Nutzer vergleichen.

Dein Laptop ist wahrscheinlich deutlich schneller als die Handys deiner Besucher. Schalte deshalb in diesem Panel die CPU-Drosselung ein, bevor du einem guten INP-Wert glaubst. Ein schwerer JavaScript-Handler, der auf einem MacBook 50 Millisekunden braucht, kann auf einem günstigen Android-Handy ein Mehrfaches davon brauchen.

Was aus den anderen Tools von 2020 geworden ist

Der ursprüngliche Artikel hat den Ladezeit-Tester von Sucuri empfohlen. Das ist das Ergebnis, das er mir damals geliefert hat:

Die Domain performance.sucuri.net löst heute nicht mehr auf, wenn ich sie aufrufe. Tools sterben. Ein Grund mehr, deine Routine auf Googles eigene Daten zu bauen und nicht auf den kostenlosen Tester, der dieses Jahr für "Speed Test" rankt.

Der Screenshot lehrt trotzdem noch was. Die Time to First Byte lag aus Frankfurt unter 0,2 Sekunden und aus São Paulo über 1,3 Sekunden. Gleiche Website, gleiche Minute. Von wo du testest, verändert das Ergebnis stärker als die meisten Optimierungen.

Der kostenlose Speed-Test von Pingdom ist noch online. Das war sein Ergebnis 2020, getestet aus Frankfurt:

Performance Grade 88, 607 Millisekunden, 796,4 KB, 19 Requests. Der GTmetrix-Lauf 19 Tage vorher sagte 392 KB und 11 Requests. Ich weiß nicht, ob ich zwischendurch etwas auf der Startseite ergänzt habe oder ob die beiden Tools unterschiedlich zählen, weil ich es nicht aufgeschrieben habe. Wenn du Zahlen vergleichst, vergleich sie aus demselben Tool, vom selben Standort, mit denselben Einstellungen, und notier dir, was sich geändert hat. Der kostenlose Test von Uptrends ist auch noch online. Keins von beiden hat es in meine Routine geschafft.

Die Zahlen, die ich ignoriere

Nach alldem bekommen ein paar Zahlen keine Aufmerksamkeit mehr von mir:

• Fully Loaded Time. Die wartet auf jedes Tracking-Pixel und jedes Chat-Widget. Deine Besucher nicht.
• Noten und Buchstaben-Scores von Drittanbieter-Tools. Ein A bei GTmetrix und ein B bei Pingdom am selben Tag sagen dir etwas über deren Bewertungsformeln, nicht über deine Besucher.
• Ein Lighthouse-Lauf auf dem Desktop im Büro. Glasfaser und ein schneller Laptop lassen fast jede Website gut aussehen. Das habe ich auch in meinem Performance-Vergleich Astro vs. WordPress geschrieben: Miss Felddaten, keinen Labortest über deine eigene Leitung.
• Die Jagd nach 100/100. Von 92 auf 100 in Lighthouse zu kommen, kostet oft Stunden Arbeit für eine Änderung, die kein Besucher bemerkt. Wenn deine Felddaten die Core Web Vitals bestehen, steck die Zeit lieber in Inhalte.

Was ich nach dem Test mache

Testen ist nur die halbe Arbeit. Bei den Websites kleiner Unternehmen, die ich sehe, sind es meistens zu große Bilder und Plugins oder Skripte, die niemand braucht, verschlimmert durch billiges Hosting. Darüber habe ich in den langweiligen Fixes, die besser sind als ein Redesign geschrieben. Wenn du auf WordPress bist, deckt ein gutes Caching-Plugin viel davon ab. Mein FlyingPress-Review zeigt, wie das aussieht.

Meine Routine passt auf einen Post-it: zuerst die Felddaten in PageSpeed Insights, Search Console für die ganze Website, CrUX Vis für den Verlauf, GTmetrix oder WebPageTest für den Wasserfall, DevTools für INP. Dann eine Sache reparieren, vier Wochen warten, wieder hinschauen.

Ich kann dir keinen perfekten Score versprechen, und ich glaube auch nicht, dass du einen brauchst. Was ich kann: deine Website richtig testen, dir sagen, welcher Fix deine echten Nutzerwerte bewegt und welcher nur Kosmetik ist, und sie von Anfang an auf Geschwindigkeit ausgelegt bauen oder umbauen. Lass uns sprechen, wenn sich deine Website langsamer anfühlt, als sie sollte.