WordPress trägt einen großen Teil des Webs, doch schnell ist damit noch nichts. Im HTTP Archive Web Almanac bestanden 2024 nur 40 Prozent (HTTP Archive Web Almanac) der mobilen WordPress-Seiten alle drei Core Web Vitals gemeinsam, ein deutlicher Fortschritt gegenüber 28 Prozent (HTTP Archive Web Almanac) im Vorjahr und doch weit von einem guten Normalzustand entfernt. Die Ursachen sind bei WordPress meist die immer gleichen: ein Page-Builder, der das Markup aufbläht, eine wachsende Zahl von Plugins mit ungenutzten Assets, eine Datenbank, die sich mit Revisionen, Transients und autoload-Optionen füllt, ein fehlender persistenter Objekt-Cache und ein zu schweres Bild im sichtbaren Bereich. Dieser Beitrag geht die häufigsten Bremsen der Reihe nach durch und zeigt, mit welchen Bordmitteln und in welcher Reihenfolge sich jede einzelne lösen lässt, ohne das System neu zu bauen.
Wie viele WordPress-Seiten wirklich schnell sind
Ein Blick auf die Felddaten ordnet das Problem ein. WordPress lief 2024 auf rund 36 Prozent (HTTP Archive Web Almanac) der mobil untersuchten Seiten und ist damit das mit Abstand verbreitetste CMS. Zugleich bestanden nur 40 Prozent (HTTP Archive Web Almanac) dieser Seiten mobil alle drei Core Web Vitals, gegenüber 28 Prozent (HTTP Archive Web Almanac) ein Jahr zuvor. Interessant ist, wo es hakt: Cumulative Layout Shift erreichten 82 Prozent (HTTP Archive Web Almanac) und Interaction to Next Paint 82 Prozent (HTTP Archive Web Almanac), Letzteres ein Sprung von 69 Prozent (HTTP Archive Web Almanac). Der Bremsklotz ist die Ladeleistung: Largest Contentful Paint bestanden ebenfalls nur rund 40 Prozent (HTTP Archive Web Almanac). Genau dort, beim ersten großen sichtbaren Element, entscheidet sich die gefühlte Geschwindigkeit einer WordPress-Seite.
Das Gewicht liefert die Erklärung. Die mediane mobile WordPress-Seite wog 2024 2.047 KB (HTTP Archive Web Almanac), davon allein 725 KB (HTTP Archive Web Almanac) Bilder und 528 KB (HTTP Archive Web Almanac) JavaScript. Das ist kein Naturgesetz, sondern die Summe vieler kleiner Entscheidungen: ein schweres Theme, ein Page-Builder, eine Handvoll Plugins, unkomprimierte Bilder. Jede dieser Schichten lässt sich einzeln entlasten. Der Bezug zu den Core Web Vitals ist dabei direkt, denn ein leichteres, früher gerendertes Above-the-Fold verbessert LCP unmittelbar, und die Reihenfolge der Maßnahmen entscheidet, wie viel Wirkung mit wie wenig Aufwand entsteht.
Die drei Schwellenwerte im Überblick
Page-Builder und Theme-Overhead
Die erste Bremse sitzt tief im Aufbau der Seite. Ein Großteil der WordPress-Seiten nutzt einen Page-Builder, der verbreitetste lief 2024 auf 56 Prozent (HTTP Archive Web Almanac) der mobilen WordPress-Seiten. Page-Builder sind komfortabel, erzeugen aber oft tief verschachteltes Markup mit vielen Verpackungs-Elementen, laden generische CSS- und JavaScript-Bundles für Funktionen, die eine konkrete Seite gar nicht braucht, und blähen so den DOM auf. Ein großer DOM verlangsamt sowohl das erste Rendern als auch spätere Interaktionen und schlägt damit auf LCP und INP zugleich. Das gleiche gilt für überladene Themes, die Slider, Icon-Bibliotheken und Schriftvarianten mitliefern, die nie zum Einsatz kommen.
Flacheres Markup
Weniger Verschachtelung senkt die DOM-Größe. Wo ein Baukasten für einen einfachen Abschnitt fünf Wrapper erzeugt, reichen oft ein oder zwei, was Rendering und Interaktion beschleunigt.
Kritisches CSS zuerst
Nur das für den sichtbaren Bereich nötige CSS gehört inline in den Head, der Rest wird nachgeladen. So beginnt der Browser früher mit dem Zeichnen, statt auf ein großes Stylesheet zu warten.
Kein Blocking oben
Render-blockierende Skripte und Schriften im Kopf verzögern das erste Bild. Defer, asynchrones Laden und ein sinnvoller Schrift-Fallback halten das Above-the-Fold frei von Wartezeiten.
Der wirksamste Schritt ist die Wahl eines schlanken, aktuellen Themes und der bewusste Verzicht auf einen Page-Builder dort, wo Standard-Blöcke genügen. Wo ein Baukasten bleibt, hilft es, ungenutzte Module zu deaktivieren und die generierten Assets pro Seite zu prüfen. Wie stark ein zu großer DOM auf die Leistung drückt, vertieft der Beitrag zum Reduzieren der DOM-Größe; wie kritisches CSS das erste Rendern beschleunigt, zeigt der Artikel zu Critical CSS im Above-the-Fold.
Plugin-Wildwuchs und ungenutzte Assets
Jedes aktive Plugin darf CSS und JavaScript in die Seite einreihen, und viele tun das global, also auch dort, wo ihre Funktion gar nicht gebraucht wird. Ein Formular-Plugin lädt seine Skripte auf jeder Seite, ein Slider-Plugin auf jeder Unterseite ohne Slider. So summieren sich die medianen 528 KB (HTTP Archive Web Almanac) JavaScript, die eine WordPress-Seite mobil im Schnitt ausliefert. Die offizielle Optimierungs-Anleitung von WordPress nennt den ersten Schritt unmissverständlich: nicht benötigte Plugins deaktivieren und löschen (WordPress.org Documentation). Was bleibt, sollte seine Assets nur dort einreihen, wo sie wirken.
Assets gezielt aus der Warteschlange nehmen
- Doppelte Funktionen zusammenlegen: mehrere Plugins für dieselbe Aufgabe verursachen doppelte Skripte und Konflikte.
- Assets bedingt laden: Handles per Hook nur auf den Seiten einreihen, die sie wirklich brauchen.
- Externe Skripte hinterfragen: eingebettete Widgets und Tracker ziehen Verbindungen zu Drittanbietern nach sich.
- Verwaiste Reste entfernen: deaktivierte Plugins hinterlassen oft Tabellen, Optionen und geplante Aufgaben.
Ein großer Teil des Ballasts kommt zudem von eingebundenen Fremdskripten, die nicht aus dem eigenen Code stammen. Wie sich solche Einbindungen entschlacken und verzögert laden lassen, behandelt der Beitrag zu Third-Party-Skripten entschlacken; wie ein festes JavaScript-Budget den Wildwuchs dauerhaft begrenzt, zeigt der Artikel zu JavaScript-Performance-Budgets. Der Grundsatz bleibt: Jedes Kilobyte, das nicht geladen wird, muss auch nicht geparst und ausgeführt werden.
Datenbank-Bloat: Revisionen, Transients, autoload
Die Datenbank ist die stillste Bremse, weil sie im Betrieb unsichtbar wächst. Drei Quellen treiben den Ballast: Beitragsrevisionen, die WordPress bei jeder Speicherung anlegt, abgelaufene Transients, die als temporärer Zwischenspeicher gedacht sind, aber liegen bleiben, und vor allem die autoload-Optionen in der Tabelle wp_options. Diese autoloaded options werden bei jedem einzelnen Seitenaufruf komplett geladen, unabhängig davon, ob die aktuelle Seite sie braucht. WordPress empfiehlt ausdrücklich, die autoload-Optionen unter 800 KB (WordPress.org Documentation) zu halten, weil zu viele automatisch geladene Optionen die Seite verlangsamen. Plugins, die dort dauerhaft große Datenmengen ablegen, belasten damit jede Anfrage.
// Zahl gespeicherter Revisionen je Beitrag begrenzen
define( 'WP_POST_REVISIONS', 5 );
// Papierkorb automatisch nach 7 Tagen leeren
define( 'EMPTY_TRASH_DAYS', 7 );Der Aufräumprozess besteht aus zwei Teilen. Zunächst begrenzt man das weitere Wachstum, etwa über eine feste Obergrenze für Revisionen und einen automatischen Papierkorb. Danach entfernt man den angesammelten Ballast: abgelaufene Transients, alte Revisionen und verwaiste Metadaten. Wichtig ist, danach die Größe der autoload-Optionen zu prüfen und einzelne Ausreißer gezielt auf nicht-autoload umzustellen, statt pauschal zu löschen. Wie sich langsame Abfragen darüber hinaus mit Indexen und dem Auflösen teurer Abfragemuster beschleunigen lassen, beschreibt der Beitrag zur Datenbank-Query-Optimierung.
| Bremse in der Datenbank | Wirkung | Gegenmaßnahme |
|---|---|---|
| Beitragsrevisionen | wp_posts wächst mit jeder Speicherung | WP_POST_REVISIONS begrenzen, Altbestand entfernen |
| Abgelaufene Transients | verwaiste Zeilen in wp_options | abgelaufene Transients regelmäßig löschen |
| Große autoload-Optionen | werden bei jedem Aufruf geladen | unter 800 KB halten, Ausreißer umstellen |
| Verwaiste Metadaten | unnötige Verknüpfungen und Zeilen | nach Plugin-Deinstallation bereinigen |
Object-Cache und persistentes Caching
WordPress hat einen eingebauten Objekt-Cache, doch der ist standardmäßig nicht persistent: Er hält Daten nur für die Dauer einer einzelnen Anfrage im Speicher und verwirft sie danach (WordPress.org Documentation). Bei jedem Seitenaufruf beginnt der Cache also von vorn, und dieselben Optionen, Metadaten und Abfrageergebnisse werden immer wieder aus der Datenbank geholt. Genau hier setzt ein persistenter Objekt-Cache an. Er behält die Ergebnisse über Anfragen hinweg im Arbeitsspeicher und spart damit die wiederholten Datenbankwege. WordPress benennt den Effekt direkt: Ein persistenter Objekt-Cache verkürzt Antwortzeiten wie die Time to First Byte und schützt die Datenbank in Lastspitzen (WordPress.org Documentation).
Objekt-Cache und Seiten-Cache trennen
Der Seiten-Cache ist der zweite Hebel. WordPress beschreibt, dass ein Seiten-Cache Beiträge und Seiten als statische Dateien ablegt und die Serverlast für weitgehend statische Seiten um ein Vielfaches senken kann (WordPress.org Documentation). Für Gäste-Traffic ist das die wirksamste einzelne Maßnahme, weil eine Anfrage dann weder PHP ausführt noch die Datenbank berührt. Wie Reverse-Proxy und In-Memory-Speicher auf Infrastrukturebene zusammenspielen, vertieft der Beitrag zu Caching-Strategien; die passende Server-Optimierung und das gezielte Senken der TTFB halten die Antwortzeit dauerhaft niedrig.
Caching ersetzt kein Aufräumen
Bilder und LCP im Above-the-Fold
Bilder sind mit medianen 725 KB (HTTP Archive Web Almanac) der größte einzelne Gewichtsposten einer WordPress-Seite und zugleich der häufigste Grund für ein schlechtes LCP. Bei den meisten Seiten ist das größte sichtbare Element ein Bild, etwa das Beitragsbild oder das Hero-Motiv. Drei Stellschrauben entscheiden hier: das Format, die Größe und die Ladepriorität. Moderne Formate wie WebP und AVIF liefern bei gleicher Qualität deutlich kleinere Dateien, passgenau skalierte Varianten verhindern, dass ein riesiges Bild in einen kleinen Rahmen geladen wird, und die richtige Priorität sorgt dafür, dass das entscheidende Bild zuerst kommt.
WebP und AVIF
Moderne Formate senken das Bildgewicht bei gleicher Qualität spürbar. WordPress erzeugt aus jedem Upload passende Größen, die sich zusätzlich in ein modernes Format bringen lassen.
fetchpriority für das LCP-Bild
Das eine wichtige Bild im sichtbaren Bereich bekommt fetchpriority=high, damit der Browser es vorzieht. Das verkürzt die Verzögerung bis zum Laden des größten Elements.
Kein Lazy-Load oben
Bilder unterhalb der Falz laden verzögert, das LCP-Bild aber nicht. Ein lazy geladenes Hero-Bild verschiebt LCP nach hinten, weil der Browser es zu spät anfordert.
Praktisch heißt das: unterhalb des sichtbaren Bereichs greift natives Lazy-Loading, im sichtbaren Bereich bekommt genau ein Bild hohe Priorität und lädt sofort. Wie sich Bildgewichte mit modernen Formaten weiter senken lassen, zeigt der Beitrag zur Bildoptimierung mit WebP und AVIF; wie Prioritäts-Hinweise das LCP-Bild beschleunigen, vertieft der Artikel zu fetchpriority und Priority Hints. Eine strukturierte Bilder-Optimierung bündelt diese Schritte, und der Beitrag zu den Core Web Vitals 2026 ordnet ihren Effekt auf die Kennzahlen ein.
Reihenfolge der Hebel und dauerhaft schnell bleiben
Die einzelnen Maßnahmen wirken am stärksten in der richtigen Reihenfolge. Zuerst kommt die Grundlast: ein schlankes Theme, ausgemistete Plugins und eine aufgeräumte Datenbank machen die kalte Anfrage schnell. Danach senkt ein persistenter Objekt-Cache zusammen mit einem Seiten-Cache die Antwortzeit für die Masse der Aufrufe. Erst dann lohnt der Feinschliff im Frontend, also Bildformate, Ladeprioritäten und kritisches CSS. Wer diese Ordnung umkehrt und mit Caching beginnt, kaschiert die Probleme, ohne sie zu lösen, und stößt bei eingeloggten Nutzern oder Cache-Misses sofort wieder an die alte Wand. Eine fundierte Performance-Analyse misst vorab, welcher Seitentyp die meiste Zeit verliert, damit der Aufwand dorthin fließt, wo er am meisten bewegt.
Das Prinzip gilt über WordPress hinaus. Wer einen Onlineshop betreibt, findet die passenden serverseitigen Hebel im Beitrag zur Shopware-Performance; wie stark die Wahl von Server und Hosting die Antwortzeit vorbestimmt, zeigt der Artikel zur Hosting-Wahl und Server-Ladezeit. Und weil die Time to First Byte den Startpunkt für alle Frontend-Kennzahlen setzt, bleibt das gezielte Beobachten der TTFB als Serverantwortzeit die Grundlage, auf der die WordPress-spezifischen Maßnahmen aufsetzen. Unsere gebündelte WordPress-Performance-Leistung setzt genau diese Reihenfolge um.
Die schnellste WordPress-Seite entsteht nicht durch ein weiteres Plugin, sondern durch das Weglassen: weniger Theme, weniger Skripte, eine schlanke Datenbank und ein Cache, der auf sauberer Grundlast aufsetzt. In dieser Reihenfolge wirkt jeder Schritt.