Kurz gesagt:
- Ein klar strukturierter Workflow zum Website-Performance-Testing umfasst sechs Schritte von der Baseline-Erstellung bis zum kontinuierlichen Monitoring. Durch konsequente Nutzung von Lab- und Felddaten sowie automatisierte Tests werden verlässliche Messwerte erzielt und Optimierungen zielgerichtet umgesetzt.
Ein reproduzierbarer Workflow zum Testen der Website-Performance folgt sechs klaren Schritten: Baseline messen, synthetische Lab-Tests durchführen, Felddaten (RUM) erfassen, Flaschenhälse diagnostizieren, Maßnahmen nach Business-Impact priorisieren und kontinuierliches Monitoring etablieren. Wer diesen Ablauf konsequent umsetzt, bekommt verlässliche Messwerte statt Zufallsergebnisse.
Die sechs Schritte im Überblick:
- Baseline erstellen: Top-Conversion-Seiten und Template-Cluster auswählen und mehrere Testläufe durchführen, um den Medianwert zu speichern
- Synthetische Tests (Lab): PageSpeed Insights, Lighthouse, WebPageTest und GTmetrix mit definierten Standorten und Throttling-Profilen
- Felddaten (RUM): CrUX, Performance API (NavigationTiming, ResourceTiming, UserTiming) und PerformanceObserver für echte Nutzerdaten
- Diagnose: Wasserfall-Analysen, Main-Thread-Profiling, Drittanbieter-Inventar
- Priorisierung: Quick Wins zuerst, dann mittelfristige Fixes, dann Architektur-Refactors
- Monitoring & Automatisierung: Lighthouse CI, WebPageTest API, RUM-Alerts und CI/CD-Gates
Die wichtigsten Tools: PageSpeed Insights, WebPageTest, GTmetrix, Chrome DevTools mit Lighthouse, die Performance API sowie Lighthouse CI und die WebPageTest API für die Automatisierung.
Inhaltsverzeichnis
- Was solltest du messen? Core Web Vitals und ergänzende KPIs
- Schritt 1: Wie legst du eine aussagekräftige Baseline fest?
- Schritt 2: Synthetische Lab-Tests — welche Tools leisten was?
- Schritt 3: Wie sammelst du echte Felddaten mit RUM und der Performance API?
- Schritt 4: Wie diagnostizierst du Flaschenhälse im Wasserfall?
- Schritt 5: Wie priorisierst du Maßnahmen nach Impact und Aufwand?
- Schritt 6: Wie automatisierst du Tests und verhinderst Regressionen?
- Bulk-Tests: Wie testest du hunderte URLs gleichzeitig?
- Wie testet und optimiert Werbeeinfach in der Praxis?
- Wichtige Erkenntnisse
- Werbeeinfach übernimmt deinen Performance-Workflow
- FAQ
- Nützliche Quellen und weiterführende Tools
Was solltest du messen? Core Web Vitals und ergänzende KPIs
Core Web Vitals sind die zentralen Leistungskennzahlen für User Experience und SEO-Ranking. Die Zielwerte sind klar definiert: LCP soll schnell sein, INP sehr kurz, und CLS gering. Wer diese Schwellen unterschreitet, landet bei Google in der grünen Zone.
Daneben gibt es weitere Metriken, die den Diagnoseprozess schärfen:
- TTFB (Time to First Byte): Zeigt Serverprobleme und CDN-Konfigurationsfehler; Zielwert unter 800 ms
- FCP (First Contentful Paint): Erster sichtbarer Inhalt; Zielwert unter 1,8 s
- TBT (Total Blocking Time): Proxy für INP im Lab; unter 200 ms anstreben
- Speed Index: Wie schnell der sichtbare Bereich visuell vollständig wird
Warum Perzentile statt Mittelwerte? Google bewertet Core Web Vitals am 75. Perzentil der Seitenaufrufe. Ein Mittelwert kann durch schnelle Aufrufe unter Desktop-Bedingungen verzerrt werden und verbirgt, dass 25 % der Nutzer deutlich schlechtere Erfahrungen machen. Wer nur den Durchschnitt betrachtet, optimiert am echten Problem vorbei.
Performance-Budgets gehören direkt an Conversion-KPIs gekoppelt. Ohne klar definierte Ziele bleibt der ROI-Nachweis aus. Ein konkretes Beispiel: Ein WooCommerce-Shop mit 10.000 Besuchern pro Monat und 2 % Conversion-Rate gewinnt bei einer Verbesserung des LCP von 4 s auf 2 s messbar mehr Abschlüsse, weil Ladezeit direkt mit Absprungrate korreliert.
Schritt 1: Wie legst du eine aussagekräftige Baseline fest?
Bevor du irgendetwas änderst, brauchst du einen objektiven Ausgangspunkt. Ohne Baseline weißt du nicht, ob eine Maßnahme geholfen hat.
Welche Seiten testen?
- Top-Conversion-URLs (Checkout, Produktdetailseiten, Landingpages)
- Template-Cluster: je eine repräsentative URL pro Template-Typ (Kategorie, Blog, Startseite)
- Traffic-Segmente: Mobile und Desktop getrennt erfassen
- Seiten mit bekannten Performance-Problemen aus der Google Search Console
Protokoll für die erste Baseline-Erhebung:
- Standort wählen: Frankfurt oder Amsterdam für mitteleuropäische Nutzer
- Geräteprofil festlegen: Mobil (Moto G Power, simuliertes 4G) und Desktop separat
- Cache-Status definieren: Cold Cache für den ersten Lauf, dann Warm-Cache-Läufe
- Mehrere Testläufe pro URL durchführen und den Medianwert als Referenz verwenden
- Lab-Werte (Lighthouse-Score, LCP, TBT, CLS) und verfügbare CrUX-Felddaten speichern
- Ergebnisse in einer Tabelle mit Datum, Tool-Version und Konfiguration dokumentieren
Eine erste Baseline lässt sich in einer Woche aufbauen: Tag 1–2 Seitenauswahl und Tool-Setup, Tag 3–4 Testläufe und Datenerfassung, Tag 5 Auswertung und Dokumentation. Wer diesen Schritt überspringt, optimiert blind.
Schritt 2: Synthetische Lab-Tests — welche Tools leisten was?
Lab-Tests sind reproduzierbar und liefern detaillierte Diagnosedaten. Sie zeigen, was unter kontrollierten Bedingungen passiert, und eignen sich ideal für Vorher-Nachher-Vergleiche.
Die wichtigsten Tools und ihre Stärken:
- PageSpeed Insights / Lighthouse: Kombiniert Lab-Daten (Lighthouse-Analyse) mit echten CrUX-Felddaten für dieselbe URL. Kostenlos, direkt in Chrome DevTools integriert, ideal als Einstiegspunkt.
- WebPageTest: Wasserfall-Diagramme, Filmstrip-Ansicht, Multi-Location-Tests (u. a. Frankfurt), Applied Throttling für präzise Netzwerksimulation. Die API erlaubt automatisierte Batch-Tests.
- GTmetrix: Wasserfall-Analyse mit historischen Verläufen; gut für regelmäßige Vergleiche über Zeit.
| Dimension | PageSpeed Insights | WebPageTest | GTmetrix |
|---|---|---|---|
| Messtyp | Lab + Feld (CrUX) | Lab (synthetisch) | Lab (synthetisch) |
| Metriken | LCP, INP, CLS, FCP, TBT | LCP, CLS, TBT, TTFB, Wasserfall | LCP, TBT, CLS, Wasserfall |
| Standorte / Throttling | Google-Server, simuliert | Weltweit inkl. Frankfurt, Applied | Weltweit, simuliert |
| Bulk-Fähigkeit | PSI API (Rate-Limit) | WPT API, Scripting | Eingeschränkt |
| Monitoring / Alerts | Nein (nur manuell) | Ja (WPT Monitoring Jobs) | Ja (GTmetrix Monitoring) |
| Kosten | Kostenlos | Kostenlos / Pro-Pläne | Kostenlos / Pro-Pläne |
Für mitteleuropäische Projekte empfiehlt sich Frankfurt als primärer Teststandort, weil er die tatsächliche Latenz für DACH-Nutzer am besten abbildet. Applied Throttling in WebPageTest ist genauer als simuliertes Throttling, weil es das Netzwerk auf Paketebene drosselt statt nur die Bandbreite zu begrenzen.
Profi-Tipp: Lege WPT-Skripte und Lighthouse-Konfigurationsdateien (.lighthouserc.json) versioniert im Repository ab. So laufen CI/CD-Tests immer mit identischen Parametern, und Konfigurationsabweichungen verfälschen keine Ergebnisse.
Schritt 3: Wie sammelst du echte Felddaten mit RUM und der Performance API?
Lab-Daten und Felddaten müssen kombiniert werden. Lighthouse zeigt, was unter Laborbedingungen passiert. CrUX und RUM zeigen, was echte Nutzer erleben, und genau diese Daten fließen in Googles Ranking ein.
Verfügbare Quellen:
- CrUX (Chrome User Experience Report): Aggregierte Felddaten aus Chrome-Browsern, abrufbar über PageSpeed Insights oder die CrUX API. Gut für Top-Pages mit ausreichend Traffic.
- Eigenes RUM mit dem
web-vitals-Paket: Liefert granulare Daten pro Nutzer, Gerät und Verbindungstyp. Ideal für detailliertes Slicing.
Die Performance API stellt über PerformanceObserver und performance.getEntries() hochpräzise Zeitstempel direkt im Browser bereit. Ein einfaches Erfassungsmuster sieht so aus:
const observer = new PerformanceObserver((list) => {
for (const entry of list.getEntries()) {
// Metrik an Analytics-Endpoint senden
navigator.sendBeacon('/analytics', JSON.stringify({
name: entry.name,
value: entry.startTime,
url: location.href
}));
}
});
observer.observe({ type: 'largest-contentful-paint', buffered: true });
observer.observe({ type: 'layout-shift', buffered: true });
Mit performance.mark() und performance.measure() lassen sich zusätzlich anwendungsspezifische Zeitpunkte erfassen, etwa die Dauer eines Warenkorb-Ladevorgangs oder eines Login-Prozesses. Diese Werte lassen sich direkt an ein Telemetrie-Endpoint senden und in Dashboards auswerten.
Segmentierungsempfehlungen für aussagekräftiges Reporting:
- Gerät: Mobil vs. Desktop getrennt auswerten
- Verbindungstyp: 4G, 3G, WLAN unterscheiden
- Geografie: DACH-Nutzer vs. internationale Besucher
- Immer am 75. Perzentil messen, nicht am Mittelwert
Profi-Tipp: Nutze CrUX und PSI für Top-Pages und ergänze eigenes RUM für detailliertes Slicing nach Nutzergruppen. Beide Quellen zusammen geben dir ein vollständiges Bild.
Schritt 4: Wie diagnostizierst du Flaschenhälse im Wasserfall?
Ein Wasserfall-Diagramm zeigt die Ladereihenfolge aller Ressourcen. Wer es lesen kann, findet Probleme in Minuten statt Stunden.
Worauf du im Wasserfall achtest:
- Lange TTFB-Balken: Zeigen Serverprobleme, fehlende Caching-Schichten oder langsame Datenbankabfragen
- Render-blocking CSS/JS: Ressourcen, die den Aufbau des DOM blockieren und den FCP verzögern
- Wasserfall-Kaskaden: Ressourcen, die erst nach dem Laden anderer angefordert werden (Ketten verlängern LCP)
- Große Ressourcen ohne Komprimierung: Erkennbar an unverhältnismäßig langen Downloadbalken
Für die INP-Diagnose hilft das Main-Thread-Profiling in Chrome DevTools. Long Tasks (über 50 ms) blockieren die Interaktivität. Das Flamechart-Panel zeigt, welche Skripte die meiste Zeit beanspruchen. Mit dem Coverage-Panel lässt sich ungenutztes JavaScript und CSS identifizieren, das beim ersten Laden übertragen wird.
Drittanbieter-Skripte sind oft unterschätzte Leistungskiller. Ein strukturiertes Vorgehen: Alle externen Domains inventarisieren, dann mit der „Block domain“-Funktion in WebPageTest oder Chrome DevTools einzeln blockieren und messen, wie sich LCP und TBT verändern. Wer den tatsächlichen Einfluss eines Tag-Manager-Skripts oder eines Chat-Widgets kennt, kann fundierte Entscheidungen treffen.
Profi-Tipp: Kombiniere Filmstrip, Wasserfall und RUM-Slicing: Der Filmstrip zeigt, wann etwas visuell sichtbar wird. Der Wasserfall erklärt warum. RUM-Slicing bestätigt, ob das Problem bei echten Nutzern auftritt. Erst alle drei zusammen ergeben eine belastbare Diagnose.
Schritt 5: Wie priorisierst du Maßnahmen nach Impact und Aufwand?
Nicht jede Optimierung lohnt sich gleich. Die Priorisierungslogik folgt einer einfachen Formel: Impact = Traffic × Conversion-Einfluss × erwartete Metrikverbesserung. Den Aufwand schätzt du in Story-Points oder Personentagen.
Quick Wins (0–6 Wochen, geringer Aufwand, hoher Impact):
- Bilder in WebP oder AVIF konvertieren,
widthundheightsetzen - Hero-Bild mit
<link rel="preload">vorladen font-display: swapfür Webfonts setzen- Brotli oder GZIP auf dem Server aktivieren
- Browser-Caching und CDN-Konfiguration prüfen
- Render-blocking JS mit
deferoderasyncladen
Hosting und Architektur sind dabei oft der größte Hebel. Ein Wechsel zu einer performanten Hosting-Plattform kann den LCP stärker verbessern als alle CSS/JS-Mikro-Optimierungen zusammen. Das gilt besonders für WordPress-Seiten auf überlasteten Shared-Hosting-Umgebungen.
| Maßnahme | Aufwand | Erwarteter Impact | Zeitrahmen |
|---|---|---|---|
| Bildformate (WebP/AVIF) | Gering | LCP hoch | 0–2 Wochen |
| Hero-Preload | Sehr gering | LCP mittel | 0–1 Woche |
| CDN-Konfiguration | Mittel (1–2 PT) | TTFB + LCP hoch | 1–3 Wochen |
| Critical CSS inline | Mittel (1–3 PT) | FCP mittel | 2–6 Wochen |
| Bundle-Splitting | Hoch (3 PT) | TBT + INP hoch | 1–3 Monate |
| SSR/SSG-Migration | Sehr hoch (10+ PT) | LCP + TTFB sehr hoch | 3+ Monate |
Mittelfristige Maßnahmen wie Critical CSS, Code-Splitting und Lazy Loading von Komponenten liefern solide Ergebnisse, erfordern aber Entwicklungszeit. Architektur-Refactors (SSR, SSG, Edge-Rendering) sind für Projekte mit dauerhaft hohem Traffic sinnvoll, aber kein Quick Win.
Schritt 6: Wie automatisierst du Tests und verhinderst Regressionen?
Einmalige Tests reichen nicht. Wer Regressionen verhindern will, braucht automatisierte Checks im Entwicklungszyklus.
Empfohlene Tools und Setups:
- Lighthouse CI: Läuft als GitHub Action oder in Jenkins/GitLab CI, vergleicht Scores gegen definierte Budgets und blockiert Merges bei Überschreitung
- WebPageTest API: Ermöglicht geplante Batch-Tests und Monitoring-Jobs mit Alert-Konfiguration für LCP/CLS/INP-Regressionen
- RUM-Alerts: Automatische Benachrichtigungen bei Perzentil-Verschiebungen im Produktivsystem
Performance-Budgets im CI/CD-Prozess:
- Budgets in
.lighthouserc.jsonoderbudget.jsondefinieren (z. B. LCP ≤ 2500 ms, TBT ≤ 200 ms) - Lighthouse CI als Pflicht-Check in Pull-Request-Pipelines einbinden
- Bei Budget-Überschreitung: Build schlägt fehl, Entwickler erhält sofortiges Feedback
- Nach jedem Deploy: automatischer WebPageTest-Job für Produktions-URLs
- RUM-Dashboard täglich prüfen, Alerts auf 75. Perzentil-Verschiebungen setzen
Das Canary-Rollout-Muster ist besonders wertvoll: Neue Deployments zunächst auf 1–5 % des Traffics ausrollen, RUM-Metriken für 30–60 Minuten beobachten, dann erst vollständig ausrollen. RUM-Slicing nach Gerät, Verbindung und Geografie stellt sicher, dass Regressionen auf mobilen Geräten nicht von Desktop-Werten überdeckt werden.
Bulk-Tests: Wie testest du hunderte URLs gleichzeitig?
Für große Websites mit hunderten oder tausenden Seiten braucht es einen strukturierten Ansatz.
Strategie für Bulk-Tests:
- Crawl mit Screaming Frog oder einem eigenen Crawler, gefiltert nach Template-Typ und Traffic-Schwelle
- Batch-Jobs über die PSI API oder WebPageTest API automatisiert ausführen
- Ergebnisse nach Template-Cluster aggregieren, nicht einzelne URLs isoliert betrachten
Technische Fallen:
- PSI API hat ein Rate-Limit von 25.000 Anfragen pro Tag (mit API-Key); Parallelisierung auf maximal 5–10 gleichzeitige Requests begrenzen
- Dynamische Parameter und Session-IDs aus URLs entfernen, sonst entstehen Duplikate
- Teststandort für alle Batch-Jobs einheitlich auf Frankfurt setzen, um Vergleichbarkeit zu gewährleisten
- Ergebnisse mit Zeitstempel und Tool-Version speichern
Beispiel-Datenstruktur für das Reporting:
| URL | Template | LCP, INP und CLS jeweils am 75. Perzentil messen |
|—|—|—|—|—|
| /produkt/beispiel | Produktdetail | — | 200 ms | — |
| /kategorie/beispiel | Kategorie | — | — | — |
| / | Startseite | 1,8 s | — | — |
Diese Struktur erlaubt es, Template-Typen mit systematisch schlechten Werten zu identifizieren und Fixes einmal zu entwickeln, die dann für alle Seiten dieses Templates wirken.
Wie testet und optimiert Werbeeinfach in der Praxis?
Bei Werbeeinfach läuft jeder WordPress- oder WooCommerce-Relaunch nach einem festen Ablauf. Vor dem Launch wird eine Baseline auf der Staging-Umgebung erhoben: PageSpeed Insights, WebPageTest mit Standort Frankfurt, drei Testläufe, Medianwert dokumentiert. Typische Ausgangswerte bei übernommenen Projekten liegen beim LCP auf Mobilgeräten oft über dem empfohlenen Schwellenwert.
Die Quick-Wins werden in der ersten Projektwoche umgesetzt: Bildformate konvertieren, Hero-Preload einrichten, Caching-Layer konfigurieren, CDN aktivieren. Danach folgt ein zweiter Testlauf, der den Fortschritt messbar macht. Für einen WooCommerce-Shop bedeutet das in der Praxis oft, den LCP von über 4 s auf unter 2,5 s zu senken, bevor der Shop live geht.
Nach dem Launch läuft das Monitoring automatisiert weiter. Lighthouse CI prüft bei jedem Deployment, ob Budgets eingehalten werden. RUM-Daten fließen über das web-vitals-Paket in ein Analytics-Dashboard. Bei Auffälligkeiten greift das Team direkt ein.
Werbeeinfach bietet dafür konkrete Services: PageSpeed-Optimierung für bestehende Websites, Wartungsverträge mit regelmäßigen Performance-Checks sowie individuelle Plugin-Entwicklung für maßgeschneiderte Telemetrie-Lösungen. Hosting-Migrationen zu performanteren Plattformen gehören ebenfalls zum Angebot, weil der Server oft der größte Hebel ist.
Profi-Tipp: Teste immer auf Staging und Produktion getrennt. Staging-Umgebungen haben oft andere Caching-Konfigurationen, andere CDN-Einstellungen und weniger Traffic. Ein grüner Lighthouse-Score auf Staging garantiert noch keinen grünen Score in Produktion.
Wichtige Erkenntnisse
Ein reproduzierbarer Workflow zum Testen der Website-Performance kombiniert Lab-Daten und Felddaten, priorisiert Maßnahmen nach Business-Impact und sichert Ergebnisse durch automatisiertes Monitoring im CI/CD-Prozess.
| Thema | Details |
|---|---|
| Core Web Vitals Zielwerte | LCP ≤ 2,5 s, INP ≤ 200 ms, CLS ≤ 0,1 — immer am 75. Perzentil messen |
| Lab und Feld kombinieren | PageSpeed Insights, WebPageTest und GTmetrix für Lab; CrUX und Performance API für Felddaten |
| Quick Wins zuerst | Bildformate, Hero-Preload, CDN und Caching liefern hohen Impact bei geringem Aufwand |
| CI/CD-Integration | Lighthouse CI und WebPageTest API als Pflicht-Gates im Buildprozess einrichten |
| Werbeeinfach | Bietet PageSpeed-Optimierung, Wartungsverträge und Hosting-Migration für WordPress und WooCommerce |
Werbeeinfach übernimmt deinen Performance-Workflow
Wer die Zeit oder das Team nicht hat, diesen Workflow selbst aufzubauen, bekommt bei Werbeeinfach alles aus einer Hand. Als WordPress-Agentur mit über 14 Jahren Erfahrung kennt das Team in Stuttgart die typischen Flaschenhälse bei WordPress und WooCommerce genau, von überlasteten Shared-Hosting-Umgebungen bis zu unkonfigurierten CDNs und aufgeblähten Plugin-Stacks.
Der konkrete Vorteil: Werbeeinfach liefert keine generischen Empfehlungen, sondern misst zuerst, priorisiert nach deinem Traffic und deinen Conversion-Zielen und setzt dann um. PageSpeed-Optimierung, Wartungsverträge mit regelmäßigen Performance-Checks und WooCommerce-Shops mit eingebautem Monitoring gehören zum Standardangebot. Schreib uns direkt an und lass uns gemeinsam eine Baseline für deine Website erstellen.
FAQ
Was sind die Zielwerte für Core Web Vitals?
Google empfiehlt LCP ≤ 2,5 s, INP ≤ 200 ms und CLS ≤ 0,1, gemessen am 75. Perzentil der Seitenaufrufe.
Warum reicht ein einzelner Lighthouse-Test nicht aus?
Ein einzelner Lauf kann durch Netzwerkschwankungen oder Caching-Effekte verfälscht sein. Mindestens 3–5 Testläufe und der Medianwert liefern eine belastbare Baseline.
Was ist der Unterschied zwischen Lab-Daten und Felddaten?
Lab-Daten (Lighthouse, WebPageTest) entstehen unter kontrollierten Bedingungen und sind reproduzierbar. Felddaten (CrUX, RUM) zeigen das echte Nutzererlebnis und fließen direkt in Googles Ranking ein.
Wie integriere ich Performance-Tests in den CI/CD-Prozess?
Lighthouse CI lässt sich als GitHub Action oder in GitLab CI einbinden. Performance-Budgets in .lighthouserc.json definieren und als Pflicht-Gate für Pull Requests konfigurieren.
Kann Werbeeinfach die Performance meiner bestehenden WordPress-Website verbessern?
Ja. Werbeeinfach bietet gezielte PageSpeed-Optimierung für bestehende WordPress- und WooCommerce-Projekte, inklusive Baseline-Messung, Quick-Win-Umsetzung und laufendem Monitoring.
Nützliche Quellen und weiterführende Tools
- PageSpeed Insights: Kostenloser Einstieg für Lab + CrUX-Felddaten; ideal für schnelle Checks einzelner URLs
- WebPageTest: Detaillierte Wasserfall-Analysen, Filmstrip, Multi-Location-Tests und API für Automatisierung
- Lighthouse (Chrome DevTools): Integriert in Chrome, läuft lokal oder als CLI; Grundlage für Lighthouse CI
- Performance API (MDN): Offizielle Referenz für NavigationTiming, ResourceTiming, UserTiming und PerformanceObserver
- CrUX API: Aggregierte Felddaten aus Chrome-Browsern, abrufbar per API für eigene Dashboards
- Lighthouse CI (GitHub): Setup-Anleitung für CI/CD-Integration mit Budget-Gates
- web-vitals npm-Paket: Einfachste Methode, Core Web Vitals im Browser zu erfassen und an ein Analytics-Endpoint zu senden
- MDN: Leistungsmessung: Übersicht aller Browser-APIs und Tools zur Leistungsmessung
