Core Web Vitals 2026: Warum WordPress schlecht abschneidet

Stellen Sie sich zwei Restaurants vor. Im einen wird jedes Gericht erst bestellt, dann gekocht, dann serviert, Sie warten also bei jeder Bestellung auf die komplette Zubereitung. Im anderen steht ein Teil des Buffets bereits fertig da, aufgewärmt und portioniert, sobald Sie den Tisch betreten. Genau das ist der Unterschied zwischen einem klassischen CMS wie WordPress und einer durchoptimierten, gehosteten Plattform.

WordPress kocht bei jedem einzelnen Seitenaufruf neu, PHP fragt die Datenbank ab und baut die Seite zusammen, erst dann schickt es sie an Ihren Browser. Plattformen wie Duda, Wix oder Squarespace haben diese Zubereitung längst auf Infrastrukturebene gelöst und liefern vorbereitete Seiten aus. Für Ihre Besucherinnen und Besucher macht das den Unterschied zwischen einer Seite, die sofort da ist, und einer, die sie spürbar warten lässt.

Vergleich der Core Web Vitals von WordPress und gehosteten CMS-Plattformen 2026

Die kurze Antwort: Woran WordPress bei den Core Web Vitals scheitert

WordPress besteht die Core Web Vitals auf Mobilgeräten nur zu rund 46 Prozent, weil jede Seite serverseitig aus PHP und Datenbank neu zusammengebaut wird und im Schnitt 20 bis 30 Plugins zusätzliches CSS und JavaScript laden. Gehostete Plattformen wie Duda erreichen 84,9 Prozent, weil sie Seiten zentral optimiert und vorbereitet ausliefern.

Die Zahlen, die Sie kennen sollten

Der CoreWebVitals.io Technology Report, zitiert in WP Tavern, liefert dazu ziemlich eindeutige Werte. WordPress-Websites erreichen auf Mobilgeräten eine Core-Web-Vitals-Bestehensquote von nur etwa 46 Prozent. Zum Vergleich: Duda kommt auf 84,9 Prozent, Wix auf 74,9 Prozent und Squarespace auf 70,4 Prozent. WordPress ist damit trotz seiner Marktführerschaft technisches Schlusslicht unter den großen Plattformen, wenn es um diese Kennzahlen geht.

Das überrascht viele, die WordPress seit Jahren einsetzen und es für ausgereift halten. Technisch gesehen ist es das auch. WordPress ist stabil und wird von einer riesigen Community getragen, dazu flexibel wie kaum ein anderes System. Aber Flexibilität hat hier ihren Preis. Jede Anpassung öffnet eine zusätzliche Baustelle, die Ihre Ladezeit beeinflusst, ob Sie das wollen oder nicht. Das gilt für ein neues Plugin genauso wie für ein neues Theme.

Der eigentliche Übeltäter: Largest Contentful Paint und Time to First Byte

Wenn man genauer hinschaut, liegt das Problem nicht dort, wo man es zuerst vermuten würde. Interaction to Next Paint, also wie schnell eine Seite auf Klicks und Eingaben reagiert, besteht bei WordPress erstaunlich gut, mit einer Erfolgsquote von 85,9 Prozent. Der Schwachpunkt liegt beim Largest Contentful Paint, also der Zeit, bis der größte sichtbare Inhalt einer Seite geladen ist. Und dahinter steckt wiederum ein technisches Detail: die Time to First Byte, kurz TTFB, also die Zeit, bis der Server überhaupt die erste Antwort schickt.

Laut Chrome-UX-Report erreichen nur 32 Prozent der WordPress-Seiten einen guten TTFB-Wert. Der Grund liegt in der Architektur selbst. Klassische CMS-Systeme setzen Seiten bei jeder Anfrage serverseitig aus PHP und Datenbank neu zusammen, statt fertige Seiten einfach auszuliefern. Gehostete Plattformen umgehen dieses Problem, weil sie die Auslieferung direkt auf Infrastrukturebene lösen, etwa durch aggressives Caching oder ein Content Delivery Network. Manche liefern Seiten sogar komplett vorgerendert aus. WordPress kann das auch, aber Sie müssen es selbst einrichten und pflegen: ein Cache-Plugin, ein CDN. Im besten Fall dazu ein Hosting-Anbieter, der auf WordPress spezialisiert ist. Wer das nicht tut, zahlt jeden Tag mit langsameren Ladezeiten.

Warum 20 bis 30 Plugins die Bremse ziehen

Eine durchschnittliche WordPress-Website läuft mit 20 bis 30 aktiven Plugins. Jedes davon bringt in der Regel eigenes CSS und eigenes JavaScript mit, das im Browser geladen und ausgeführt werden muss. Diese Skripte konkurrieren um dieselben Ressourcen und verschlechtern nachweislich sowohl LCP als auch INP, selbst dann, wenn die jeweilige Plugin-Funktion auf der aktuellen Seite gar nicht sichtbar ist. Ein Social-Sharing-Plugin etwa lädt seine Skripte häufig auf jeder Unterseite, auch wenn die Share-Buttons dort nirgends zu sehen sind.

Ein Rechenbeispiel macht das greifbar. Nehmen wir eine typische Wiener Handwerksbetrieb-Website mit WordPress: ein SEO-Plugin, ein Formular-Plugin, ein Cookie-Banner, ein Slider für die Startseite, ein Buchungssystem, eine Backup-Lösung und noch ein Caching-Plugin, das die anderen sechs eigentlich ausgleichen soll. Jedes einzelne davon ist für sich genommen sinnvoll. In Summe aber lädt der Browser bei jedem Seitenaufruf sieben zusätzliche CSS- und JavaScript-Pakete, von denen auf der aktuell besuchten Unterseite vielleicht zwei tatsächlich gebraucht werden. Das ist, als würden Sie bei jedem Einkauf den ganzen Werkzeugkoffer mitschleppen, nur weil Sie theoretisch mal einen Schraubenzieher brauchen könnten.

Die Web-Almanac-Perspektive: Offenheit hat einen Preis

Der HTTP Archive Web Almanac 2025 widmet dem Thema im CMS-Kapitel eigene Auswertungen und kommt zu einem klaren Muster: Je schwerer eine Seite ist, gemessen an Bildlast und dem Gesamtumfang an geladenem JavaScript, desto wahrscheinlicher verfehlt sie die Core-Web-Vitals-Schwellenwerte, besonders auf Mobilgeräten. Interessant ist dabei der strukturelle Unterschied zwischen den Plattformtypen. Systeme, die Anpassbarkeit bewusst einschränken, sorgen durch einheitliche, durchdachte Defaults für bessere Werte. Offen erweiterbare Systeme wie klassische CMS geben die Verantwortung für die Performance dagegen komplett an die Seitenbetreiber und an die Plugin- und Theme-Entwickler ab.

Das ist im Grunde der Kern des Problems. WordPress selbst ist nicht langsam. Eine schlanke WordPress-Installation mit einem sauberen Theme und wenigen, gut programmierten Plugins kann durchaus gute Werte erreichen. Das Problem entsteht erst durch die Summe der Entscheidungen, die über Jahre hinweg von unterschiedlichen Personen getroffen werden, oft ohne dass jemand die Gesamtwirkung im Blick behält. Bei einer gehosteten Plattform trifft diese Entscheidungen der Anbieter zentral und einmal für alle. Bei WordPress trifft sie jeder Websitebetreiber für sich, meistens ohne technischen Hintergrund und ohne zu wissen, was ein zusätzliches Plugin tatsächlich kostet.

Warum das für Ihr Google-Ranking zählt

Das ist keine rein technische Petitesse. Google nutzt die Core Web Vitals, konkret einen LCP unter 2,5 Sekunden, ein INP unter 200 Millisekunden und ein CLS unter 0,1, als Teil des Page-Experience-Rankingsignals. Technische Performance-Schwächen eines CMS wirken sich damit direkt auf die Sichtbarkeit Ihrer Seite in der organischen Suche aus. Wer in Wien im Handwerk, in der Gastronomie oder im Dienstleistungssektor um Kunden konkurriert, konkurriert also auch um schnellere Ladezeiten, nicht nur um bessere Inhalte. Zwei Betriebe mit vergleichbarem Angebot und vergleichbarem Content können bei Google unterschiedlich weit oben stehen, einfach weil die eine Seite in 1,8 Sekunden lädt und die andere in 4,2 Sekunden.

Schritt für Schritt: Was Sie konkret prüfen können

Wenn Sie selbst WordPress betreiben und wissen wollen, wo Sie stehen, brauchen Sie dafür keine große Analyse. Gehen Sie diese Punkte der Reihe nach durch.

Erstens, prüfen Sie Ihren TTFB. Tools wie PageSpeed Insights oder die Chrome-Entwicklertools zeigen Ihnen, wie lange der Server für die erste Antwort braucht. Liegt der Wert über 600 Millisekunden, lohnt sich ein Blick auf Ihr Hosting.

Zweitens, zählen Sie Ihre aktiven Plugins. Alles über 15 bis 20 verdient eine kritische Prüfung. Fragen Sie sich bei jedem Einzelnen, ob es wirklich täglich gebraucht wird oder ob es aus einer Testphase vor zwei Jahren übrig geblieben ist.

Drittens, testen Sie einzelne Unterseiten, nicht nur die Startseite. Oft ist die Startseite optimiert, während Produktseiten oder Blogartikel unter der Last vergessener Plugins leiden.

Viertens, prüfen Sie, ob ein Caching-Plugin und ein CDN aktiv sind. Ohne beides baut WordPress bei jeder Anfrage wirklich alles neu zusammen, das ist bei stärkerem Besucheraufkommen der schnellste Weg zu schlechten Werten.

Fünftens, wenn Sie selbst nicht tief genug in die technische Materie einsteigen wollen oder können, lassen Sie sich das professionell durchleuchten. Über unseren Kontakt können Sie Ihre Seite unkompliziert prüfen lassen, bevor Sie größere Entscheidungen treffen.

Häufige Irrtümer bei diesem Thema

Ein verbreiteter Irrtum ist die Annahme, ein schnelleres Hosting löse das Problem allein. Besseres Hosting hilft beim TTFB, aber wenn zwanzig Plugins weiterhin unnötiges JavaScript ausliefern, bleibt der LCP trotzdem träge. Die Ursache liegt oft nicht ausschließlich im Server, sondern in der Summe der Software, die auf ihm läuft.

Ein zweiter Irrtum ist die Vorstellung, mehr Funktionen seien automatisch besser für die Kunden. Ein Buchungssystem, ein Live-Chat, ein Instagram-Feed und ein Newsletter-Popup klingen einzeln alle sinnvoll. Gemeinsam auf einer Seite verlangsamen sie den Aufbau spürbar, und genau das kostet Sie eher Kunden, als dass es welche bringt.

Ein dritter Irrtum betrifft die Annahme, Core Web Vitals seien nur für sehr große Websites relevant. Auch eine kleine Website eines Wiener Einzelunternehmens wird nach denselben Schwellenwerten bewertet wie eine internationale Plattform. Google unterscheidet hier nicht nach Unternehmensgröße.

Fazit

Traditionelle CMS-Systeme scheitern bei den Core Web Vitals nicht, weil die zugrunde liegende Technik schlecht wäre, sondern weil ihre Offenheit die Verantwortung für Performance auf viele einzelne Entscheidungen verteilt, die selten jemand im Gesamtbild betrachtet. Der TTFB leidet unter der serverseitigen Zusammensetzung jeder einzelnen Seite, und die Vielzahl an Plugins summiert sich zu einer Last, die einzeln kaum auffällt, in der Summe aber deutlich spürbar ist. Gehostete Plattformen lösen diese Probleme zentral, WordPress und vergleichbare Systeme überlassen die Lösung Ihnen.

Key Takeaways

• WordPress besteht die Core Web Vitals auf Mobilgeräten nur zu rund 46 Prozent, gehostete Plattformen wie Duda liegen bei 84,9 Prozent.
• Nicht die Interaktivität ist das Problem, INP besteht zu 85,9 Prozent, sondern der Largest Contentful Paint durch schwachen TTFB.
• Nur 32 Prozent der WordPress-Seiten erreichen laut Chrome-UX-Report einen guten TTFB-Wert.
• Durchschnittlich 20 bis 30 aktive Plugins bringen eigenes CSS und JavaScript mit, das Ladezeiten unabhängig von der sichtbaren Funktion verschlechtert.
• Core Web Vitals sind Teil von Googles Page-Experience-Rankingsignal, technische Schwächen wirken sich also direkt auf Ihre Sichtbarkeit aus.

Wenn Sie nicht wissen, wo Ihre eigene Seite bei diesen Werten steht, oder wenn Sie Ihre WordPress-Website grundlegend überprüfen lassen wollen, melden Sie sich unverbindlich über unseren Kontakt. Wir sehen uns Ihre Seite an und sagen Ihnen ehrlich, wo die Zeit tatsächlich verloren geht.