Core Web Vitals mit WordPress: woran es scheitert und wie weit man es bringt

Die Ausgangslage ist besser als ihr Ruf: Laut dem Web Almanac 2025 der HTTP Archive bestehen 45 Prozent aller erfassten WordPress-Seiten die Core Web Vitals auf Mobilgeräten, während das Gesamtweb bei 48 Prozent liegt. Grün ist mit WordPress also weder exotisch noch selten — knapp jede zweite Installation schafft es. Die interessantere Frage ist, woran die andere Hälfte scheitert, und die Antwort ist erstaunlich gleichförmig.

Denn die Ursachen verteilen sich nicht zufällig. Sie sammeln sich an vier Stellen: einer trägen Serverantwort, einem zu schweren Hero-Bild, zu viel ausgeführtem JavaScript und nachgeladenen Elementen ohne reservierten Platz. Dieser Artikel geht sie der Reihe nach durch, rechnet ein LCP-Budget vor, das sich nachprüfen lässt, und benennt am Ende die Grenze, an der Optimieren teurer wird als neu bauen.

Welche der drei Metriken WordPress tatsächlich reisst

Der Engpass ist fast immer LCP, nicht CLS — und das lässt sich beziffern. Im Datensatz des Web Almanac 2025 bestehen 53 Prozent der WordPress-Seiten den Largest Contentful Paint auf Mobilgeräten, gegenüber 62 Prozent im Gesamtweb. Beim Cumulative Layout Shift liegt WordPress mit 84 Prozent dagegen leicht über dem Webdurchschnitt von 81 Prozent. Anders gesagt: WordPress-Seiten sind visuell stabiler als der Durchschnitt und laden langsamer.

Das ist plausibel, wenn man weiss, wie eine typische Installation arbeitet. Layoutstabilität wird von Theme und Editor weitgehend vorgegeben, dort kann der Betreiber wenig falsch machen. Die Ladezeit dagegen entsteht aus PHP-Ausführung, Datenbankabfragen, Hosting-Qualität und der Summe aller eingebundenen Dateien — vier Faktoren, die niemand vorgibt und die sich über Jahre unbemerkt verschlechtern.

Für Interaction to Next Paint weist der Datensatz keinen eigenen WordPress-Wert aus. Aus der Praxis lässt sich aber sagen, dass INP der Wert ist, der am längsten rot bleibt, weil er als einziger nicht durch Konfiguration zu gewinnen ist. Was die drei Metriken grundsätzlich messen, haben wir im Beitrag zu Core Web Vitals und INP erklärt; hier geht es um die konkreten Ursachen in einer WordPress-Installation.

Das LCP-Budget: 2'500 Millisekunden, vier Etappen

Ein LCP-Wert lässt sich in vier aufeinanderfolgende Etappen zerlegen, und jede davon ist einzeln messbar und einzeln zu verbessern. Die Summe muss unter 2'500 Millisekunden bleiben. Die folgende Rechnung zeigt eine typische Ausgangslage — geteiltes Hosting, unoptimiertes Hero-Bild, ein Dutzend Plugins — und dieselbe Seite nach vier Standardmassnahmen. Angenommen ist eine mobile Verbindung mit rund 7 Mbit/s effektivem Durchsatz.

Die Zahlen sind nachrechenbar. Ein 1'200 KB grosses Bild entspricht 9,6 Megabit; bei 7 Mbit/s dauert die Übertragung rund 1,37 Sekunden. Dasselbe Motiv als WebP mit 90 KB entspricht 0,72 Megabit, also rund 0,1 Sekunden, zu denen etwa 150 Millisekunden Verbindungsaufbau kommen. Allein diese eine Zeile bringt 1'150 Millisekunden — mehr als die anderen drei Etappen zusammen.

Genau das ist der Grund, warum LCP bei WordPress so oft scheitert und warum er sich so zuverlässig reparieren lässt. Die Medienbibliothek nimmt entgegen, was hochgeladen wird, und viele Themes liefern das Original in einer Grösse aus, die niemand geprüft hat. Wer nur diese eine Stelle in Ordnung bringt, verschiebt den Wert typischerweise um mehr als eine Sekunde.

INP: der Wert, den keine Konfiguration rettet

INP misst nicht, wie schnell eine Seite lädt, sondern wie stark der Hauptthread des Browsers blockiert ist, wenn jemand klickt — und diese Blockade entsteht durch die Summe allen ausgeführten JavaScripts. Damit ist INP die einzige der drei Metriken, die sich nicht durch eine Einstellung verbessern lässt. Man kann Skripte später laden, aufteilen oder verzögern; ausgeführt werden sie trotzdem, und dann konkurrieren sie mit der Reaktion auf die Eingabe des Nutzers.

In einer gewachsenen WordPress-Installation kommt dieses JavaScript aus vielen Richtungen gleichzeitig: aus dem Theme, aus dem Page Builder, aus jedem einzelnen Plugin, aus dem Consent-Manager, aus dem Tag Manager und aus allem, was der Tag Manager wiederum nachlädt. Der Web Almanac hält dazu fest, dass Page Builder tendenziell komplexere DOM-Strukturen sowie grössere CSS- und JavaScript-Pakete erzeugen — und rund 60 Prozent der WordPress-Seiten setzen einen ein, allen voran Elementor mit 43 Prozent Anteil an dieser Gruppe.

Der einzige wirksame Hebel heisst deshalb Weglassen, und er ist unbequem, weil er Verzicht bedeutet. Die Reihenfolge, die sich bewährt hat: zuerst der Drittanbieter-Code, den niemand mehr auswertet — alte Heatmap-Tools, doppelte Analytics-Einbindungen, Chat-Widgets ohne Betreuung. Danach die Plugins, deren Funktion sich mit zehn Zeilen im Theme abbilden lässt. Erst zuletzt die Bausteine, an denen wirklich etwas hängt.

Wie viel dabei zu holen ist, zeigt eine Messung an unserer eigenen Seite. Nach dem Zurücknehmen einer einzigen Auslieferungsentscheidung fiel das ausgelieferte HTML von /seo-agentur-zuerich von 517 KB auf 159 KB, die Text-Ratio stieg von 2,45 auf 9,45 Prozent, und die Payload bei internen Klicks sank um 79 Prozent (eigene Messung, August 2026). Weniger Code heisst weniger Arbeit für den Browser, und das ist bei INP die einzige Währung, die zählt. Warum dieselbe Zahl auch für die Sichtbarkeit in der KI-Suche relevant ist, haben wir unter Text-Ratio und Payload durchgerechnet.

CLS: der Teil, den man mit Disziplin gewinnt

Layoutstabilität ist bei WordPress meist schon in Ordnung und lässt sich mit wenigen Regeln vollständig absichern. Die 84 Prozent Bestehensquote aus dem Web Almanac bestätigen das. Die verbleibenden Fälle folgen fast immer demselben Muster: Etwas wird nachgeladen und schiebt bereits sichtbare Inhalte nach unten, genau in dem Moment, in dem der Nutzer tippen will.

Die vier üblichen Verursacher sind schnell benannt. Bilder ohne Angabe von Breite und Höhe zwingen den Browser, den Platz erst nach dem Laden zu reservieren. Werbeflächen und Einbettungen ohne Platzhalter tun dasselbe in grösserem Massstab. Cookie-Banner, die von oben einfahren, verschieben die gesamte Seite. Und Webfonts ohne passenden Ersatz erzeugen beim Wechsel einen sichtbaren Sprung, wenn sich die Zeilenhöhe ändert.

Alle vier lassen sich ohne Umbau beheben: Abmessungen an jedes Bild, feste Höhen für alles Nachgeladene, Banner als Overlay statt als Layoutelement, und Schriften mit einer metrisch ähnlichen Systemschrift als Fallback. Das ist unspektakuläre Arbeit von wenigen Stunden — und der einzige Bereich, in dem eine WordPress-Seite ohne Weiteres über den Webdurchschnitt kommt.

Was Caching-Plugins leisten und was nicht

Ein Caching-Plugin verbessert genau eine der vier LCP-Etappen zuverlässig und wirkt auf INP praktisch nicht. Diese Einordnung ist wichtig, weil Caching in der Praxis oft als Gesamtlösung verkauft wird. Was ein Page-Cache tut, ist wertvoll: Er liefert fertiges HTML aus, statt es bei jedem Aufruf neu aus PHP und Datenbank zu erzeugen. In der Rechnung oben ist das die erste Zeile — 900 auf 300 Millisekunden, ein realer Gewinn.

Ein vorgelagertes CDN wie Cloudflare verstärkt diesen Effekt, weil die Antwort geografisch näher am Besucher entsteht. Für Schweizer Seiten mit Schweizer Publikum ist der Gewinn kleiner als oft angenommen, weil die Wege ohnehin kurz sind; spürbar wird er vor allem bei Besuchern aus dem Ausland und bei Lastspitzen.

Was Caching nicht kann: Es entfernt kein JavaScript. Nach der Auslieferung führt der Browser exakt dieselben Skripte aus wie vorher, und der Hauptthread ist genauso belegt. Funktionen zum Zusammenfassen und Verzögern von Dateien, wie sie viele Optimierungs-Plugins mitbringen, verschieben die Ausführung, sie reduzieren sie nicht — und sie sind die häufigste Ursache dafür, dass nach einer Optimierungsrunde einzelne Funktionen der Seite nicht mehr arbeiten. Wer solche Schalter aktiviert, muss danach jede interaktive Komponente von Hand prüfen.

Wie weit man es realistisch bringt

Mit Caching, CDN, Bildoptimierung und konsequentem Aufräumen erreichen die meisten WordPress-Seiten grüne LCP- und CLS-Werte und einen INP im gelben, oft auch im grünen Bereich — das reicht, um die Core Web Vitals insgesamt zu bestehen. Der Aufwand liegt erfahrungsgemäss bei zwei bis vier Arbeitstagen für eine mittelgrosse Unternehmensseite, sofern niemand tragende Funktionen verteidigen muss.

Die Obergrenze ist erreicht, wenn der verbleibende Ballast Teil des Produkts ist. Ein Seitenaufbau, der vollständig aus Page-Builder-Modulen besteht, lässt sich nicht schlank machen, ohne ihn neu zu bauen. Ein Buchungs-, Filter- oder Konfigurationssystem, das als Plugin eingekauft wurde, bringt sein JavaScript mit, und daran ändert keine Einstellung etwas. In diesen Fällen endet die Optimierung typischerweise bei einem knapp bestandenen Ergebnis, das nach dem nächsten grösseren Update wieder kippt.

Das ist der Punkt, an dem die Frage nach dem System berechtigt wird — aber als Wirtschaftlichkeitsfrage, nicht als Ranking-Frage. Warum das System für sich genommen kein Rankingfaktor ist, haben wir in Rankt eine WordPress-Seite schlechter ausführlich behandelt.

Wann Optimieren teurer wird als neu bauen

Der Umbau rechnet sich, sobald die verbleibenden Massnahmen bedeuten würden, tragende Bestandteile der Seite auszubauen — denn dann baut man ohnehin neu, nur ungeordnet und ohne Plan. Ein brauchbarer Prüfpunkt ist die investierte Zeit: Wer mehr als drei Tage optimiert hat und INP weiterhin im roten Bereich liegt, sollte aufhören zu schrauben und beide Wege sauber gegenüberstellen — die Kosten der nächsten Optimierungsrunde plus deren jährliche Wiederholung gegen die Kosten eines Neubaus plus dessen Wartung.

Für diese Gegenüberstellung braucht es zuerst einen belastbaren Befund. Ein Website-Audit liefert ihn mitsamt Felddaten und einer nach Wirkung sortierten Massnahmenliste, der schnellere SEO-Check reicht für eine erste Einschätzung. Fällt die Entscheidung für den Neubau, stehen die Rahmenbedingungen unter Website erstellen lassen und Webdesign-Preise; für Projekte im Raum Zürich ist die Webentwicklung Zürich der direkte Einstieg.

Und wenn die Rechnung zugunsten der bestehenden Seite ausfällt, ist das ein gutes Ergebnis. Eine WordPress-Seite mit grünen Core Web Vitals ist kein Kompromiss, sondern eine Seite, an der jemand aufgeräumt hat. Genau darauf kommt es an — nicht auf das System, sondern darauf, was am Ende ausgeliefert wird.