Performance 8 Min.
Core Web Vitals 2026: So verbessern Sie Ihren PageSpeed
Konkrete Maßnahmen für bessere LCP, INP und CLS-Werte — mit Vorher-Nachher-Messdaten aus echten DACH-Projekten.
"Wir wollen Headless" — dieser Satz begegnet uns in Briefings immer häufiger. Manchmal ist er die richtige Anforderung. Manchmal ist er Technologie-Enthusiasmus, der am Ende mehr kostet und weniger Nutzen bringt als erwartet. Dieser Artikel gibt Ihnen eine ehrliche Entscheidungsgrundlage — keine Technologie-Evangelisierung, sondern konkrete Kriterien.
Kurzantwort · Position 0
WordPress ist die bessere Wahl wenn: Standard-Business-Website oder Blog, WooCommerce-E-Commerce mit gängigen Anforderungen, nicht-technische Redaktion soll Inhalte pflegen, Budget unter 15.000 €, schnelle Umsetzung Priorität.
Headless CMS (Contentful, Sanity, Strapi) ist besser wenn: Multi-Channel-Publishing (Web + App + Kiosk), PageSpeed 95+ als harte Anforderung, React/Next.js-Entwicklerteam vorhanden, komplexe API-Integrationen nötig, Traffic über 100.000 Sessions/Monat.
Die meisten DACH-Mittelständler kommen mit WordPress gut aus — Headless lohnt sich erst ab spezifischen Anforderungen.
Was ist Headless CMS — und was ist es nicht?
Bevor wir vergleichen, klären wir die Begriffe.
Traditionelles CMS (WordPress-Modell): Backend und Frontend sind eng gekoppelt. WordPress verwaltet Inhalte in einer MySQL-Datenbank, generiert HTML-Seiten serverseitig mit PHP und liefert sie direkt an den Browser. Themes und Plugins bestimmen Aussehen und Funktionen. Vorteil: niedrige Einstiegskosten, einfache Pflege. Nachteil: Frontend an PHP/WordPress gebunden, Plugin-Overhead belastet Performance.
Headless CMS: Das CMS ist "kopflos" — es hat kein eigenes Frontend. Es verwaltet ausschließlich Inhalte und stellt sie über eine REST- oder GraphQL-API bereit. Das Frontend (React, Next.js, Astro, Nuxt.js) holt Inhalte über diese API und rendert sie eigenständig. Das CMS kennt nicht, wie Inhalte dargestellt werden — das entscheidet das Frontend-Framework.
Die dritte Option: WordPress als Headless CMS. WordPress kann auch "headless" betrieben werden — als reines Content-Backend mit REST-API, während Next.js das Frontend übernimmt. Das kombiniert das vertraute WordPress-Interface mit den Performance-Vorteilen eines modernen Frontends. Ein oft unterschätzter Mittelweg.
Warum WordPress so weit verbreitet ist — und warum das stimmt
WordPress betreibt laut aktuellen Daten über 43% aller Websites weltweit. Das ist kein Zufall und kein Marketingmythos.
Content-Pflege ohne Technik-Kenntnisse: Der Gutenberg-Editor ist seit Jahren für nicht-technische Redakteure ausgelegt. Seiten hinzufügen, Bilder uploaden, Blog-Artikel schreiben — das kann jeder ohne Entwickler-Eingriff.
Schnelle Umsetzung: Mit einem soliden Theme-Fundament und gezielten Plugins ist eine professionelle Business-Website in 3–4 Wochen produktionsreif — ohne jede Zeile Custom-Code.
WooCommerce-E-Commerce: Für Standard-Webshops (bis ca. 10.000 Produkte, ohne komplexe B2B-Logik) ist WooCommerce produktionsbewährt, gut dokumentiert und mit einem starken Dienstleister-Ökosystem ausgestattet.
Plugin-Ökosystem: Über 60.000 Plugins lösen fast jede Standardanforderung — Newsletter-Integration, Buchungssysteme, Mitgliederbereiche, Mehrsprachigkeit, SEO-Werkzeuge.
Das eigentliche Problem mit WordPress
Nicht WordPress selbst ist das Problem — sondern der Missbrauch von Pagebuildern. Elementor, Divi, WPBakery generieren aufgeblähten HTML-Code, der Core Web Vitals systematisch verschlechtert. Ein WordPress-Projekt das nach diesem Muster gebaut wird, erreicht selten PageSpeed-Werte über 70 auf Mobile. Hawd Design nutzt WordPress ohne Pagebuilder — Custom-Theme mit sauberem Code, Gutenberg für die Inhaltsstruktur. Das Ergebnis: PageSpeed-Werte über 90 auf Mobile.
Wann WordPress an seine Grenzen stößt
Es gibt Szenarien, in denen WordPress strukturell nicht die beste Wahl ist. Ehrlichkeit hilft mehr als Vendor-Loyalität.
Szenario 1: Multi-Channel-Publishing. Wenn Ihre Inhalte auf einer Website, einer mobilen App, einem Kiosk-Display und in einem gedruckten Katalog erscheinen sollen — brauchen Sie eine saubere Inhaltstrennung vom Präsentationslayer. WordPress kann das über seine REST-API, aber es ist nicht dafür gebaut. Headless CMS sind es.
Szenario 2: Extreme Performance-Anforderungen. E-Commerce-Shops, bei denen jede Millisekunde Ladezeit messbar in Conversion-Rate übersetzt wird, profitieren von Static Site Generation oder Server-Side Rendering mit Next.js. Korrekt implementiert, erreichen diese Setups PageSpeed-Werte von 95–100 auf Mobile strukturell leichter als WordPress.
Szenario 3: Komplexe API-Integrationen. Wenn Ihre Website Echtzeit-Daten aus einem ERP-System, einem Product-Information-Management (PIM) oder einem CRM beziehen muss — ist eine API-first Architektur sauberer als WordPress-Plugins, die diese Verbindungen mit fragilen PHP-Code-Bridges aufbauen.
Szenario 4: Großes Redaktionsteam mit strukturierten Inhalten. Wenn 20+ Redakteure nach klaren Inhaltsstrukturen und Validierungsregeln arbeiten müssen — bieten Content-Modelling-Werkzeuge in Contentful oder Sanity mehr Kontrolle als WordPress-Custom-Fields-Plugins.
Die Headless CMS Landschaft: Contentful, Sanity und Strapi
Nicht alle Headless CMS sind gleich. Hier die drei relevantesten für DACH-Mittelständler:
Contentful
Enterprise-Standard
Stärken: ausgereifte API, exzellente Dokumentation, starkes Entwickler-Ökosystem, sehr gute Lokalisierungsunterstützung (wichtig für DE/FR/IT-Mehrsprachigkeit in der Schweiz).
Schwächen: teuer ab dem Professional-Tier (300–900 $/Monat), komplexes Preismodell, Vendor-Lock-in.
Ideal für: Große Mittelständler, Konzerne, Multi-Site-Setups mit komplexen Freigabeprozessen.
Sanity
Entwickler-Favorit
Stärken: flexibles Content-Modelling, portabler Text (GROQ-Abfragesprache), großzügiges Free-Tier für kleinere Projekte, Real-time-Kollaboration.
Schwächen: steilere Lernkurve für Nicht-Entwickler, weniger "out of the box" als Contentful.
Ideal für: Entwickler-getriebene Projekte, kreative Agenturen, komplexe Content-Strukturen.
Strapi
Open Source
Stärken: Self-hosted (volle Datenkontrolle), kein SaaS-Vendor-Lock-in, flexibel erweiterbar, kostenlos bei Self-Hosting.
Schwächen: Wartungsaufwand (Updates, Sicherheitspatches), weniger ausgereiftes UI als Contentful/Sanity.
Ideal für: Teams mit eigenem DevOps-Kapazität, Projekte mit Datensouveränitäts-Anforderungen.
Performance im direkten Vergleich: Reale Messdaten
Das ist die Frage, die am häufigsten kommt — und für die es keine pauschale Antwort gibt. Es kommt auf die Implementierung an.
| Setup | PageSpeed Mobile | LCP | Ursache |
|---|---|---|---|
| WordPress + Pagebuilder typisch bei Budget-Agenturen |
35–55 | 4–8 Sekunden | Unkomprimierter JS/CSS-Overhead aus Elementor/Divi |
| WordPress ohne Pagebuilder Hawd Design Standard |
88–96 | 1,5–2,5 Sekunden | Sauberes Custom-Theme, WebP-Bilder, minimales JavaScript |
| Next.js + Headless CMS Static Site Generation |
95–100 | 0,8–1,5 Sekunden | Statisch generierte Seiten, kein Server-Rendering-Overhead |
Ein schlecht gebautes Headless-Setup kann schlechter performieren als ein gut gebautes WordPress-Setup. Ein gut gebautes Headless-Setup übertrifft ein gutes WordPress-Setup strukturell — aber der Unterschied ist für die meisten Geschäftszwecke marginal.
Kosten im Vergleich: Was kostet welches Setup?
| Kategorie | WordPress (Hawd Design) | Headless (Next.js + Contentful) |
|---|---|---|
| Entwicklungskosten | ab 4.900 € | ab 12.000 € |
| CMS-Lizenz | kostenlos | 0–900 €/Monat |
| Hosting | 15–50 €/Monat | 30–150 €/Monat |
| Wartungsaufwand | Mittel (Plugin-Updates) | Niedrig (statische Seiten) |
| Entwickler-Stundensatz | 65–85 €/Std. | 75–95 €/Std. (React-Entwickler) |
| Content-Pflege ohne Entwickler | ✓ Vollständig möglich | ○ Möglich (mit gutem Interface) |
Drei-Jahres-TCO-Vergleich (Business-Website):
| Setup | Jahr 1 | Jahr 2 | Jahr 3 | Total |
|---|---|---|---|---|
| WordPress (Hawd Starter) | 4.900 € + 540 € | 540 € | 540 € | 6.520 € |
| WordPress (Hawd Business) | 9.500 € + 540 € | 540 € | 540 € | 11.120 € |
| Headless (Next.js + Contentful) | 15.000 € + 1.200 € | 1.200 € | 1.200 € | 18.600 € |
| Headless (Next.js + Sanity Free) | 12.000 € + 600 € | 600 € | 600 € | 13.800 € |
Hosting 30–100 €/Monat je nach Setup. Ohne CMS-Lizenz bei WordPress, mit Basis-Contentful-Tier bei Headless.
Die Entscheidungsmatrix: Was passt zu Ihnen?
| Anforderung | WordPress | Headless |
|---|---|---|
| Inhalte selbst pflegen (kein Technik-Wissen) | ✓ Optimal | ○ Möglich |
| Standard-Blog und News | ✓ Optimal | ○ Überengineering |
| WooCommerce-Shop (Standard) | ✓ Gut | ○ Komplex |
| Multi-Channel (Web + App + weitere) | ○ Eingeschränkt | ✓ Optimal |
| PageSpeed 95+ strukturell | ○ Mit Aufwand | ✓ Standard |
| API-Integrationen (ERP, CRM) | ○ Plugins | ✓ Nativ |
| React/Next.js-Entwicklerteam vorhanden | — | ✓ Voraussetzung |
| Budget unter 10.000 € | ✓ Passend | ✗ Zu teuer |
| Schnelle Umsetzung (< 4 Wochen) | ✓ Möglich | ✗ Unrealistisch |
| Skalierung auf 1M+ Pageviews | ○ Mit Caching | ✓ Strukturell besser |
Welche Architektur passt zu Ihrem Projekt?
WordPress oder Headless — die Entscheidung hängt von Ihren konkreten Anforderungen ab. Wir analysieren Ihren Fall in einem 30-minütigen Erstgespräch auf Deutsch und empfehlen die langfristig richtige Lösung.
Was wir bei Hawd Design empfehlen — und warum
Wir sind keine WordPress-Agentur. Und keine Headless-Agentur. Wir sind eine Agentur, die die Technologie nach den Anforderungen wählt — nicht umgekehrt.
Für die meisten DACH-Mittelständler: WordPress ohne Pagebuilder, mit sauberem Custom-Theme, Gutenberg für die Inhaltspflege, Umami für DSGVO-konformes Analytics. Das ist die pragmatische, kosteneffiziente Lösung, die 90% der Anforderungen erfüllt.
Für spezifische Anforderungen: Next.js mit Sanity oder Contentful, wenn Multi-Channel, extreme Performance oder komplexe API-Integrationen das Projekt definieren.
Der Mittelweg: WordPress als Headless-Backend mit Next.js-Frontend. Das beste aus beiden Welten — bekanntes Redaktionsinterface, modernes performantes Frontend. Mehr Entwicklungsaufwand als reines WordPress, weniger als komplettes Headless-Setup.
No-Code und Low-Code Tools (und traditionelle CMS wie WordPress) dürfen nicht als Bedrohung, sondern als Werkzeuge zur Margensteigerung begriffen werden. Die Technologieentscheidung folgt der Business-Anforderung — nicht dem technischen Trend.