WebPageTest

TL;DR — WebPageTest ist ein kostenloses Tool, das Ihre Seite in einem echten Browser an einem echten Standort lädt und genau zeigt, was beim Laden passiert ist — jede Datei, die heruntergeladen wurde, in welcher Reihenfolge, und ein Video der entstehenden Seite Bild für Bild. Es ist das Tool für den Fall, dass PageSpeed Insights eine Seite als langsam meldet, Sie aber sehen wollen, warum. Es ist kein Google-Produkt, und seine Werte beeinflussen Ihre Rankings nicht — es ist ein Diagnose-Tool.

Was WebPageTest ist

Die meisten Speed-Tools liefern Ihnen eine Zahl. WebPageTest liefert Ihnen eine Geschichte — ein detailliertes, Schritt für Schritt nachvollziehbares Bild davon, wie Ihre Seite geladen wurde.

Sie rufen webpagetest.org auf, geben eine URL ein, wählen aus, von welchem Ort der Welt aus und mit welcher Art von Gerät und Verbindung getestet werden soll, und starten den Test. Ein echter Browser auf einer echten Maschine lädt Ihre Seite, und WebPageTest zeichnet alles auf: jedes Bild, jedes Skript und jede Schriftart, die abgerufen wurden, wie lange das jeweils gedauert hat, und einen Filmstrip — eine tatsächliche Serie von Screenshots, Bild für Bild, wie die Seite auf dem Bildschirm erscheint.

Es ist kostenlos und Open Source. Entwickelt wurde es 2008 von einem Entwickler namens Patrick Meenan, und ein Unternehmen namens Catchpoint hat es 2020 übernommen — die kostenlose öffentliche Version auf webpagetest.org steht aber weiterhin allen zur Verfügung.

Warum Sie es statt PageSpeed Insights nutzen würden

PageSpeed Insights (Googles Tool) ist gut darin, Ihnen mitzuteilen, dass eine Seite langsam ist, und einen Score zu vergeben. WebPageTest ist besser darin, Ihnen zu zeigen, warum und wo. Wenn PSI „reduce render-blocking resources“ meldet, zeigt Ihnen WebPageTest genau die Datei, die blockiert, und in welcher Sekunde — in einem Diagramm, das sich wie eine Zeitleiste lesen lässt.

Das Zweite, was oft falsch verstanden wird: WebPageTest-Werte sind kein Ranking-Faktor. Google bewertet unter anderem, wie schnell echte Besucher Ihre Website erleben (das nennt sich „Field data“ und stammt von tatsächlichen Chrome-Nutzern). WebPageTest ist ein „Lab“-Test — ein kontrollierter Lauf auf einer Maschine. Er dient dazu, Probleme zu finden und zu beheben, nicht dazu, die Zahl zu liefern, die Google tatsächlich sieht.

Die zwei Ansichten, mit denen die meisten beginnen

• Der Waterfall. Ein Diagramm mit einer Zeile pro Datei, die Ihre Seite geladen hat, gestapelt in der Reihenfolge ihres Eintreffens. Lange Balken und viele Dateien gleich zu Beginn sind meist der Ort, an dem die Langsamkeit sitzt.
• Der Filmstrip. Eine Reihe von Screenshots, die zeigen, wie sich die Seite nach und nach aufbaut. Sie können buchstäblich den Moment beobachten, in dem Ihr Hauptinhalt erscheint — oder den Moment, in dem etwas auf der Seite verspringt.

Sie wollen die vollständige Fassung — die Connection View, das genaue Vorgehen, mit dem ich Layout Shifts aufspüre, den Vergleich mit Lighthouse und CrUX und wie ich das Tool für technisches SEO einsetze? Wechseln Sie zum Tab Fortgeschritten.

TL;DR — WebPageTest ist ein kostenloses, quelloffenes Performance-Tool für Lab-Daten (synthetische Daten): hinein gehen eine URL, ein echter, weltweit verteilter Teststandort, ein Browser und ein Netzwerkprofil, heraus kommt eine Tiefendiagnose — Waterfall (Kennzeichnung Render-blockierender Ressourcen, Abfolge der Requests), Filmstrip/Video (Bild für Bild, mit der Option Highlight Layout Shifts für CLS), Connection View (DNS/TCP/TLS/TTFB) und Core Web Vitals Bild für Bild. Patrick Meenan entwickelte es 2008 (als internes AOL-Tool); Catchpoint übernahm es 2020; der Code bleibt unter der Polyform-Shield-Lizenz offen. Der Genauigkeitskern: Es erzeugt Lab-Daten, keine Field data, und fließt daher nicht in Googles CWV-Ranking-Signal ein (dafür sorgt CrUX mit Daten echter Nutzer). Es ist ein Diagnosewerkzeug und nicht der Score, den Google sieht — und es ist kein Konkurrent zu Lighthouse, denn Lighthouse lässt sich darin ausführen. Greifen Sie dazu, wenn PageSpeed Insights Ihnen sagt, dass eine Seite langsam ist, aber nicht warum oder an welcher Stelle des Ladevorgangs.

Was es tatsächlich ist

Jedes WebPageTest-Ergebnis ist ein konfigurierter Testlauf: eine URL, getestet von einem bestimmten Standort, auf einem bestimmten Browser und Gerät, über ein bestimmtes Verbindungsprofil, zu einem bestimmten Zeitpunkt. Es ist keine allgemeingültige Messung dessen, „wie schnell Ihre Website ist“ — es ist ein Beleg aus genau diesem Lauf und muss auch so gelesen werden.

In diesem Rahmen ist WebPageTest das Werkzeug für die Tiefendiagnose im Werkzeugkasten der Web-Performance. web.dev, Googles eigene Entwicklerseite, formuliert es treffend: “WebPageTest contains an advanced suite of metrics and trace viewers. It enables deep diving into the performance of your site on real mobile hardware with network conditions.” (Übersetzung) „WebPageTest bietet eine anspruchsvolle Palette von Messgrößen und Ablaufansichten. Damit können Sie die Leistung Ihrer Website auf echter mobiler Hardware unter festgelegten Netzwerkbedingungen gründlich untersuchen.“ (web.dev, „Werkzeuge für Geschwindigkeitsmessungen richtig einordnen“)

Die dortige Seite zum Thema „Audit“ ergänzt den SEO-nahen Blickwinkel: “WebPagetest will also check static-content caching, time to first byte, and if your site makes effective use of CDNs.” (Übersetzung) „WebPagetest prüft außerdem das Caching statischer Inhalte, die Time to First Byte und ob Ihre Website CDNs effektiv nutzt.“ (web.dev, “Audit performance”)

Wo die Schwester-Tools in diesem Cluster — Google Lighthouse, PageSpeed Insights und der Chrome UX Report (CrUX) — Ihnen einen Score oder ein Bestanden/Nicht bestanden liefern, liefert WebPageTest die Belege unter diesem Score: Request für Request, Bild für Bild.

Eine kurze Geschichte — und eine wirklich merkwürdige Fußnote

Patrick Meenan hat WebPageTest 2008 entwickelt und quelloffen gestellt; es begann als internes Testwerkzeug bei AOL. Catchpoint übernahm es 2020. Die Seite zur Geschichte erzählt die Entstehungsgeschichte direkt: “Catchpoint’s 2020 acquisition of WebPageTest, created and open-sourced by Patrick Meenan in 2008, marked a significant milestone.” (Übersetzung) „Die Übernahme des 2008 von Patrick Meenan entwickelten und quelloffen gestellten WebPageTest durch Catchpoint war 2020 ein bedeutender Meilenstein.“ Die dort formulierte Mission ist unverblümt: “slow is the new down, and our mission is to empower you to deliver the best experiences to your users.” (Übersetzung) „langsam ist das neue offline, und unsere Mission ist es, Sie in die Lage zu versetzen, Ihren Nutzern die besten Erlebnisse zu liefern.“ (webpagetest.org/about)

Und hier die merkwürdige Fußnote, die es festzuhalten lohnt: Meenan arbeitet inzwischen bei Google an Chrome und Web-Performance. Und dennoch nennt Googles eigene offizielle Tool-Seite zu den Core Web Vitals — web.dev/articles/vitals-tools, genau jene Seite, auf die das Core-Web-Vitals-Dokument der Search Central als “the different tools that can help you measure and report Core Web Vitals” (Übersetzung) „die verschiedenen Tools, die Ihnen helfen können, Core Web Vitals zu messen und darüber zu berichten“ verweist — WebPageTest nicht. Aufgeführt sind CrUX, PageSpeed Insights, Search Console, Lighthouse, das Performance-Panel der DevTools, die JS-Bibliothek web-vitals und Lighthouse-CI. Das Tool, das die Person gebaut hat, die heute dort arbeitet, fehlt.

Lesen Sie das allerdings genau: Es ist kein Hinweis darauf, dass WebPageTest veraltet oder nicht empfohlen wäre. Google kuratiert eine Liste der eigenen Produkte; ein quelloffenes Tool eines Drittanbieters steht dort schlicht nicht drauf. Andere web.dev-Seiten (speed-tools, performance-audit-tools) verweisen positiv auf WebPageTest. Das ist eine Lücke in der Kuratierung, kein Urteil über das Tool.

Lab vs. Field — die Unterscheidung, auf die es am meisten ankommt

Das ist der Genauigkeitskern des gesamten Themas und das Gegenstück zum Lab-vs.-Field-Punkt, der sich durch den gesamten Cluster Web-Performance-Tools zieht.

WebPageTest erzeugt Lab-Daten (synthetische Daten): einen kontrollierten, wiederholbaren Test auf einer Maschine, die Sie konfigurieren, zu einem Zeitpunkt, den Sie wählen. Das ist etwas grundlegend anderes als Field data — die Messwerte echter Nutzer aus dem Chrome UX Report (CrUX), die Google Search tatsächlich für das Core-Web-Vitals-Ranking-Signal heranzieht und die in PageSpeed Insights und der Search Console auftauchen.

Also ganz einfach gesagt:

• Ein WebPageTest-Lauf fließt nicht in Googles Ranking-Signal ein. Er misst dieselben Metriken, die für Google zählen (LCP, INP, CLS), aber die Zahl, nach der Google rankt, stammt aus den Field data von CrUX und nicht aus einem Lab-Lauf — weder aus dem von WebPageTest noch aus dem Lab-Teil von PSI noch aus dem von Lighthouse.
• WebPageTest dient der Diagnose: ein Problem reproduzieren, es isolieren und einen Fix in einer schnellen, kontrollierten Schleife bestätigen. Field data (CrUX) sind die langsame, maßgebliche Bestätigung, dass echte Nutzer die Verbesserung gespürt haben — wie dieses Ranking-Signal funktioniert, steht unter Core Web Vitals.

Ganz nüchtern: Ein WebPageTest-Ergebnis ist kein Ersatz für Field data aus CrUX, für Zahlen zum realen Nutzertraffic oder für ein Ranking- bzw. Page-Experience-Ergebnis in der Google-Suche — und kann es auch nicht sein. Das sind eigene Datensätze, die ihre eigenen Belege brauchen; ein schneller synthetischer Lauf ist kein Beweis dafür, dass sich bei einem von ihnen etwas bewegt hat.

Wenn Sie nur eines von dieser Seite mitnehmen: WebPageTest sagt Ihnen, was zu beheben ist; CrUX sagt Ihnen, ob sich Googles Ranking-Signal bewegt hat.

So führen Sie einen einfachen Test durch

Der Kernablauf ist bewusst einfach:

1. URL. Die öffentliche Seite, die Sie testen wollen (sie muss öffentlich erreichbar sein).
2. Teststandort. WebPageTest läuft auf physisch verteilten, echten Maschinen rund um die Welt — wählen Sie einen Standort nahe Ihrer Zielgruppe, denn Entfernung und Netzwerkbedingungen verändern das Ergebnis.
3. Browser / Gerät. Chrome liefert Ihnen die meisten Daten. Sie können auch mobile Geräte emulieren.
4. Verbindungsprofil. Ein gedrosseltes Netzwerk (z. B. eine langsame mobile Verbindung), damit Sie unter realistischen Bedingungen testen und nicht über die Glasfaserleitung im Büro.
5. Wiederholungsläufe. Das ist der Punkt, den Einsteiger überspringen. Die Performance schwankt von Lauf zu Lauf (Netzwerk-Jitter, Serverlast, konkurrierende CPU-Last), deshalb führt WebPageTest mehrere Tests durch und meldet einen Median. Trauen Sie niemals einem einzelnen Lauf — lesen Sie den Median. Behalten Sie dabei im Kopf, dass auch der Median nur eine synthetische Stichprobe aus Ihrer gewählten Konfiguration ist und keine Messung auf Populationsebene dessen, was echte Besucher erleben — dafür sind Field data (CrUX) da.

Jede einzelne dieser Einstellungen ist Teil des Experiments und kein nebensächliches Detail. Wenn Sie zwei Tests vergleichen — vor und nach einem Fix oder Ihre Website gegen die eines Wettbewerbers —, hat der Vergleich nur dann Aussagekraft, wenn Sie die Einstellungen festhalten und konstant halten: gleicher Standort, gleicher Browser, gleiches Verbindungsprofil, gleicher Cache-Zustand (First View vs. Repeat View) und ungefähr gleiche Anzahl an Läufen im gleichen Zeitfenster. Ändern Sie eines davon zwischen den Läufen, verwechseln Sie leicht eine Verschiebung der Testkonfiguration mit einem echten Performance-Unterschied.

Die Ergebnisse lesen

Das Waterfall-Diagramm

Der Waterfall ist eine Zeitleiste Request für Request: eine Zeile pro Ressource, in Ladereihenfolge, jeder Balken zeigt die Phasen DNS/Verbindung/TLS/Wartezeit/Download. Er kennzeichnet Render-blockierende Ressourcen, zeigt Weiterleitungsketten als zusätzliche Hops und macht offensichtlich, wenn eine Handvoll Ressourcen ganz oben alles Nachfolgende ausbremst. Hier hört „reduce render-blocking resources“ auf, eine Abstraktion zu sein, und wird zu „genau diese CSS-Datei, in genau dieser Sekunde“.

Die Connection View

Diese Ansicht gruppiert nach Verbindung statt nach Request und legt damit DNS-Lookup, TCP-Verbindungsaufbau, TLS-Aushandlung und Time to First Byte (TTFB) pro Host offen. Sie ist der schnellste Weg, um zu sehen, ob Ihre Langsamkeit auf Server- bzw. Netzwerkseite liegt (eine langsame TTFB, zu viele separate Verbindungen) oder auf Seiten der Inhalte.

Die Filmstrip-/Video-Ansicht — und mein Vorgehen bei der CLS-Jagd

Der Filmstrip ist eine Abfolge von Screenshots, die zeigen, wie sich die Seite über die Zeit aufbaut; die Video-Ansicht spielt das Ganze ab. So sehen Sie — statt darauf zu schließen —, wann Ihr Hauptinhalt erscheint und wann etwas auf der Seite springt.

Das ist die WebPageTest-Funktion, auf die ich mich am meisten stütze, und ich habe sie wiederholt in Vorträgen und in meinem Ahrefs-Guide zu den Core Web Vitals durchgespielt. Für das Aufspüren von Cumulative Layout Shift ist das genau das Rezept, das ich verwende: “In Filmstrip View, use the following options: Highlight Layout Shifts, Thumbnail Size: Huge, Thumbnail Interval: 0.1 secs.” (Übersetzung) „Verwenden Sie in der Filmstrip View die folgenden Optionen: Highlight Layout Shifts, Thumbnail Size: Huge, Thumbnail Interval: 0.1 secs.“ Das macht aus dem Filmstrip eine hochauflösende Zeitleiste, auf der ein Shift unmöglich zu übersehen ist. Im realen Beispiel aus diesem Guide war ein Font-Swap der Übeltäter — “Notice how our font restyles between 5.1 secs and 5.2 secs, shifting the layout as our custom font is applied.” (Übersetzung) „Beachten Sie, wie sich unsere Schrift zwischen 5,1 s und 5,2 s neu formatiert und dabei das Layout verschiebt, sobald unsere eigene Schriftart angewendet wird.“ Web Fonts, spät ladende Bilder und eingefügte Werbeanzeigen sind die üblichen CLS-Verdächtigen, und der Filmstrip ertappt sie sichtbar auf frischer Tat.

Eine Warnung: Wenn eine Ressource im Waterfall genau in dem Moment fertig lädt, in dem der Filmstrip einen Sprung zeigt, ist das ein starkes Indiz, aber kein Beweis — es ist eine Hypothese. Bestätigen Sie diese Vermutung, indem Sie den Verdächtigen isolieren (die Domain bzw. den Request blockieren oder ihn verzögern) und dieselbe Konfiguration erneut testen; verschwindet der Shift, haben Sie die Ursache bestätigt, statt nur zwei Zeitleisten zu korrelieren.

Core Web Vitals, Bild für Bild

WebPageTest weist LCP, CLS und — bei echter Interaktion — INP zusammen mit TTFB, FCP und Speed Index aus und lässt Sie sehen, an welcher Stelle des Ladevorgangs der jeweilige Wert zustande kam, statt nur einen Endwert zu liefern. Wo Field data aus CrUX verfügbar sind, können sie neben den Lab-Ergebnissen angezeigt werden, die Tiefendiagnose liefert aber der Lab-Lauf.

Fortgeschrittene Funktionen

• Scripting / mehrstufige Abläufe. Testen Sie Seiten hinter einem Login oder einen Warenkorb- bzw. Checkout-Ablauf — skripten Sie die Schritte, damit WebPageTest eine echte Journey misst und nicht nur eine kalte Startseite. Kontrollieren und notieren Sie, wovon das Skript abhängt: das verwendete Testkonto samt Zugangsdaten, in welchem Zustand das Konto ist, dynamische Inhalte auf der Seite und Ihr API-Kontingent — ein undokumentiertes Skript lässt sich zwischen Läufen genauso schwer vergleichen wie ein undokumentierter manueller Test.
• Domain- / Request-Blocking. Blockieren Sie eine bestimmte Drittanbieter-Domain und testen Sie erneut, um exakt zu messen, was Sie dieses Chat-Widget oder Werbeskript kostet. Das kann PSI schlicht nicht.
• Lighthouse innerhalb von WebPageTest. „WebPageTest vs. Lighthouse“ ist ein falscher Gegensatz — Sie können ein Lighthouse-Audit aus WebPageTest heraus ausführen. Dabei lohnt sich Präzision: Das Lighthouse-Audit ist ein eigener, versionierter Report — mit eigenem Score von 0–100 und eigener Audit-Liste —, der innerhalb der übergeordneten WebPageTest-Testsitzung erzeugt wird und nicht in die nativen Waterfall- und Filmstrip-Metriken von WebPageTest einfließt. Wie ich es im Ahrefs-Guide formuliert habe, nutzen die meisten Speed-Tools intern Lighthouse: “The exception is WebPageTest, although you can also run Lighthouse tests with it as well.” (Übersetzung) „Die Ausnahme ist WebPageTest, wobei sich damit ebenfalls Lighthouse-Tests ausführen lassen.“ (Ahrefs — Core Web Vitals)
• Opportunities & Experiments. Eine No-Code-Funktion für den Vorher-/Nachher-Vergleich von HTML-Änderungen, mit der sich zwei Zustände einer Seite vergleichen ließen, ohne die Produktivumgebung anzufassen — eingeführt etwa 2022, laut zeitgenössischer Berichterstattung von Detlef Johnson bei Search Engine Land (dieser konkrete Artikel wurde inzwischen von jener Website genommen, und ich konnte den aktuellen Namen bzw. die Verfügbarkeit der Funktion in dieser Update-Runde nicht unabhängig gegen eine laufende WebPageTest-Sitzung erneut bestätigen — es lohnt sich, das frisch zu prüfen, bevor Sie unter diesem Namen einen Workflow darauf aufbauen).
• API / Automatisierung und private Instanzen. Es gibt eine API für programmatisches Testen, und weil der Code Open Source ist, können Sie eine eigene private Instanz betreiben.

WebPageTest für technisches SEO nutzen

Das ist der Blickwinkel, den die meisten WebPageTest-Guides auslassen, und der Grund, warum das Tool in den Werkzeugkasten eines technischen SEO gehört:

• Als Googlebot testen. Sie können einen Googlebot-User-Agent setzen und beobachten, wie sich Render-blockierendes JS verhält — eine nützliche Annäherung (kein perfektes Abbild) daran, wie Googles Renderer die Seite erleben könnte. MobileMoxies Guide zu WebPageTest für technisches SEO fasst den SEO-Nutzen gut: “The tool provides detailed information about the health of your pages and helps analyze things like round trip requests, asset errors, redirects, caching concerns, security information, and more.” (Übersetzung) „Das Tool liefert detaillierte Informationen über den Zustand Ihrer Seiten und hilft dabei, Dinge wie Round-Trip-Requests, Fehler bei Assets, Weiterleitungen, Caching-Probleme, Sicherheitsinformationen und mehr zu analysieren.“
• Weiterleitungsketten prüfen. Der Waterfall legt jeden Weiterleitungs-Hop offen, sodass eine aufgeblähte Weiterleitungskette (jeder Hop ein Round Trip) sichtbar wird, statt verborgen zu bleiben.
• Caching und CDN-Wirksamkeit prüfen. Laut web.dev (siehe oben) prüft WebPageTest das Caching statischer Inhalte, die TTFB und die CDN-Nutzung — also die Infrastruktur, die bestimmt, wie schnell Bots und Nutzer gleichermaßen an Ihre Bytes kommen.
• JS-Rendering-Probleme diagnostizieren. Wenn Inhalte erst erscheinen, nachdem JavaScript ausgeführt wurde, zeigen Ihnen Filmstrip und Waterfall, wann (und ob) sie gerendert wurden.
• Vorher-/Nachher-Belege für Stakeholder. Ein Filmstrip der aktuellen Seite neben dem eines vorgeschlagenen Fixes ist für Kunden oder ein Entwicklungsteam ein weit überzeugenderes Artefakt als eine Lighthouse-Zahl, die um sechs Punkte gefallen ist.

Preise und Zugang

Der kostenlose öffentliche Dienst auf webpagetest.org bot historisch in der Größenordnung von einigen Hundert Testläufen pro Monat, dazu einen kostenlosen API-Schlüssel mit Tageslimits. Eine kostenpflichtige Stufe WebPageTest Pro schaltet mehr API-Volumen, private Tests und Priorität in der Testwarteschlange frei. Und weil das Ganze unter der Polyform-Shield-Lizenz Open Source ist — Catchpoint formuliert es so: “the WebPageTest code remains freely accessible under the Polyform Shield license, permitting its use for internal or non-competing commercial projects” (Übersetzung) „der WebPageTest-Code bleibt unter der Polyform-Shield-Lizenz frei zugänglich und erlaubt seine Nutzung für interne oder nicht konkurrierende kommerzielle Projekte“ (webpagetest.org/about) — können Sie auch eine eigene private Instanz selbst hosten.

Ehrliche Grenzen

• Lernkurve. Die Oberfläche ist dicht; ein Waterfall wirkt einschüchternd, bevor er nützlich wird.
• Konto für gespeicherte und private Ergebnisse nötig. Gelegentliche Einzeltests sind offen zugänglich, für das Speichern und für private Tests braucht es aber ein Konto.
• Es diagnostiziert, es behebt nicht. WebPageTest zeigt Ihnen das Problem in großartiger Detailtiefe; es führt Sie aber nicht an der Hand durch die Behebung, wie es manche Scoring-Tools versuchen.
• Schwankung bei Einzelläufen. Ein einzelner Lauf kann in die Irre führen. Nutzen Sie mehrere Läufe und lesen Sie den Median — das Tool macht das nicht ohne Grund zur Voreinstellung.

Eine Anmerkung zu Bing

Es gibt keine Dokumentation von Bing oder Microsoft, die WebPageTest als Ranking-Input oder als Empfehlung aus erster Hand positioniert. Die Bing Webmaster Tools haben ihren eigenen Site Scan und eigene Empfehlungen rund um Geschwindigkeit, aber nichts WebPageTest-Spezifisches — und die Core Web Vitals selbst bleiben in erster Linie ein Google-Konstrukt. (Verwechseln Sie WebPageTest nicht mit Bings eigenem bing.com/tools/speedtest, das ein Netzwerk-Geschwindigkeitstest ist und kein Tool für die Seiten-Performance.)

Wo das Ganze einzuordnen ist

Das ist das Mitglied für die Tiefendiagnose im Cluster Web-Performance-Tools. Seine Geschwister haben jeweils eine andere Aufgabe: Google Lighthouse ist das Lab-Audit, das den Score von 0–100 erzeugt (und das viele andere Tools intern ausführen); PageSpeed Insights zeigt Field data aus CrUX und einen Lighthouse-Lab-Lauf in einer Oberfläche; der Chrome UX Report (CrUX) ist der Field-Datensatz echter Nutzer, nach dem Google tatsächlich rankt. Für die Metriken, die all diese Tools messen, und die Schwellenwerte, die Google verwendet, beginnen Sie beim Hub Core Web Vitals. Für die gesamte Pipeline, in der diese Tools stehen, siehe den Web-Performance-Cluster.

KI-Zusammenfassung

Eine verdichtete Fassung der Advanced-Version:

• WebPageTest = das Lab-basierte Performance-Tool für die Tiefendiagnose. Kostenlos und Open Source; 2008 von Patrick Meenan entwickelt (als internes AOL-Tool), 2020 von Catchpoint übernommen, Code unter der Polyform-Shield-Lizenz.
• Jedes Ergebnis ist ein konfigurierter Testlauf — eine URL, ein Standort, ein Browser, ein Verbindungsprofil, ein Zeitpunkt — und keine allgemeingültige Messung. Vergleiche haben nur dann Aussagekraft, wenn Sie diese Einstellungen festhalten und konstant halten.
• Lab, nicht Field. Es erzeugt synthetische Lab-Daten und fließt nicht in Googles Core-Web-Vitals-Ranking-Signal ein — dafür sorgt CrUX mit Daten echter Nutzer (sichtbar in PageSpeed Insights und der Search Console). Ein WebPageTest-Lauf belegt auch weder realen Nutzertraffic noch ein Ranking- oder Page-Experience-Ergebnis in der Suche — er dient der Diagnose und liefert nicht die Zahl, nach der Google rankt.
• Der Ablauf: URL → echter, verteilter Teststandort → Browser/Gerät → gedrosseltes Netzwerk → mehrere Wiederholungsläufe, den Median lesen (niemals ein einzelner Lauf — auch wenn selbst der Median eine synthetische Stichprobe bleibt und keine Field data).
• Charakteristische Ansichten: Waterfall (Request für Request, Kennzeichnung Render-blockierender Ressourcen, Weiterleitungsketten), Filmstrip/Video (Bild für Bild; eine Option Highlight Layout Shifts für CLS), Connection View (DNS/TCP/TLS/TTFB) und Core Web Vitals Bild für Bild. Ein Waterfall-Ereignis mit einem Filmstrip-Frame in Deckung zu bringen, ist eine starke Hypothese, kein Beweis — überprüfen Sie diese Vermutung, indem Sie die Ressource isolieren und erneut testen.
• CLS-Rezept: Filmstrip View → Highlight Layout Shifts an, Thumbnail Size Huge, Thumbnail Interval 0,1s — so ertappen Sie einen Font-Swap oder einen Shift durch ein spät geladenes Bild auf frischer Tat.
• Kein Konkurrent zu Lighthouse — Sie können ein Lighthouse-Audit aus WebPageTest heraus ausführen, es ist aber ein eigener, versionierter Report (eigener Score, eigene Audits) und fließt nicht in die nativen Metriken von WebPageTest ein. Weitere fortgeschrittene Funktionen: Scripting und mehrstufige Abläufe (Zugangsdaten, Zustand und Kontingente dokumentieren), Blockieren von Drittanbieter-Domains, eine No-Code-Funktion für Vorher-/Nachher-Vergleiche, die etwa 2022 eingeführt wurde (ihr aktueller Name und ihre Verfügbarkeit wurden in dieser Runde nicht unabhängig erneut bestätigt), eine API und Self-Hosting.
• SEO-Anwendungen: als Googlebot testen, Weiterleitungsketten prüfen, Caching/CDN/ TTFB kontrollieren, JS-Rendering diagnostizieren und Vorher-/Nachher-Belege für Stakeholder erzeugen.
• Merkwürdige Fußnote: Meenan arbeitet inzwischen bei Google, dennoch führt Googles eigene offizielle CWV-Tool-Seite (web.dev/articles/vitals-tools) WebPageTest nicht auf. Das ist eine Kuratierungslücke bei einem Drittanbieter-Tool und kein Hinweis darauf, dass es abgekündigt wäre.
• Grenzen: dichte Oberfläche und Lernkurve, Konto für gespeicherte und private Tests nötig, es diagnostiziert eher, als dass es behebt, und einzelne Läufe können in die Irre führen.

Offizielle Dokumentation

Dokumentation aus Primärquellen (Googles Erwähnungen von WebPageTest, WebPageTests eigene Dokumentation und eine Anmerkung zu Bing).

WebPageTest / Catchpoint

• WebPageTest – Geschichte und Hintergrund — die Entstehungsgeschichte um Meenan und Catchpoint, das Leitbild und die Polyform-Shield-Lizenz.
• WebPageTest — der kostenlose öffentliche Testdienst, inklusive Testformular, Oberfläche für Ergebnisse und Filmstrip sowie der API für programmatisches Testen.

Google (wo es WebPageTest erwähnt — und wo bemerkenswerterweise nicht)

• web.dev – Werkzeuge für Geschwindigkeitsmessungen richtig einordnen — verortet WebPageTest als die fortgeschrittene Option für die Lab-Diagnose und weist darauf hin, dass sich Lighthouse darin ausführen lässt.
• web.dev – Leistung prüfen — WebPageTest für Prüfungen zu Caching, TTFB und CDN.
• web.dev – Werkzeuge für die Core Web Vitals — Googles eigene Übersicht der CWV-Tools, die WebPageTest nicht erwähnt (die Fußnote zur Kuratierungslücke).
• Google Search Central — Core Web Vitals — verweist für Tool-Empfehlungen auf web.dev, statt ein Lab-Tool eines Drittanbieters zu nennen.

Bing / Microsoft

• Keine Dokumentation von Bing oder Microsoft verweist auf WebPageTest als Ranking-Input oder als Empfehlung aus erster Hand. Der Site Scan der Bing Webmaster Tools ist das nächstliegende Pendant aus erster Hand. Allgemeine Hinweise finden Sie in den Bing Webmaster Guidelines.

Zitate aus der Quelle

Dokumentierte Aussagen über WebPageTest. Wo ein Link einen #:~:text=-Anker enthält, springt er zur zitierten Stelle auf der Quellseite.

Google / web.dev — wo WebPageTest hingehört

• “WebPageTest contains an advanced suite of metrics and trace viewers. It enables deep diving into the performance of your site on real mobile hardware with network conditions.” (Übersetzung) „WebPageTest enthält eine fortgeschrittene Sammlung von Metriken und Trace-Viewern. Es ermöglicht, tief in die Performance Ihrer Website auf echter mobiler Hardware unter Netzwerkbedingungen einzutauchen.“ — web.dev, „Werkzeuge für Geschwindigkeitsmessungen richtig einordnen“. Zum Zitat springen
• “WebPagetest will also check static-content caching, time to first byte, and if your site makes effective use of CDNs.” (Übersetzung) „WebPagetest prüft außerdem das Caching statischer Inhalte, die Time to First Byte und ob Ihre Website CDNs effektiv nutzt.“ — web.dev, “Audit performance.” Zum Zitat springen

WebPageTest / Catchpoint — Geschichte, Mission, Lizenz

• “Catchpoint’s 2020 acquisition of WebPageTest, created and open-sourced by Patrick Meenan in 2008, marked a significant milestone.” (Übersetzung) „Die Übernahme des 2008 von Patrick Meenan entwickelten und quelloffen gestellten WebPageTest durch Catchpoint war 2020 ein wichtiger Meilenstein.“ — WebPageTest-Seite zur Geschichte. Quelle
• “slow is the new down, and our mission is to empower you to deliver the best experiences to your users.” (Übersetzung) „langsam ist das neue offline, und unsere Mission ist es, Sie in die Lage zu versetzen, Ihren Nutzern die besten Erlebnisse zu liefern.“ — WebPageTest-Seite zur Geschichte. Quelle
• “The WebPageTest code remains freely accessible under the Polyform Shield license, permitting its use for internal or non-competing commercial projects.” (Übersetzung) „Der WebPageTest-Code bleibt unter der Polyform-Shield-Lizenz frei zugänglich und erlaubt seine Nutzung für interne oder nicht konkurrierende kommerzielle Projekte.“ — Catchpoint, WebPageTest-Seite zur Geschichte. Quelle

Patrick Stox (ich) / Ahrefs — die CLS-Filmstrip-Technik

• “In Filmstrip View, use the following options: Highlight Layout Shifts, Thumbnail Size: Huge, Thumbnail Interval: 0.1 secs.” (Übersetzung) „Verwenden Sie in der Filmstrip View die folgenden Optionen: Highlight Layout Shifts, Thumbnail Size: Huge, Thumbnail Interval: 0.1 secs.“ — aus meinem Ahrefs-Guide zu den Core Web Vitals. Quelle
• “The exception is WebPageTest, although you can also run Lighthouse tests with it as well.” (Übersetzung) „Die Ausnahme ist WebPageTest, wobei sich damit ebenfalls Lighthouse-Tests ausführen lassen.“ — von mir, dazu, wie sich WebPageTest von Lighthouse-basierten Tools unterscheidet. Quelle

MobileMoxie — der Blickwinkel des technischen SEO

• “The tool provides detailed information about the health of your pages and helps analyze things like round trip requests, asset errors, redirects, caching concerns, security information, and more.” (Übersetzung) „Das Tool liefert detaillierte Informationen über den Zustand Ihrer Seiten und hilft dabei, Dinge wie Round-Trip-Requests, Fehler bei Assets, Weiterleitungen, Caching-Probleme, Sicherheitsinformationen und mehr zu analysieren.“ — MobileMoxie, über WebPageTest für technisches SEO. Quelle

WebPageTest-Cheatsheet

Wo es im Vergleich zu den anderen Tools steht

Die Ansichten

CLS-Rezept (meines)

• Filmstrip View → Highlight Layout Shifts an → Thumbnail Size: Huge → Thumbnail Interval: 0,1 secs. Achten Sie auf das Bild, in dem das Layout springt (häufig ein Web-Font-Swap oder ein spät geladenes Bild bzw. eine Werbeanzeige).

Kurzfakten

• Lab, nicht Field — fließt nicht in Googles CWV-Ranking-Signal ein (dafür sorgt CrUX).
• Lesen Sie den Median, niemals einen einzelnen Lauf — die Performance schwankt von Lauf zu Lauf.
• Sie können Lighthouse innerhalb von WebPageTest ausführen — es ist kein Entweder-oder.
• Open Source unter der Polyform-Shield-Lizenz; Self-Hosting ist möglich.
• Meenan (der Entwickler) arbeitet inzwischen bei Google, dennoch führt web.dev/articles/vitals-tools WebPageTest nicht auf — eine Kuratierungslücke, keine Abkündigung.

Ein WebPageTest-Lauf — Checkliste

So erhalten Sie ein belastbares, nützliches Ergebnis statt eines irreführenden:

• Teststandort nahe Ihrer echten Zielgruppe gesetzt (Entfernung verändert die Zahlen).
• Gerät + Verbindungsprofil passen zu Ihren Nutzern (z. B. emuliertes Mobilgerät in einem gedrosselten Netzwerk), nicht zur Glasfaserleitung im Büro.
• Mehrere Wiederholungsläufe aktiviert — und Sie lesen den Median, nicht einen einzelnen Lauf.
• Den Waterfall auf Render-blockierende Ressourcen und überflüssige Weiterleitungs-Hops geprüft.
• Die Connection View auf eine langsame TTFB oder zu viele separate Verbindungen geprüft.
• Den Filmstrip genutzt, um zu sehen, wann der Hauptinhalt gerendert wird — und für CLS Highlight Layout Shifts mit Intervallen von 0,1s und Huge-Thumbnails aktiviert.
• Bestätigt, dass Sie das Ergebnis als Lab-Daten behandeln — das eigentliche Ranking-Signal gegen CrUX gegengeprüft (PageSpeed Insights / Search Console).
• Für einen verdächtigen Drittanbieter Domain- bzw. Request-Blocking genutzt, um dessen tatsächliche Kosten zu messen.
• Für Login- und Checkout-Abläufe Scripting genutzt, statt eine kalte Startseite zu testen.
• Einen Vorher-/Nachher-Filmstrip gespeichert, wenn Sie Stakeholdern einen Fix vorschlagen.

Tools, die gut mit WebPageTest zusammenspielen

• WebPageTest selbst (webpagetest.org) — das kostenlose öffentliche Lab-Tool, dazu die API und eine kostenpflichtige Pro-Stufe für Volumen und private Tests.
• PageSpeed Insights — der schnelle Weg, die Field data (CrUX) zu prüfen, die WebPageTest nicht erzeugen kann, damit Sie wissen, ob sich das Ranking-Signal tatsächlich bewegt hat.
• Google Search Console — Core Web Vitals report — findet Gruppen fehlerhafter Seiten im großen Maßstab über die Website hinweg; nehmen Sie anschließend eine repräsentative URL zur Diagnose mit in WebPageTest.
• Chrome DevTools Performance Panel — der lokale, login-freundliche Begleiter für Lab-Profiling, wenn Sie keine verteilten Standorte brauchen.
• Google Lighthouse — ausführbar innerhalb von WebPageTest oder eigenständig in den DevTools bzw. per CLI für das Audit von 0–100.
• CrUX Vis (cruxvis.withgoogle.com) — visualisiert den Field-Trend echter Nutzer über die Zeit, um zu bestätigen, dass ein in WebPageTest diagnostizierter Fix bei echten Nutzern angekommen ist. (Siehe Chrome UX Report (CrUX).)

WebPageTest-Fehler, die falsche Sicherheit erzeugen

Einen Lab-Lauf als Googles Field-Urteil behandeln

WebPageTest liefert synthetische Daten aus dem Gerät, dem Standort, dem Browser und dem Netzwerkprofil, die Sie ausgewählt haben. Nutzen Sie es, um Ursachen zu diagnostizieren; nutzen Sie CrUX oder eigenes RUM, um echte Nutzer und Googles CWV-Bewertung zu beschreiben.

Läufe mit unterschiedlichen Testeinstellungen vergleichen

Ein geänderter Standort, eine geänderte Verbindung, ein anderer Browser, ein anderer Cache-Zustand oder eine andere Anzahl von Läufen kann die getestete Code-Änderung überlagern. Speichern Sie die Konfiguration und vergleichen Sie Gleiches mit Gleichem.

Den Hauptscore optimieren statt den Waterfall

Der Wert von WebPageTest liegt in der Abfolge der Requests, im Verbindungsaufbau, in den Filmstrips und im Timing der Metriken. Führen Sie die langsame Metrik auf einen konkreten Request oder ein konkretes Main-Thread-Ereignis zurück, statt eine Note isoliert zu tunen.

Eine Änderung anhand eines einzigen Laufs beurteilen

Lab-Tests schwanken. Führen Sie mehrere Tests mit demselben Profil durch und vergleichen Sie repräsentative Ergebnisse; gehen Sie Ausreißern nach, statt den schnellsten Lauf auszuwählen.

Nur die Startseite testen

Unterschiedliche Templates haben unterschiedliche LCP-Elemente, Skripte, Drittanbieter und Cache-Verhalten. Beziehen Sie die Seiten ein, auf denen Nutzer und Field data das tatsächliche Problem zeigen.

Eine Performance-Änderung in WebPageTest nachweisen

Kontrollierter Vorher-/Nachher-Test

Durchzuführender Test: Speichern Sie eine Konfiguration aus Standort/Browser/Netzwerk/Cache und führen Sie mehrere Tests für die unveränderte und die geänderte Version durch. Erwartetes Ergebnis: Die betrachtete Metrik und ihre Ursache im Waterfall verbessern sich über repräsentative Läufe hinweg. Deutung bei Fehlschlag: Die Änderung ist wirkungslos, oder die Testschwankung übersteigt den Effekt. Beobachtungszeitraum: unmittelbares Lab-Ergebnis. Auslöser für ein Rollback: eine konsistente Verschlechterung bei der Zielmetrik oder einem benachbarten Core Web Vital.

Test der Request-Abfolge

Durchzuführender Test: Vergleichen Sie Waterfalls, nachdem Sie Preload, Priorität, blockierendes CSS/JS oder das Caching geändert haben. Erwartetes Ergebnis: Der betreffende Request startet früher, überträgt weniger Bytes oder umgeht im erwarteten Cache-Zustand das Netzwerk. Deutung bei Fehlschlag: Der Hint bzw. die Konfiguration wurde nicht angewendet, oder eine andere Abhängigkeit steuert die Abfolge. Beobachtungszeitraum: unmittelbar. Auslöser für ein Rollback: Die Änderung verzögert einen wichtigeren Request oder erzeugt Fehler.

Test der visuellen Korrektheit

Durchzuführender Test: Prüfen Sie Filmstrip und Video sowie die Hervorhebung von Layout Shifts für dasselbe Vorher-/Nachher-Profil. Erwartetes Ergebnis: Schnelleres Rendering führt nicht zu fehlenden Inhalten, Flackern oder neuen Shifts. Deutung bei Fehlschlag: Die numerische Verbesserung ging zulasten der visuellen Korrektheit. Beobachtungszeitraum: jeder repräsentative Viewport vor dem Release. Auslöser für ein Rollback: kaputte Inhalte oder eine neue sichtbare Instabilität.

Ressourcen, die Ihre Zeit wert sind

Verwandte Texte von mir

• Core Web Vitals: A Complete Guide (Ahrefs) — enthält mein WebPageTest-Filmstrip-Rezept zur Diagnose von Cumulative Layout Shift, die Einordnung von WebPageTest gegenüber Lighthouse und die Metriken, die WebPageTest misst, samt der Funktionsweise der Ranking-Seite. (Diese Seite hat meinen früheren Beitrag “Advanced Guide to PageSpeed Insights” aufgenommen, der nun hierher weiterleitet.)
• The Beginner’s Guide to Technical SEO (Ahrefs) — wo Web-Performance im größeren Bild steht.

Meine Vorträge

• Page Experience Update — TMC, June 2021 (SlideShare) — behandelt dieselbe WebPageTest-Filmstrip-/CLS-Technik in Vortragsform.
• A Crash Course in Technical SEO — Beer & SEO Meetup, May 2019 (SlideShare) — WebPageTest als Teil des Werkzeugkastens für technisches SEO, damals im Jahr 2019.

Aus der Branche

• WebPageTest – Geschichte und Hintergrund — die Primärquelle für Geschichte, Mission und Polyform-Shield-Lizenz.
• Werkzeuge für Geschwindigkeitsmessungen richtig einordnen (web.dev) — Googles eigene Verortung von WebPageTest unter den Werkzeugen für Labortests.
• Leistung prüfen (web.dev) — WebPageTest für Prüfungen zu Caching, TTFB und CDN.
• WebPageTest für die Bewertung des technischen SEO einrichten (MobileMoxie) — der am nächsten liegende vorhandene Einrichtungsleitfaden aus SEO-Perspektive mit Googlebot-User-Agent, Weiterleitungen, Caching und Asset-Fehlern.
• Vollständiger Leitfaden zur Nutzung von WebPageTest (Kinsta) — eine umfassende allgemeine Erklärung zu Geschichte, Einrichtung, Interpretation der Ergebnisse und Preisen.
• WebPageTest: Leitfaden für Leistungstests im Web (DebugBear) — vom Anbieter selbst verfasst, aber eine gute Aufschlüsselung von Mittelwertbildung über mehrere Läufe, Waterfall, Filmstrip, Connection View und Scripting.

Testen Sie sich: WebPageTest

Fünf kurze Fragen dazu, was WebPageTest ist, wie man es liest und wo es hingehört. Wählen Sie jeweils eine Antwort und kontrollieren Sie anschließend Ihre Auswahl.

Änderungsprotokoll