Website Speed Test: Sofortiger Start und alle Begriffe erklärt.

Website Speed Test heißt: Largest Contentful Paint (LCP) unter 2,5 Sekunden, Interaction to Next Paint (INP) unter 200 Millisekunden, Cumulative Layout Shift (CLS) unter 0,1, jeweils am 75. Perzentil echter Besuche. Das steht so bei Google, nicht in einem Blog. Wer nur von seinem Laptop in Berlin misst, kennt die Seite in Lagos nicht.

Ich fange meist mit dem Chrome Inspector an und schaue im Network-Tab, ob ein Bild oder Video viel Kapazität frisst. Dann PageSpeed Insights. Und dann – ein Test aus einer anderen Stadt – aus einem anderen Land – auf einem anderen Kontinent.

Lab ist eine Maschine. Feld sind Menschen.

Lab (Lighthouse, ein Klick in PageSpeed Insights unter „Diagnose"): ein festes Gerät, ein festes Netz, kein Mensch der tippt. Gut zum Finden eines fetten JPEGs. Schlecht als Urteil über Japan.

Feld (Chrome User Experience Report, kurz CrUX): echte Chrome-Nutzer, 28 Tage, 75. Perzentil. Das ist die Zahl, an der Google die Seite bewertet. Eine Origin besteht Core Web Vitals, wenn LCP, INP und CLS dort alle „good" sind.

INP hat First Input Delay (FID) im März 2024 abgelöst. Steht in einem Text noch FID als Core Web Vital, ist der Text alt.

Die Schwellen, die zählen

Metrik	Was sie misst	Gut	Geht so	Schlecht
LCP	Wann das größte sichtbare Stück da ist	≤ 2,5 s	2,5 s bis 4 s	> 4 s
INP	Wie lange ein Klick, Tap oder Tastendruck bis zum nächsten Paint braucht	≤ 200 ms	200 ms bis 500 ms	> 500 ms
CLS	Wie sehr sich das Layout ohne dein Zutun verschiebt	≤ 0,1	0,1 bis 0,25	> 0,25
TTFB	Erstes Byte der Antwort. Kein Core Web Vital, aber die Untergrenze für LCP	≤ 0,8 s	0,8 s bis 1,8 s	> 1,8 s
FCP	Erster sichtbarer Inhalt. Diagnose, nicht Ranking-Vital	≤ 1,8 s	1,8 s bis 3 s	> 3 s

Quelle der drei Vitals: web.dev/articles/vitals, zuletzt aktualisiert 31. Oktober 2024, Schwellen 2026 unverändert. TTFB: web.dev/articles/ttfb, Stand 18. November 2025. FCP: dieselbe Vitals-Familie, Lighthouse nutzt 1,8 s als „good".

Mobile und Desktop haben dieselben Zahlen. Kalibriert ist das an mittelmäßigem Mobilfunk. Deshalb fällt fast jede Origin zuerst auf dem Telefon durch.

Der 20-Minuten-Pfad

1. Network-Tab. Chrome, F12, Network, Reload. Sortier nach Size. Was über 300 KB liegt und ein Bild ist, ist der erste Verdacht.
2. PageSpeed Insights. Feld (CrUX) und Lab (Lighthouse) auf einer Seite. URL oben in den Starter.
3. Lighthouse lokal. DevTools, Tab Lighthouse, Kategorie Performance, Device Mobile. Dieselbe Engine wie das Lab in PSI, nur bei dir.
4. Eine zweite Stadt. WebPageTest, Location Mumbai oder São Paulo, nicht nur „default". Wenn TTFB dort explodiert, liegt der Server in der falschen Region oder ohne CDN-Edge.
5. Ein zweiter Browser. Safari auf einem echten iPhone lügt anders als Chrome auf einem Pixel. Dazu unten.

Tool-Karte: wofür welches Ding gut ist

Tool	Misst	Orte	Preisgefühl
PageSpeed Insights	CrUX-Feld plus Lighthouse-Lab, LCP/INP/CLS	Lab: ein Google-Standort. Feld: echte Nutzer weltweit, aggregiert	frei
Chrome DevTools, Network + Performance + Lighthouse	Bytes, Waterfall, LCP-Element, Layout Shifts	dein Schreibtisch	frei
WebPageTest	Filmstrip, TTFB, LCP, Request-Waterfall, Script-Blocking	du wählst die Stadt, das Gerät, die Verbindung	frei in der Grundstufe, API kostenpflichtig
GTmetrix	Lighthouse plus eigene Waterfall-Ansicht	wenige feste Regionen, mehr in Paid	frei knapp, Rest Abo
CrUX / CrUX Vis	28-Tage-Feld, Origin oder URL, wenn genug Traffic	echte Nutzer, keine Stadt-Auswahl	frei
Search Console, Bericht Core Web Vitals	URLs deiner Property, Feld, 28 Tage	deine echten Besucher	frei, Property muss verifiziert sein
DebugBear, SpeedCurve, Calibre	Monitoring, Budgets, Lab auf Zeitachse	mehrere Regionen	Abo
Catchpoint	Synthetik plus RUM, Enterprise	hundert Plus Standorte	teuer, ernst
UptimeRobot	ob die Kiste antwortet, Response Time	wenige Probe-Standorte	frei reicht zum Leben
Pingdom	Uptime plus Transaktionen, Speed in Paid	mehrere Regionen	Abo
BrowserStack, LambdaTest	ob die Seite in Safari, Firefox, Edge, alten iPhones überhaupt läuft	Gerätewolke, kein Speed-Ranking	Abo

Uptime ist nicht Speed. UptimeRobot sagt dir, ob nach 30 Sekunden noch ein HTTP 200 kommt. Die Response Time dort ist grob TTFB, nicht LCP. Ich habe dort einen Account, weil die Frage „lebt die Seite" eine andere ist als „kann jemand in Jakarta den Hero sehen".

Warum einfache Speedtests die Welt weglassen

PageSpeed Insights im Lab startet von einem Google-Rechner. CrUX darunter mittelt echte Nutzer, ohne dir Tokio gegen Nairobi zu zeigen. Für eine Shop-Seite mit Kunden in DE und US ist das Mittel eine Lüge mit korrekter Formel.

Wer globale Erreichbarkeit will, braucht synthetische Tests mit wählbarem Standort. WebPageTest ist der freie Einstieg: Location, Browser, 4G. Catchpoint und DebugBear sind dasselbe als Dauerauftrag. Ein Ping von einem Uptime-Dienst aus den USA misst den Handshake, nicht das größte Bild.

DNS, TLS, erstes Byte, dann HTML, dann CSS, dann das Hero-Bild. Eine Origin in Nürnberg ist in Frankfurt schnell und in Sydney erst einmal 250 ms auf dem Kabel, bevor irgendwer Pixel malt. Deshalb: eine Messung hier, eine Messung dort, erst dann ein Urteil.

Browser, die Chrome nicht ist

Lighthouse ist Chromium. Safari auf iOS hat anderen JavaScript-JIT, andere Cache-Regeln, andere Schriftladung. Firefox schiebt Tracker in den Strict-Mode. Ein Core-Web-Vitals-Pass in Chrome sagt nichts über einen Checkout in Safari 17.

Praktisch:

• Ein echtes iPhone, Safari, einmal den Checkout durchklicken. Nicht der Simulator allein.
• Firefox, Tracking Protection an, Network-Tab. Drittanbieter-Scripts, die Chrome noch durchlässt, bleiben hier oft liegen.
• BrowserStack oder LambdaTest, wenn du kein Gerätebrett hast: iPhone-Safari, ein altes Samsung, iPad. Das ist Funktions-Test. Speed dort ist grob, weil die Farm nicht dein 4G ist.
• WebPageTest kann Chrome, Firefox, Edge auf echten Boxen in der gewählten Stadt. Safari-iOS bleibt das physische Gerät oder die Farm.

Was du an der Seite drehst, wenn die Zahl rot ist

• LCP: Hero als modernes Format (AVIF oder WebP), feste Breite, fetchpriority="high", nicht hinter einem Slider. TTFB unter 0,8 s, sonst kann LCP die 2,5 s nicht schaffen.
• INP: lange Tasks auf dem Main Thread. Chat-Widgets, Tag-Manager-Friedhöfe, Hydration die 400 ms blockt. Total Blocking Time im Lab ist der Proxy, weil Lighthouse nicht klickt.
• CLS: Breite und Höhe an Bildern und Embeds. Kein Banner das nach 2 s von oben reinfällt. Schriften mit font-display: swap und einem passenden Fallback, der ähnlich breit läuft.

Ein YouTube-iframe im Artikel ist ein klassischer CLS-und-LCP-Täter. Facades, also Vorschaubild erst, Player nach Klick, sind hier die Regel, nicht die Kür.

Mit einem AI-Agenten in 12 Minuten selbst messen

Du brauchst Node, sonst nichts. Der Agent schreibt das Skript, du lässt es gegen deine URL laufen.

npx --yes lighthouse https://example.com --only-categories=performance --form-factor=mobile --chrome-flags="--headless" --output=json --output-path=./lh.json

Dann TTFB ohne Theater:

curl -o /dev/null -s -w "dns:%{time_namelookup} connect:%{time_connect} tls:%{time_appconnect} ttfb:%{time_starttransfer} total:%{time_total}\n" https://example.com

Playwright, wenn du klicken willst (INP im Lab gibt es sonst nicht):

npx --yes playwright install chromium
# ein 40-Zeilen-Skript: page.goto, page.click, performance.getEntries

Prompt an den Agenten, der reicht: „Schreib ein Node-Skript, das Lighthouse mobil gegen diese URL fährt, LCP/TBT/CLS aus JSON zieht, und curl-TTFB danebenlegt. Keine Dependencies außer lighthouse. Exit 1 wenn LCP über 2,5 s."

Das ersetzt kein CrUX. Es ersetzt den Nachmittag, in dem du 40 URLs von Hand durch PSI jagst.

Wer mehrere Städte will und keinen Enterprise-Vertrag hat: WebPageTest hat eine API. Ein Agent kann drei Locations hintereinander anstoßen und die JSON-Summaries in eine Tabelle kippen. Das ist der günstige Weg zu „global", ohne eigene Box in Mumbai.

Ein eigenes Website-Speedtest-Tool: was sich lohnt

Google in die Seite zu iframeen geht nicht sauber. PageSpeed Insights schickt X-Frame-Options. Selbst wenn, würde der Embed genau die Metriken ruinieren, die der Artikel erklärt.

Drei Stufen, aufsteigend:

1. Starter, wie oben. Ein Feld, drei Buttons, Tests laufen bei Google und WebPageTest. Bauzeit: unter einer Stunde. Steht in diesem Artikel.
2. Probe aus der eigenen Flotte. Ein kleiner Dienst auf der Mothership: URL rein, von Nürnberg (nbg1) und Falkenstein (fsn1) je ein HEAD plus TTFB, DNS, TLS. Zwei deutsche Standorte, als DE beschriftet. Kein „global". Bauzeit: ein Nachmittag, wenn der Agent den Service schreibt und du die Boxen schon hast.
3. Welt über fremde Augen. Dieselbe Oberfläche, hinten WebPageTest-API oder ein Catchpoint-Lite. Mumbai, Virginia, São Paulo als Checkbox. Das ist das Produkt, das einfache Speedtests nicht sind. Bauzeit: zwei Tage für eine v1, plus API-Kosten.

Feld-Daten (CrUX) kannst du über die CrUX API dazulegen, sobald die Origin genug Chrome-Traffic hat. Unter der Schwelle bleibt die Kachel leer, und das muss die UI sagen, nicht eine erfundene Zahl.

Was wir nicht bauen sollten: ein Lighthouse-Klon im Browser-Tab des Lesers, der so tut als wäre er die Welt. Der lügt in dieselbe Richtung wie der eine Klick auf PSI.

Fakten-Tabelle

Aussage	Korb	Woher
Core Web Vitals 2026: LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1, je 75. Perzentil, mobil und desktop gleiche Schwellen	Fakt	web.dev/articles/vitals, Stand 31.10.2024. Branchentexte 2026 bestätigen unveränderte Gut-Schwellen.
INP hat FID im März 2024 als Core Web Vital ersetzt	Fakt	Dieselbe Seite, Lifecycle Stable für LCP, CLS, INP.
TTFB gut ≤ 0,8 s, schlecht > 1,8 s, 75. Perzentil. Kein Core Web Vital	Fakt	web.dev/articles/ttfb, Stand 18.11.2025.
FCP gut ≤ 1,8 s in der CrUX-Definition von HTTP Archive / web.dev	Fakt	httparchive.org/reports/chrome-ux-report, „Good First Contentful Paint".
PSI-Lab kommt von einem Standort, CrUX mittelt echte Nutzer ohne Stadtfilter	Fakt	PageSpeed-Insights-Produkt, CrUX-Doku.
Ein iframe von PSI in diesem Artikel würde LCP und CLS der Seite selbst verschlechtern	These	MDN zu iframe-Kosten, plus die X-Frame-Policy von Google-Tools.
Zwei Hetzner-Standorte (nbg1, fsn1) reichen für TTFB aus Deutschland, nicht für „global"	These	Physik der Strecke plus unsere Flotte. Mumbai bleibt eine andere Messung.

Quellen

1. https://web.dev/articles/vitals: Core Web Vitals, Schwellen, Lab gegen Feld.
2. https://web.dev/articles/ttfb: TTFB-Definition und 0,8 / 1,8 s.
3. https://web.dev/articles/lcp · https://web.dev/articles/inp · https://web.dev/articles/cls
4. https://pagespeed.web.dev/: PageSpeed Insights.
5. https://developer.chrome.com/docs/crux: Chrome User Experience Report.
6. https://www.webpagetest.org/: Standort wählen.
7. https://httparchive.org/reports/chrome-ux-report: Feld-Verteilung über Origins.
8. https://developer.mozilla.org/en-US/docs/Learn_web_development/Extensions/Performance/HTML: iframe-Kosten.
9. https://github.com/GoogleChrome/lighthouse: CLI für den Agenten-Lauf.

Schnitt der Schwellen: 16. September 2026, gegen web.dev. Die Gut-Zahlen haben sich seit dem INP-Wechsel 2024 nicht bewegt.