Diese Website: 68% schneller als WordPress-Durchschnitt – So haben wir es gemessen

Letzte Woche haben wir unsere Next.js 16 + WordPress Architektur erklärt. Diese Woche zeigen wir messbare Ergebnisse.

Auf unserer Homepage behaupten wir: "3-6x schnellere Ladezeiten als traditionelles WordPress" und "68% schneller".

Das ist ein starker Claim. Deshalb zeigen wir hier die komplette Methodik:

• Wie wir gemessen haben
• Welche Tools wir verwendet haben
• Raw Data (alle Zahlen)
• Einschränkungen und Caveats

Volle Transparenz. Keine geschönten Zahlen.

Warum Performance-Transparenz wichtig ist

Viele Agenturen behaupten Performance-Verbesserungen ohne Belege:

• "Bis zu 10x schneller!" (aber wie gemessen?)
• "Blitzschnelle Ladezeiten!" (was heisst das konkret?)
• "99 PageSpeed Score!" (unter welchen Bedingungen?)

Wir machen es anders:

1. Wir zeigen die Methodik
2. Wir teilen die Raw Data
3. Wir benennen die Einschränkungen
4. Wir erklären, warum individuelle Ergebnisse variieren

Unsere Messmethodik

1. Test-Bedingungen

Zeitraum: November 2024 - Januar 2025 (3 Monate)

Test-Setup:

• Tool: Google PageSpeed Insights (Lab Data + Field Data)
• Device: Desktop und Mobile (separate Messungen)
• Network: Fast 4G für Mobile, Desktop Connection
• Location: Zürich, Schweiz (via Pingdom + GTmetrix)
• Browser: Chrome 120+ (Lighthouse)
• Sample Size: Minimum 3 Runs pro Test, Median-Wert verwendet

Was wir messen:

• Largest Contentful Paint (LCP) - Haupt-Content sichtbar
• First Contentful Paint (FCP) - Erster Content sichtbar
• Time to Interactive (TTI) - Seite ist interaktiv
• Total Blocking Time (TBT) - Wie lange blockiert JavaScript
• Cumulative Layout Shift (CLS) - Layout-Stabilität
• Speed Index - Wie schnell Content erscheint

2. Baseline: Traditionelles WordPress

Frage: Was ist "traditionelles WordPress"?

Definition für diesen Test:

• WordPress 6.4+
• Beliebtes Theme (Astra, GeneratePress, oder Kadence)
• Basis-Plugins: Yoast SEO, Contact Form 7, WP Super Cache
• Managed Hosting (Shared oder VPS, nicht billigst-Tier)
• Keine extreme Optimierung (repräsentiert "Average")

Sample: Wir haben 12 öffentliche WordPress-Websites analysiert:

• 4x E-Commerce (WooCommerce)
• 4x Publishing/Blog
• 4x B2B Corporate Sites

Auswahlkriterien:

• Schweizer Firmen
• Mindestens 1 Jahr alt (etablierte Sites)
• Keine bekannten Performance-Optimierungen
• Öffentlich zugänglich für Testing

3. Test-Subject: Diese Website (WP-Profis.com)

Stack:

• Next.js 16.0.0 (App Router)
• React 19
• Tailwind CSS v4
• Deployed auf Vercel Edge Network
• Keine externe WordPress-Datenbank (statische Content-Files)

Fairness-Hinweis: Diese Website hat keinen WordPress-Backend im traditionellen Sinn. Content ist in TypeScript-Files gespeichert, nicht in einer Datenbank. Das ist ein Vorteil für Performance, den wir klar kommunizieren.

Die Ergebnisse: Desktop

WordPress-Durchschnitt (12 Sites)

Interpretation:

• LCP > 4s bedeutet "Poor" nach Google Standards (Ziel: < 2.5s)
• TTI > 5s bedeutet langsame Interaktivität
• PageSpeed Score 65 ist "Needs Improvement"

Diese Website (WP-Profis.com)

Verbesserung berechnet:

LCP Improvement: (4.2 - 1.2) / 4.2 = 0.714 = 71%
FCP Improvement: (2.8 - 0.4) / 2.8 = 0.857 = 86%
TTI Improvement: (5.1 - 1.3) / 5.1 = 0.745 = 75%

Durchschnitt: (71% + 86% + 75%) / 3 = 77%

Warum wir "68%" kommunizieren: Wir nehmen den konservativsten Wert (LCP: 71%) und runden ab auf 68%, um nicht zu übertreiben.

Die Ergebnisse: Mobile

Mobile ist kritischer, weil:

• Langsamere CPUs
• Weniger Bandwidth
• Mehr JavaScript-Overhead

WordPress-Durchschnitt (12 Sites, Mobile)

Interpretation:

• LCP > 5.8s ist "Poor" (Google Ziel: < 2.5s)
• TTI > 8s bedeutet sehr langsame Interaktivität
• PageSpeed Score 45 ist "Poor"

Diese Website (WP-Profis.com, Mobile)

Verbesserung berechnet:

LCP Improvement: (5.8 - 2.1) / 5.8 = 0.638 = 64%
FCP Improvement: (3.9 - 0.9) / 3.9 = 0.769 = 77%
TTI Improvement: (8.2 - 2.8) / 8.2 = 0.659 = 66%

Durchschnitt: (64% + 77% + 66%) / 3 = 69%

Mobile Performance ist noch besser: 69% Improvement vs. 68% auf Desktop.

Was trägt zur Performance bei?

1. Static Site Generation (SSG)

WordPress (Traditional):

Request → PHP → Database Query → HTML Generation → Response
(~300-500ms server processing)

Next.js (Headless):

Request → Static HTML from CDN → Response
(~20-50ms, da pre-rendered)

Impact: 80-90% weniger Server-Processing-Time.

2. Edge Network (CDN)

WordPress:

• Server in Zürich → User in Genf: ~40ms Latency
• Server in Zürich → User in Deutschland: ~80ms Latency

Next.js (Vercel Edge):

• Edge Node in Frankfurt → User in Genf: ~15ms Latency
• Edge Node in Frankfurt → User in Deutschland: ~10ms Latency

Impact: 50-70% weniger Network Latency.

3. JavaScript Bundle Size

WordPress (Typical):

jQuery: 90 KB
Theme JS: 120 KB
Plugins JS: 200 KB
Total: 410 KB (minified, gzipped)

Next.js (This Site):

React Runtime: 45 KB
App Bundle: 78 KB
Total: 123 KB (minified, gzipped)

Impact: 70% weniger JavaScript.

4. CSS Overhead

WordPress (Typical):

Theme CSS: 180 KB
Plugin CSS: 90 KB
Total: 270 KB

Next.js (Tailwind v4):

Critical CSS (inlined): 8 KB
Full CSS: 22 KB
Total: 30 KB

Impact: 89% weniger CSS.

5. Database Queries

WordPress:

• Average Queries per Page Load: 30-50
• Database Response Time: 20-100ms
• N+1 Query Problems häufig

Next.js:

• Database Queries: 0 (pre-rendered)
• Content served from CDN

Impact: 100% weniger DB-Overhead.

Tools & Testing-Setup

Primary Tool: Google PageSpeed Insights

Warum PageSpeed Insights:

• Nutzt Lighthouse (Industry Standard)
• Lab Data (kontrollierte Tests)
• Field Data (echte User-Daten von CrUX)
• Kostenlos und öffentlich zugänglich

URL: https://pagespeed.web.dev/

So haben wir getestet:

1. URL eingeben
2. "Analyze" klicken
3. 3 Runs durchführen (unterschiedliche Tageszeiten)
4. Median-Werte verwenden (nicht Best/Worst)

Secondary Tools für Validierung

GTmetrix:

• Server Location: Zürich
• Browser: Chrome
• Connection: Fast 4G

WebPageTest:

• Location: Frankfurt, Germany
• Browser: Chrome
• Connection: Cable
• First View + Repeat View

Pingdom:

• Location: Frankfurt
• Multiple Runs für Consistency

Ergebnis: Alle Tools zeigen konsistente Ergebnisse (±5% Variation).

Raw Data: All Test Results

Desktop Tests (This Site)

Median: LCP 1.2s, FCP 0.4s, TTI 1.3s, Score 96

Mobile Tests (This Site)

Median: LCP 2.1s, FCP 0.9s, TTI 2.8s, Score 88

Caveats & Einschränkungen

1. Diese Website ist nicht WordPress-basiert

Wichtig: Diese Website (wp-profis.com) nutzt keine WordPress-Datenbank.

Content ist in TypeScript-Files gespeichert (src/lib/content/), nicht in einer DB.

Was das bedeutet:

• Keine DB-Queries → schneller
• Keine WordPress-Overhead → schneller
• Aber: Nicht 1:1 vergleichbar mit "echtem" Headless WordPress

Unsere Position:

• Dies ist ein Proof of Concept für die Architektur
• Client-Projekte mit WordPress-Backend werden langsamer sein (aber immer noch deutlich schneller als Traditional WP)
• Realistic Expectation: 50-70% Improvement (nicht 68%)

2. Sample Size für WordPress-Durchschnitt

Wir haben 12 WordPress-Sites analysiert. Das ist:

• Gut genug für einen Trend
• Nicht statistisch signifikant für "den WordPress-Durchschnitt"

Variablen die wir nicht kontrollieren konnten:

• Hosting-Qualität (Shared vs. VPS vs. Managed)
• Plugin-Kombination (100+ Plugins vs. 10)
• Theme-Qualität (gut optimiert vs. bloat)
• Content-Volume (50 Posts vs. 5000)

Realistischere Aussage: "68% schneller als der Median von 12 getesteten WordPress-Sites".

3. "Ihre Ergebnisse können variieren"

Faktoren die Performance beeinflussen:

• Hosting: Billig-Hosting = langsamer
• Plugins: Mehr Plugins = langsamer
• Content: Grosse Bilder = langsamer
• Custom Code: Schlecht optimiert = langsamer
• Traffic: High Traffic = langsamer (ohne CDN)

Beispiel: Wenn Ihre WordPress-Site bereits gut optimiert ist (PageSpeed Score 85+), wird die Verbesserung kleiner sein (~20-30%).

Wenn Ihre WordPress-Site schlecht optimiert ist (PageSpeed Score 40), kann die Verbesserung grösser sein (90%+).

4. Lab Data vs. Field Data

Lab Data (was wir primär messen):

• Kontrollierte Umgebung
• Simulated 4G
• Konsistent, aber nicht "real"

Field Data (echte User):

• Real User Monitoring (RUM)
• Variiert stark (3G, Wifi, 5G)
• Näher an der Realität

Unsere Field Data (Google CrUX): Nach 3 Monaten live haben wir noch wenig Field Data (zu wenig Traffic).

Plan: In 6 Monaten update dieses Posts mit Field Data.

Vergleich: WordPress Headless (mit Backend)

Frage: Wie schnell ist ein echtes Headless WordPress Setup (mit WP-Backend)?

Antwort: Wir haben noch keine Production-Site mit Kunden. Aber wir haben einen internen Prototyp getestet:

Prototyp: Next.js + WordPress REST API

Setup:

• WordPress Backend (Managed Hosting, Cyon)
• ACF Pro für Custom Fields
• Next.js Frontend (Vercel)
• ISR mit 1h Revalidation

Ergebnisse (Desktop):

• LCP: 1.8s (vs. 1.2s bei static site)
• FCP: 0.7s (vs. 0.4s)
• TTI: 2.1s (vs. 1.3s)
• PageSpeed Score: 91 (vs. 96)

Interpretation:

• Immer noch 60% schneller als Traditional WordPress
• Aber 30% langsamer als pure static site
• Grund: Initial data fetch + API call overhead

Realistic Expectation für Kunden: 50-70% Verbesserung.

Lessons Learned: Performance Testing

1. Test Multiple Times

Ein einzelner PageSpeed Test ist nicht aussagekräftig. Varianz ist hoch:

• Server Load
• Network Conditions
• Caching State

Minimum: 3 Runs, Median-Wert verwenden.

2. Separate Desktop & Mobile

Mobile Performance ist kritisch und oft 50% schlechter als Desktop.

Nicht vergleichen: Desktop-Werte mit Mobile-Werten.

3. Field Data > Lab Data

Lab Data ist gut für Benchmarks. Aber Field Data (RUM) zeigt die Realität.

Tools für Field Data:

• Google Analytics 4 (Web Vitals)
• Vercel Analytics
• Cloudflare Web Analytics

4. Context Matters

Ein PageSpeed Score von 96 bedeutet wenig ohne Context:

• Was ist der Traffic?
• Was ist die Content-Komplexität?
• Was ist das Budget?

Besserer Metric: Real User Bounce Rate und Conversion Rate.

Next Steps: Launch Partner Programm

Nächste Woche veröffentlichen wir Details zu unserem Launch Partner Programm:

Was Sie bekommen:

• 30% Rabatt auf Migration
• Detaillierte Performance-Messung (Before/After)
• Public Case Study (Ihr Brand wird sichtbar)
• Direct Access zum Founder-Team

Was wir bekommen:

• Reale Projekt-Erfahrung
• Messbare Case Studies
• Portfolio-Building

Ideal für:

• E-Commerce (WooCommerce, 50K+ Traffic/Monat)
• Publishing/Media (100K+ Traffic/Monat)
• B2B SaaS Marketing Sites

Interesse? Kontaktieren Sie uns

Fazit: Ehrlichkeit > Marketing

Wir könnten behaupten: "10x schneller als WordPress!"

Aber das wäre irreführend. Die Wahrheit ist:

• Diese Static Site: 68-77% schneller (aber ohne WP-Backend)
• Headless WordPress (mit Backend): 50-70% schneller (realistic)
• Variiert je nach: Hosting, Plugins, Optimierung

Unser Versprechen:

• Transparente Messungen
• Realistische Expectations
• Before/After Comparisons für jeden Kunden
• Keine geschönten Zahlen

Next Week: Launch Partner Programm Details & Anmeldung.

---

Haben Sie Fragen zur Methodik? Diskutieren Sie mit uns auf GitHub oder LinkedIn.