WordPress betreibt rund 42 % aller Websites weltweit (W3Techs, Mai 2026) und kommt unter den Sites mit bekanntem CMS auf einen Anteil von 59,6 %. Aber wie schnell sind diese Sites tatsächlich? Die ehrliche Antwort: durchwachsen. Wenn Sie die Performance Ihrer eigenen Site einordnen wollen, liefert der kostenlose Website-Check in unter einer Minute eine erste Orientierung — Core Web Vitals, SEO und Sicherheit auf einer Seite.
Die folgende Analyse stützt sich auf das Web Almanac 2025 des HTTP Archive — eine der wenigen öffentlich zugänglichen Quellen, die Performance-Daten plattformübergreifend und methodisch sauber aggregiert. Keine Anekdoten, keine Marketing-Folien. Einfach: Was zeigen die Daten, und was bedeutet das für ein WordPress-Projekt 2026?
Wir haben uns für diese Quelle entschieden, weil sie zwei Eigenschaften vereint, die im sonst lauten Performance-Diskurs selten zusammenkommen. Erstens: Die Daten beruhen auf realen Nutzer-Sessions, nicht auf Lab-Tests im Idealzustand. Zweitens: Sie sind plattformweit erhoben, nicht von einem Anbieter, der seine eigene Plattform vermarkten will. Wer 2026 eine fundierte Aussage zu WordPress-Performance treffen will, kommt an dieser Datenquelle nicht vorbei.
Wie schneidet WordPress bei Core Web Vitals gegen andere CMS ab?
WordPress besteht 2026 nur 45 % der Core Web Vitals auf Mobilgeräten — gegenüber 85 % bei Duda, 79 % bei TYPO3 und 74 % bei Wix (Web Almanac 2025). Damit liegt WordPress drei Prozentpunkte unter dem mobilen Web-Durchschnitt von 48 %, holt mit +4 Prozentpunkten gegenüber dem Vorjahr aber auf.
Das HTTP Archive misst monatlich Millionen von Websites und veröffentlicht jährlich den Web Almanac. Das CMS-Kapitel gruppiert die Daten nach Plattform und erlaubt damit den direkten Vergleich. Grundlage für die Core-Web-Vitals-Werte sind Felddaten aus dem Chrome User Experience Report — also tatsächliche Nutzer-Erfahrungen, keine synthetischen Lab-Tests.
Ein Wert gilt als "good", wenn alle drei Core-Web-Vitals-Metriken (LCP, CLS, INP) im grünen Bereich liegen. Genau dieser kombinierte Pass ist der relevante Vergleichswert — nicht die Einzelmetrik. Eine Einschränkung zur Lesart der Tabelle: Site-Builder wie Duda oder Wix selektieren strukturell einfachere, stärker standardisierte Sites, während unter "WordPress" vom Ein-Personen-Blog bis zum überladenen Enterprise-Shop alles zusammenfällt. Der Vergleich misst also auch unterschiedliche Site-Populationen, nicht nur unterschiedliche Technik.
| CMS-Plattform | Mobile CWV "good" Pass-Rate |
|---|---|
| Duda | 85 % |
| TYPO3 | 79 % |
| Wix | 74 % |
| Squarespace | ~70 % |
| Joomla | ~52 % |
| Drupal | ~49 % |
| WordPress | 45 % (+4 PP YoY) |
| Web-Durchschnitt (mobil) | 48 % |
Quelle: Web Almanac 2025, CMS-Kapitel und Performance-Kapitel. WordPress erreicht 45 % — 40 Prozentpunkte unter Duda (85 %) und 3 Punkte unter dem Web-Durchschnitt (48 %). Mit +4 Prozentpunkten gegenüber dem Vorjahr holt WordPress zwar auf, aber 45 % bedeutet eben auch: in mehr als jedem zweiten Fall fällt eine WordPress-Site bei mindestens einer der drei Metriken durch. Auf Desktop liegt der Web-Durchschnitt mit 56 % höher — die mobilen Werte sind der härtere Massstab, weil dort Server-Antwortzeit und Asset-Grösse am stärksten ins Gewicht fallen.
Die Plattformen oben in der Tabelle haben ein gemeinsames Muster: Sie sind Site-Builder, die das Frontend stark standardisieren und aus eigenen, gut optimierten Edge-Infrastrukturen ausliefern. Duda und Wix kontrollieren End-to-End — von der Datenhaltung bis zum Asset-Delivery. WordPress dagegen ist ein offenes Ökosystem mit zigtausend Themes und Plugins, in dem jede Site-Entscheidung Performance-Folgen hat. Diese Offenheit ist ein Vorteil für Flexibilität — und gleichzeitig der Grund, warum die durchschnittliche WordPress-Site langsamer ist als die durchschnittliche Duda-Site. Es ist kein technisches Versäumnis, sondern eine direkte Folge der Architektur-Philosophie.
LCP: WordPress' grösste Schwachstelle
Largest Contentful Paint (LCP) ist das schwächste Glied im WordPress-Stack. Während die Plattform bei den anderen Metriken anschlussfähig ist, klafft bei LCP eine deutliche Lücke zu den Konkurrenten. Die mobilen "good"-Raten aus dem Web Almanac 2025:
- WordPress: 53 % LCP "good" (mobil)
- Duda: 94 %
- TYPO3: 89 %
- Wix: 81 %
Der Hauptgrund ist strukturell: WordPress' grösste Schwachstelle ist Time-to-First-Byte (TTFB) — die Server-Antwortzeit, die jedes nachgelagerte Metric verlangsamt. Googles Performance-Team formuliert es bei web.dev zu TTFB unmissverständlich: Bei Navigations-Anfragen "geht TTFB jeder anderen relevanten Lade-Metrik voraus". Als "good" gilt ein TTFB von 0,8 Sekunden oder weniger; über 1,8 Sekunden gilt er als schlecht. Je länger der Server für die erste Byte-Antwort braucht, desto weniger Zeit bleibt fürs Rendern des Hero-Elements, bevor die LCP-Schwelle von 2,5 Sekunden reisst. Bei klassischem WordPress entsteht diese Verzögerung durch das Zusammenspiel aus Plugin-Stack, Theme-Logik, Datenbankabfragen pro Request und unzureichend konfigurierten Cache-Schichten.
Das Bild verschärft sich, wenn man die Architektur betrachtet: Plattformen wie Duda oder Wix liefern aus Edge-CDNs aus, mit weitgehend statisch vorgerenderten Seiten. WordPress in seiner klassischen Form rendert pro Request — das ist flexibel, aber der Performance-Preis ist hoch.
INP, CLS: nahezu par mit anderen Plattformen
Bei den anderen beiden Metriken sieht das Bild deutlich freundlicher aus. WordPress erreicht mobil rund 84 % "good" bei Cumulative Layout Shift (CLS) und etwa 86 % "good" bei Interaction to Next Paint (INP) — beides nahe am Plattform-Durchschnitt. Diese Metriken werden stärker durch Frontend-Disziplin geprägt: saubere Bildgrössen mit explizitem width/height, vermiedene Layout-Sprünge bei nachgeladenen Inhalten und kontrollierte JavaScript-Tasks. Hier hat WordPress in den letzten Jahren methodisch zugelegt — der Block-Editor erzwingt explizite Bildmasse, moderne Themes minimieren Layout-Sprünge, und INP-Optimierungen wurden im Core nachgezogen.
Die Implikation ist wichtig: Das Problem von WordPress 2026 ist nicht "alles ist schlecht". Das Problem ist konzentriert auf TTFB und LCP — also genau auf die Schichten, die am stärksten von der Server-Architektur abhängen. Genau hier setzt der direkte Architektur-Vergleich zwischen klassischem und Headless WordPress an, weil sich an genau diesen Schichten der Unterschied entscheidet.
Daraus folgt eine pragmatische Trennlinie für Performance-Investitionen: CLS- und INP-Probleme sind mit Frontend-Disziplin und Theme-Auswahl lösbar — ohne die Architektur anzufassen. Den LCP-Spalt zu Duda und TYPO3 schliesst dagegen kein Theme-Wechsel, sondern nur eine Veränderung am Auslieferungs-Modell.
Wo Headless WordPress die Lücke schliesst
Headless WordPress trennt das Frontend strikt vom Backend. WordPress liefert Inhalte über eine API zur Build- oder Revalidation-Zeit; das Frontend wird als statisches HTML oder per Edge-Rendering ausgeliefert. Das Ergebnis: TTFB wird strukturell aus dem Pfad genommen, weil jeder Seitenaufruf nicht mehr durch den WordPress-Stack laufen muss.
In der Praxis liegen LCP- und TTFB-Werte strukturell tiefer, weil die langsamsten Schichten des klassischen Stacks aus der Auslieferung herausgenommen werden. Konkrete Plattform-Daten zu Headless-WordPress veröffentlicht das Web Almanac 2025 nicht — Headless-Setups werden anhand des Backends gezählt, nicht des Frontends. Belastbar ist aber der Mechanismus: Wird die kritische Seite statisch aus einem Edge-CDN ausgeliefert, fällt der TTFB unter die 0,8-s-Schwelle, die web.dev als "good" definiert — und genau dieser Wert ist laut Google die Voraussetzung dafür, dass ein LCP unter 2,5 Sekunden überhaupt erreichbar bleibt. In unseren eigenen Schweizer Projekten 2024–2026 hat dieser Schritt den mobilen LCP regelmässig von über drei Sekunden auf deutlich unter zwei Sekunden gedrückt. Das ist kein Marketing — das ist die direkte Konsequenz aus der Architektur-Trennung.
Das Problem von WordPress 2026 ist nicht "alles ist schlecht". Das Problem ist konzentriert auf TTFB und LCP — und genau dort setzt Headless an.
Wichtige Einschränkung: Nicht jede Headless-Architektur ist automatisch schnell. Reine Client-Side-SPAs ohne Server-Side-Rendering können bei LCP sogar schlechter abschneiden als klassisches WordPress, weil das Frontend erst noch JavaScript laden, ausführen und Daten holen muss, bevor überhaupt etwas Sichtbares entsteht. Die Architektur-Wahl entscheidet — und sie sollte nüchtern auf Basis der Anforderungen getroffen werden, nicht auf Basis von Plattform-Loyalität. Eine vertiefte Einordnung dazu liefert die Seite Headless WordPress als Pillar-Übersicht.
Drei Hebel sind in der Praxis verantwortlich dafür, dass Headless-Setups die LCP-Lücke schliessen. Erstens: Die kritischen Seiten werden zur Build-Zeit als statisches HTML gerendert und global über ein CDN ausgeliefert — der erste Byte kommt aus einem Edge-Knoten in unmittelbarer Nähe des Besuchers. Zweitens: Das HTML enthält bereits den vollständigen Hero-Inhalt, sodass der grösste sichtbare Block direkt nach dem ersten Render-Pass steht. Drittens: WordPress wird nur noch zur Inhaltsänderung angefragt, nicht bei jedem Seitenaufruf — der gesamte Plugin- und Datenbank-Overhead verschwindet aus dem kritischen Pfad.
Welche Hebel helfen ohne Architektur-Wechsel?
Nicht jede WordPress-Site braucht Headless, um aus dem roten Bereich zu kommen. Vier Massnahmen senken TTFB und LCP messbar, ohne die Architektur anzufassen — sinnvoll für Sites unter rund zehn aktiven Plugins ohne akuten Wachstumsdruck. Sie verschieben den Engpass, lösen ihn bei dynamischem Rendering aber nicht vollständig.
| Hebel | Wirkt auf | Aufwand | Grenze |
|---|---|---|---|
| Page-Cache / Full-Page-Caching (Server oder CDN) | TTFB, LCP | gering | greift nicht bei eingeloggten oder personalisierten Ansichten |
Hero-Bild als WebP/AVIF mit fetchpriority="high" | LCP | gering | löst kein TTFB-Problem |
| Plugin-Audit: deaktivieren statt anhäufen | TTFB, INP | mittel | jedes Plugin bleibt ein Datenbank-Request pro Aufruf |
| Schnelleres Hosting (PHP-Worker, Objekt-Cache) | TTFB | mittel | dynamisches Rendering bleibt im Pfad |
Die ehrliche Trennlinie: Ein gut konfigurierter Page-Cache bringt viele WordPress-Sites mobil über die 0,8-s-TTFB-Schwelle — solange die Seite statisch genug ist, um cachebar zu bleiben. Sobald Personalisierung, häufige Inhaltsänderungen oder mehrere Sprachen ins Spiel kommen, sinkt die Cache-Trefferquote, und der Architektur-Wechsel wird zur strukturell saubereren Antwort.
Was Sie heute messen können
Bevor Sie über Architektur-Wechsel nachdenken, lohnt sich ein nüchterner Blick auf die eigenen Werte. Drei Tools genügen für eine belastbare Standortbestimmung:
- Google PageSpeed Insights — kombiniert Lab-Daten (Lighthouse) mit Felddaten aus dem Chrome User Experience Report. Die Felddaten sind der relevante Vergleichswert, weil sie reale Nutzer-Erfahrungen abbilden, gemittelt über die letzten 28 Tage.
- CrUX Dashboard — zeigt historische Trends über mehrere Monate. Sinnvoll, um Verbesserungen oder Verschlechterungen über Zeit zu erkennen, und um saisonale Effekte einzuordnen.
- Lighthouse-Lauf — liefert einen Snapshot inklusive konkreter Empfehlungen pro Metrik. Achtung: Lab-Werte liegen oft günstiger als Felddaten, weil reale Nutzer mit schwächeren Geräten und schwankenden Netzwerken unterwegs sind.
Eine erste Einordnung in unter einer Minute liefert auch unser kostenloser Website-Check als Performance-Übersicht — Performance, SEO, Sicherheit und Barrierefreiheit auf einer Seite, ohne Datenfreigabe. Wenn Sie die eigene Site selbst messen, lohnt der Fokus auf vier Werte:
- LCP — Ladezeit des grössten sichtbaren Elements (Ziel: unter 2,5 s)
- CLS — Layout-Verschiebungen während des Ladens (Ziel: unter 0,1)
- INP — Reaktionszeit auf Nutzer-Interaktion (Ziel: unter 200 ms)
- TTFB — Server-Antwortzeit, der Hebel hinter LCP (Ziel: unter 600 ms)
Nächster Schritt
Wenn Sie wissen wollen, wo Ihre Site bei Core Web Vitals aktuell steht, prüfen Sie LCP, CLS und INP für Ihre Domain in unter einer Minute. Daraus ergibt sich, welche Hebel sich in welcher Reihenfolge lohnen — vom Theme-Wechsel über Caching bis zum Architektur-Wechsel. Eine vertiefende Einordnung, wann sich der Architektur-Wechsel rechnet, liefert der Beitrag zu den konkreten Vorteilen von Headless WordPress.
Wenn Sie die nächsten Schritte direkt besprechen wollen, vereinbaren wir gerne ein Erstgespräch — 15 Minuten, kostenlos. In dieser Zeit klären wir Ausgangslage, Performance-Ziele und das passende Vorgehen — und Sie wissen am Ende, ob ein Audit, eine Optimierung des bestehenden Setups oder ein Wechsel auf Headless für Ihre Site die ehrlichere Antwort ist.