WordPress schneller machen: Was Core Web Vitals wirklich verbessert

Wer seine WordPress-Website mit Google PageSpeed Insights überprüft und auf Mobilgeräten nur 60 oder 70 Punkte erreicht, bekommt schnell den Eindruck, dass dringend etwas repariert werden muss. Performance-Plugins versprechen bessere Ergebnisse, SEO-Tools melden technische Probleme und zahlreiche Anleitungen erklären, wie sich der PageSpeed-Score möglichst auf 100 steigern lässt.

Dabei bedeutet ein Wert von 65 Punkten weder, dass eine Website grundsätzlich langsam oder fehlerhaft ist, noch erklärt er automatisch, warum eine Seite bei Google keine guten Rankings erreicht. Er zeigt zunächst, dass unter den simulierten Testbedingungen Verbesserungspotenzial besteht. Ob dieses Potenzial für tatsächliche Besucher relevant ist und welche Maßnahmen sich lohnen, muss genauer untersucht werden.

Google verwendet die sogenannten Core Web Vitals, um bestimmte Aspekte der Nutzererfahrung messbar zu machen. Dazu gehören die Geschwindigkeit, mit der die wichtigsten Inhalte sichtbar werden, die Reaktionsfähigkeit einer Seite auf Benutzerinteraktionen und die Stabilität des Layouts während des Ladens.

Diese Kennzahlen spielen auch für die Suchmaschinenoptimierung eine Rolle. Allerdings sind sie nur ein Teil der Bewertung einer Website. Relevanz, hilfreiche Inhalte, Suchintention und die allgemeine Wettbewerbsfähigkeit einer Seite sind für gute Platzierungen häufig wesentlich entscheidender. Moderate Performance-Probleme haben meiner Erfahrung nach für sich genommen selten einen eindeutig messbaren Rankingeffekt. Bei sehr schlechter Performance sieht die Situation anders aus, insbesondere wenn eine Website dadurch kaum noch vernünftig genutzt werden kann.

Der wichtigste Grund für eine schnelle Website sind ohnehin nicht die Google-Rankings, sondern die Menschen, die sie verwenden. Lange Ladezeiten können dazu führen, dass Besucher eine Seite verlassen, bevor sie überhaupt den Inhalt gesehen haben. Verzögerte Reaktionen auf Klicks lassen eine Anwendung unzuverlässig wirken, und springende Layout-Elemente können versehentliche Interaktionen verursachen. Gerade auf kommerziellen Websites kann das Anfragen und Verkäufe beeinträchtigen, lange bevor sich ein möglicher Effekt auf die Suchmaschinenplatzierungen nachweisen lässt.

Ein PageSpeed-Score von 65 ist deshalb kein Grund zur Panik. Er sollte vielmehr der Ausgangspunkt für eine Untersuchung sein, welche Komponenten die Website tatsächlich ausbremsen und ob diese Probleme bei echten Besuchern auftreten.

Was Google PageSpeed Insights tatsächlich misst

Google PageSpeed Insights kombiniert zwei unterschiedliche Arten von Informationen: simulierte Labordaten und, sofern ausreichend Daten verfügbar sind, Messwerte von echten Websitebesuchern.

Die simulierten Tests werden mit Lighthouse durchgeführt. Dabei lädt Google die untersuchte Seite unter kontrollierten Bedingungen und mit bewusst begrenzten Ressourcen. So lassen sich technische Probleme reproduzierbar untersuchen und unterschiedliche Optimierungen miteinander vergleichen.

Ein Lighthouse-Test bildet allerdings nicht exakt die Erfahrungen aller Besucher einer Website ab. Die simulierte mobile Umgebung verwendet bestimmte Annahmen über die Leistungsfähigkeit des Geräts und die Geschwindigkeit der Netzwerkverbindung. Ein tatsächlicher Besucher kann ein wesentlich leistungsfähigeres Smartphone und eine schnellere Internetverbindung verwenden. Andere Nutzer können dagegen unter deutlich schlechteren Bedingungen unterwegs sein.

Gerade bei einer Website, deren Zielgruppe überwiegend in Deutschland oder anderen europäischen Ländern sitzt, können die tatsächlichen Bedingungen erheblich von der simulierten Testumgebung abweichen. Daraus folgt allerdings nicht automatisch, dass europäische Besucher grundsätzlich schnellere Geräte oder bessere Verbindungen besitzen. Entscheidend sind die tatsächlichen Nutzerdaten der jeweiligen Website.

Hier kommen die sogenannten Felddaten (Field Data) ins Spiel.

Wenn Google ausreichend Informationen zur Verfügung stehen, zeigt PageSpeed Insights zusätzlich aggregierte Messwerte aus dem Chrome User Experience Report (CrUX). Diese basieren auf Erfahrungen echter Chrome-Nutzer und beschreiben die Performance über einen längeren Zeitraum.

Auch der Core-Web-Vitals-Bericht in der Google Search Console verwendet solche realen Nutzerdaten.

Deshalb kann eine Website im simulierten Lighthouse-Test nur 68 Punkte erreichen, während ihre tatsächlichen Core Web Vitals bereits im guten Bereich liegen. Umgekehrt ist ebenfalls möglich, dass ein einzelner Labortest hervorragend ausfällt, reale Besucher aber regelmäßig Performance-Probleme erleben.

Für die Bewertung würde ich deshalb zunächst die Felddaten betrachten, sofern ausreichend Daten vorhanden sind. Anschließend nutze ich Lighthouse und die Entwicklertools des Browsers, um konkrete Ursachen zu untersuchen.

Der PageSpeed-Score ist dabei ein hilfreicher Diagnosewert, aber kein eigenständiges Optimierungsziel.

Die drei Core Web Vitals verstehen

Die aktuellen Core Web Vitals bestehen aus Largest Contentful Paint (LCP), Interaction to Next Paint (INP) und Cumulative Layout Shift (CLS).

Sie messen unterschiedliche Aspekte der Nutzererfahrung und können auf einer WordPress-Website aus völlig verschiedenen Gründen schlechte Werte erreichen.

Kennzahl	Was wird gemessen?	Guter Wert
Largest Contentful Paint (LCP)	Wann der größte relevante sichtbare Inhalt dargestellt wird	≤ 2,5 Sekunden
Interaction to Next Paint (INP)	Wie schnell die Seite sichtbar auf Benutzerinteraktionen reagiert	≤ 200 Millisekunden
Cumulative Layout Shift (CLS)	Wie stark sichtbare Elemente unerwartet ihre Position verändern	≤ 0,1

Google bewertet diese Kennzahlen anhand realer Nutzerdaten üblicherweise am 75. Perzentil. Ein guter Durchschnittswert allein ist deshalb nicht ausreichend, wenn ein erheblicher Teil der Besucher deutlich schlechtere Erfahrungen macht.

Für die technische Optimierung ist es wichtig, die drei Messwerte getrennt zu betrachten. Ein Problem mit der Bildauslieferung erfordert andere Maßnahmen als eine durch JavaScript blockierte Benutzeroberfläche oder ein Layout, das während des Ladens mehrfach seine Struktur verändert.

Largest Contentful Paint: Wann erscheint der wichtigste Inhalt?

Largest Contentful Paint misst, wie lange es dauert, bis das größte relevante Inhaltselement im sichtbaren Seitenbereich dargestellt wird.

Auf vielen Unternehmenswebsites ist das ein großes Hero-Bild am Anfang der Seite. Es kann sich aber auch um eine Überschrift, einen Textblock oder ein anderes großes Element handeln.

Wenn das LCP-Element ein Bild ist, würde ich zunächst untersuchen, wann der Browser von diesem Bild erfährt und welche Ressourcen geladen werden müssen, bevor es dargestellt werden kann.

Dabei spielen unter anderem die Dateigröße, das Bildformat, die Komprimierung, responsive Bildvarianten und die Priorisierung des Downloads eine Rolle. Ebenso wichtig sind die Serverantwortzeit und mögliche Verzögerungen durch CSS oder JavaScript.

Das wichtigste Bild sollte nicht unnötig spät geladen werden

Ein häufiger Fehler besteht darin, das große Hero-Bild einer Website mit loading="lazy" auszuliefern.

Lazy Loading ist für Bilder sinnvoll, die sich außerhalb des zunächst sichtbaren Bereichs befinden. Bei einem Bild, das unmittelbar nach dem Seitenaufruf sichtbar sein soll und möglicherweise das LCP-Element bildet, kann es dagegen die Darstellung verzögern.

WordPress verfügt inzwischen über eigene Mechanismen zur Optimierung des Ladeverhaltens von Bildern. Je nach Kontext können dabei Attribute wie loading oder fetchpriority automatisch gesetzt werden.

Das bedeutet allerdings nicht, dass die erzeugten Attribute in jeder Situation optimal sind. Besonders bei individuellen Themes, Slidern oder Page-Builder-Komponenten sollte das tatsächlich ausgegebene HTML überprüft werden.

Mit fetchpriority="high" lässt sich beispielsweise die Priorität einer wichtigen Bildressource erhöhen. Das kann helfen, wenn der Browser die Datei zwar früh erkennt, ihr aber nicht ausreichend Priorität einräumt.

Ein Preload kann dagegen sinnvoll sein, wenn eine besonders wichtige Ressource erst spät entdeckt würde, beispielsweise weil ein Hero-Bild ausschließlich über CSS eingebunden ist.

Beide Maßnahmen sollten gezielt eingesetzt werden. Wer wahllos zahlreiche Bilder vorlädt oder mit hoher Priorität versieht, kann die Konkurrenz um verfügbare Netzwerkressourcen sogar verschärfen.

Erst den tatsächlichen Engpass identifizieren

Nicht jede LCP-Optimierung beginnt bei der Bildkomprimierung.

Wenn der Server bereits zwei Sekunden benötigt, um das HTML-Dokument auszuliefern, wird die Reduzierung einer Bilddatei um einige Kilobyte das grundlegende Problem kaum lösen.

Dasselbe gilt, wenn das wichtigste Bild erst nach mehreren JavaScript-Ausführungen entdeckt wird oder umfangreiche Stylesheets seine Darstellung verzögern.

Deshalb würde ich zunächst den gesamten Ladeablauf untersuchen und feststellen, wo die Zeit tatsächlich verloren geht. Erst danach lässt sich entscheiden, ob Bildoptimierung, Ressourcenpriorisierung, Caching oder eine Änderung am Theme den größten Nutzen verspricht.

Interaction to Next Paint: Warum reagiert WordPress manchmal träge?

Interaction to Next Paint misst, wie schnell eine Website sichtbar auf Benutzerinteraktionen reagiert. Dazu gehören beispielsweise Klicks, Berührungen und Tastatureingaben.

Eine Seite kann bereits vollständig geladen aussehen und sich trotzdem langsam anfühlen. Das passiert beispielsweise, wenn ein Klick auf ein Menü erst nach einer deutlichen Verzögerung eine Reaktion auslöst oder Eingaben in einem Formular nur stockend verarbeitet werden.

Bei WordPress-Websites würde ich bei solchen Problemen häufig zunächst die JavaScript-Ausführung untersuchen.

Plugins und Themes können zahlreiche Skripte laden, obwohl deren Funktionen auf der aktuellen Seite überhaupt nicht benötigt werden. Consent-Management-Systeme, Analytics-Dienste, Chat-Widgets, Slider, Page-Builder und WooCommerce-Erweiterungen können zusätzliche Arbeit auf dem Hauptthread des Browsers verursachen.

Dabei sagt die reine Anzahl installierter WordPress-Plugins erstaunlich wenig aus.

Eine Website mit vierzig gut entwickelten Plugins kann im Frontend problemlos funktionieren, während eine andere Installation durch ein einziges schlecht implementiertes Skript spürbar ausgebremst wird.

Entscheidend ist, welche Ressourcen tatsächlich geladen werden und wie viel Arbeit sie im Browser verursachen.

Warum Chrome DevTools hilfreicher sind als die Plugin-Liste

Mit dem Performance-Panel der Chrome DevTools lässt sich untersuchen, was während einer langsamen Interaktion im Browser passiert.

Dabei kann sichtbar werden, ob die Verzögerung durch JavaScript-Ausführung, aufwendige Layout-Berechnungen, Style-Neuberechnungen oder das anschließende Rendering entsteht.

Sobald die Ursache bekannt ist, können gezielte Maßnahmen umgesetzt werden. Vielleicht wird ein umfangreiches Skript auf jeder Seite geladen, obwohl es nur für ein bestimmtes Formular benötigt wird. Möglicherweise führt ein Event-Handler unnötig viele Berechnungen aus oder eine Komponente verändert bei jeder Interaktion große Teile des DOM.

Auch externe Skripte können eine Rolle spielen. Besonders Chat-Widgets, Marketing-Technologien oder andere Drittanbieter-Dienste bringen häufig zusätzlichen JavaScript-Code mit, dessen Ausführung nur eingeschränkt kontrolliert werden kann.

JavaScript verzögern ist nicht immer die beste Lösung

Performance-Plugins bieten häufig Funktionen an, mit denen JavaScript verzögert oder erst nach einer Benutzerinteraktion ausgeführt wird.

Das kann in bestimmten Situationen erhebliche Verbesserungen bringen, insbesondere wenn nicht benötigte Drittanbieter-Skripte den Seitenaufbau belasten.

Allerdings ist es häufig eher eine nachträgliche Optimierung als die Beseitigung der eigentlichen Ursache.

Wenn ein Skript grundsätzlich überflüssig ist, sollte zunächst geprüft werden, ob es vollständig entfernt werden kann. Wenn es nur auf bestimmten Seiten benötigt wird, ist bedingtes Laden oft sinnvoller als eine pauschale Verzögerung.

Außerdem kann aggressives Verzögern dazu führen, dass Menüs, Formulare oder andere Funktionen nicht sofort reagieren, wenn Besucher sie verwenden möchten.

Eine bessere Lighthouse-Bewertung ist wenig wert, wenn die Website dadurch im tatsächlichen Gebrauch schlechter funktioniert.

Cumulative Layout Shift: Wenn Inhalte beim Laden springen

Cumulative Layout Shift misst unerwartete Veränderungen der Position sichtbarer Seitenelemente.

Ein typisches Beispiel ist ein Textabschnitt, der plötzlich nach unten verschoben wird, weil oberhalb ein Bild oder ein Banner nachgeladen wurde. Besonders störend ist das, wenn ein Besucher gerade auf einen Button klicken möchte und sich dessen Position im letzten Moment verändert.

Solche Layout-Verschiebungen entstehen häufig, wenn der Browser beim ersten Aufbau einer Seite nicht weiß, wie viel Platz eine bestimmte Komponente benötigt.

Bilder und eingebettete Inhalte brauchen reservierten Platz

Bei Bildern sollte der Browser möglichst früh erkennen können, welches Seitenverhältnis sie besitzen. Dafür können beispielsweise die Attribute width und height oder eine entsprechende CSS-Regel mit aspect-ratio verwendet werden.

So lässt sich der benötigte Platz bereits reservieren, bevor die Bilddatei vollständig geladen wurde.

Dasselbe Prinzip gilt für Videos, eingebettete Inhalte und andere Komponenten, deren Abmessungen erst später bekannt werden.

Auch Slider können problematisch sein, wenn ihre Höhe erst nach der Initialisierung durch JavaScript festgelegt wird.

Webfonts, Cookie-Banner und dynamische Inhalte

Schriftarten können ebenfalls Layout-Verschiebungen verursachen. Wenn zunächst eine Ersatzschrift angezeigt wird und die später geladene Webfont deutlich andere Zeichenbreiten besitzt, kann sich der Zeilenumbruch verändern.

Auch nachträglich eingefügte Banner, Benachrichtigungen oder andere Komponenten können zu CLS-Problemen führen.

Bei Cookie-Bannern hängt der Effekt stark von der Implementierung ab. Ein Overlay, das über dem vorhandenen Inhalt liegt, verursacht nicht zwangsläufig einen Layout Shift. Wird dagegen nachträglich Platz im normalen Seitenfluss eingefügt, kann sich der gesamte Inhalt verschieben.

Solche Probleme lassen sich häufig besser verstehen, wenn man die tatsächlichen Layout-Verschiebungen im Browser beobachtet, statt nur den endgültigen CLS-Wert zu betrachten.

Sobald klar ist, welches Element sich bewegt und warum, ist die technische Korrektur oft relativ überschaubar.

Die Serverantwortzeit ist weiterhin ein wichtiger Faktor

Bevor der Browser Bilder, Schriften oder andere Inhalte darstellen kann, muss er zunächst das HTML-Dokument erhalten.

Wenn der WordPress-Server dafür ungewöhnlich lange benötigt, beginnt der eigentliche Seitenaufbau bereits mit einem erheblichen Zeitverlust. Das wirkt sich häufig auch auf den Largest Contentful Paint aus.

Hier spielen insbesondere die Hosting-Umgebung und die verschiedenen Caching-Mechanismen eine Rolle.

Ohne Full-Page-Cache muss WordPress bei einem gewöhnlichen Seitenaufruf unter anderem PHP ausführen, WordPress und die benötigten Plugins initialisieren, Datenbankabfragen durchführen und das HTML-Dokument erzeugen.

Je nach Theme, Plugin-Konfiguration und Umfang der Website kann dabei eine erhebliche Menge an Arbeit entstehen.

Wenn eine Seite für alle Besucher weitgehend identisch ist, muss dieser Prozess nicht bei jedem Aufruf vollständig wiederholt werden.

Ein Full-Page-Cache kann bereits erzeugte HTML-Antworten zwischenspeichern und bei späteren Anfragen direkt ausliefern. Dadurch lassen sich zahlreiche PHP-Ausführungen und Datenbankabfragen vermeiden.

Die unterschiedlichen Caching-Arten in WordPress

Bei WordPress werden verschiedene Caching-Mechanismen eingesetzt, die unterschiedliche Aufgaben erfüllen.

Caching-Art	Aufgabe
Full-Page-Caching	Speichert komplette HTML-Antworten, damit WordPress bei geeigneten Anfragen nicht vollständig ausgeführt werden muss
Object-Caching	Speichert häufig benötigte Daten und Ergebnisse von Berechnungen beziehungsweise Datenbankabfragen
Browser-Caching	Ermöglicht dem Browser, bestimmte Ressourcen wie Bilder, CSS und JavaScript wiederzuverwenden
PHP-Opcode-Caching	Speichert kompilierten PHP-Code, damit dieser nicht bei jeder Ausführung erneut verarbeitet werden muss

Diese Mechanismen ergänzen sich, ersetzen einander aber nicht.

Ein persistenter Object-Cache mit Redis oder Memcached kann beispielsweise wiederholte Datenbankarbeit reduzieren. Er ist allerdings kein Ersatz für Full-Page-Caching.

WordPress besitzt bereits einen internen Object-Cache, dessen Inhalte standardmäßig nur während der jeweiligen Anfrage verfügbar sind. Erst durch eine entsprechende persistente Cache-Implementierung können geeignete Daten über mehrere Requests hinweg wiederverwendet werden.

Für viele weitgehend statische Unternehmenswebsites bringt effektives Full-Page-Caching den größten unmittelbaren Vorteil bei der Serverantwortzeit.

Bei dynamischen Anwendungen oder WooCommerce-Shops kann dagegen auch ein persistenter Object-Cache besonders wertvoll sein, weil zahlreiche Anfragen nicht vollständig aus einem Seiten-Cache bedient werden können.

Braucht eine schnelle WordPress-Website einen eigenen VPS?

Performance-Beratung führt erstaunlich häufig zu Empfehlungen für immer leistungsfähigeres Hosting.

Dabei benötigt nicht jede WordPress-Website einen eigenen virtuellen Server.

Eine gewöhnliche Unternehmenswebsite mit überschaubarem Traffic kann auf einem guten Shared-Hosting- oder Managed-WordPress-Tarif hervorragend funktionieren, insbesondere wenn Full-Page-Caching korrekt eingerichtet ist.

Ein WooCommerce-Shop mit vielen gleichzeitigen Nutzern, individuellen Warenkörben und dynamischen Funktionen hat dagegen andere Anforderungen. Dasselbe gilt für Mitgliederplattformen, Buchungssysteme oder Anwendungen mit zahlreichen nicht cachebaren Anfragen.

In solchen Fällen werden unter anderem PHP-Performance, Datenbankkonfiguration, CPU-Ressourcen, Object-Caching und die technische Architektur der Anwendung wichtiger.

Ich würde deshalb nicht allein aufgrund einer schlechten Serverantwortzeit in PageSpeed Insights empfehlen, sofort auf einen VPS umzuziehen.

Zunächst sollte untersucht werden, wo die Zeit tatsächlich verloren geht. Vielleicht funktioniert das vorhandene Caching nicht, obwohl es eigentlich aktiv sein sollte. Möglicherweise verursacht eine bestimmte Plugin-Funktion unnötig viele Datenbankabfragen oder ein externer API-Aufruf verzögert die Generierung des HTML-Dokuments.

Ein leistungsfähigerer Server kann solche Probleme teilweise kaschieren. Er beseitigt aber nicht automatisch ihre Ursache.

Welches WordPress-Cache-Plugin ist das beste?

WP Rocket, LiteSpeed Cache, W3 Total Cache, WP Super Cache und ähnliche Lösungen können je nach Hosting-Umgebung gute Ergebnisse liefern.

Die entscheidende Frage ist allerdings weniger, welches Plugin grundsätzlich am besten ist, sondern welcher Caching-Mechanismus in der konkreten Serverumgebung tatsächlich verwendet werden kann.

Ein Teil des Cachings kann direkt innerhalb von WordPress erfolgen. Andere Lösungen nutzen Funktionen des Webservers oder vorgelagerter Systeme.

Gerade serverseitiges Full-Page-Caching kann sehr effizient sein, weil eine gecachte Antwort ausgeliefert werden kann, ohne WordPress überhaupt vollständig zu starten.

In solchen Umgebungen dient ein WordPress-Plugin häufig vor allem dazu, den serverseitigen Cache zu konfigurieren oder bei Änderungen gezielt zu leeren.

LiteSpeed Cache bietet beispielsweise besondere Vorteile, wenn die entsprechende LiteSpeed-Serverinfrastruktur vorhanden ist und die zugehörigen Funktionen genutzt werden können.

WP Rocket kombiniert Full-Page-Caching mit verschiedenen Frontend-Optimierungen und bietet eine vergleichsweise komfortable Konfiguration.

Auch andere Lösungen können zuverlässig funktionieren, wenn sie korrekt eingerichtet sind und zur Hosting-Umgebung passen.

Mehrere Cache-Plugins machen WordPress nicht automatisch schneller

Die gleichzeitige Installation mehrerer umfangreicher Cache-Plugins ist normalerweise keine gute Idee.

Wenn unterschiedliche Erweiterungen dieselben Aufgaben übernehmen, können widersprüchliche Einstellungen, doppelte Optimierungen und unerwartete Fehler entstehen.

Besonders problematisch wird es, wenn mehrere Plugins gleichzeitig JavaScript verzögern, CSS-Dateien verändern oder unterschiedliche Mechanismen zur Cache-Invalidierung verwenden.

Natürlich können verschiedene Caching-Ebenen sinnvoll kombiniert werden. Beispielsweise können ein serverseitiger Full-Page-Cache, Redis und Browser-Caching problemlos zusammenarbeiten.

Wichtig ist lediglich, dass klar definiert ist, welche Komponente welche Aufgabe übernimmt.

Für die meisten WordPress-Websites würde ich deshalb eine passende Caching-Lösung sorgfältig konfigurieren, statt mehrere Optimierungs-Plugins auf Verdacht miteinander zu kombinieren.

Warum 100 Punkte bei PageSpeed selten das eigentliche Ziel sein sollten

Ab einem bestimmten Punkt bringen zusätzliche Performance-Optimierungen nur noch einen geringen praktischen Nutzen.

Eine Website, die bereits schnell lädt, zuverlässig reagiert und gute reale Core Web Vitals erreicht, wird für ihre Besucher nicht automatisch spürbar besser, nur weil sich der Lighthouse-Score von 96 auf 100 erhöht.

Die verbleibenden Empfehlungen betreffen möglicherweise nur noch kleine Ressourcen, minimale Verzögerungen oder Funktionen, die aus geschäftlichen Gründen bewusst eingesetzt werden.

Auch Google empfiehlt gute Core Web Vitals, weist aber darauf hin, dass ein perfekter PageSpeed-Score kein eigenständiges SEO-Ziel sein sollte.

Wenn eine sinnvolle Funktion die Ladezeit in einem synthetischen Test um 80 Millisekunden erhöht, würde ich sie normalerweise nicht allein deshalb entfernen.

Wenn dagegen ein externes Skript sämtliche Benutzerinteraktionen um eine halbe Sekunde verzögert, lohnt sich eine genauere Untersuchung.

Gute Performance bedeutet nicht, sämtliche Funktionen für einen möglichst hohen Messwert zu opfern. Sie bedeutet, unnötige Verzögerungen zu vermeiden und die Website für echte Besucher zuverlässig nutzbar zu machen.

Welche WordPress-Optimierungen häufig überschätzt werden

Viele Performance-Berichte empfehlen Maßnahmen, die technisch durchaus sinnvoll sein können, aber nicht zwangsläufig die wichtigsten Probleme einer Website lösen.

Einige davon werden besonders häufig umgesetzt, ohne vorher den tatsächlichen Nutzen zu prüfen.

Kleine CSS- und JavaScript-Dateien weiter minimieren

Minification kann die Größe von CSS- und JavaScript-Dateien reduzieren. In Kombination mit moderner Komprimierung und effektivem Caching sind die zusätzlichen Einsparungen bei bereits kleinen Dateien allerdings häufig gering.

Wenn der Server beispielsweise 1,8 Sekunden für die HTML-Antwort benötigt, wird die Reduzierung einer kleinen CSS-Datei um wenige Kilobyte kaum einen relevanten Unterschied machen.

Das bedeutet nicht, dass Minification nutzlos ist. Sie sollte lediglich nicht vor deutlich größeren Engpässen priorisiert werden.

Sämtliche CSS- und JavaScript-Dateien zusammenfassen

Früher war es häufig sinnvoll, möglichst viele Ressourcen in wenigen Dateien zusammenzufassen, um die Anzahl der HTTP-Anfragen zu reduzieren.

Unter HTTP/1.1 konnte die Zahl paralleler Verbindungen tatsächlich ein erheblicher begrenzender Faktor sein.

Mit HTTP/2 und HTTP/3 hat sich diese Situation verändert. Das pauschale Zusammenführen sämtlicher Dateien kann heute sogar Nachteile haben, beispielsweise wenn dadurch Ressourcen geladen werden, die auf der aktuellen Seite gar nicht benötigt werden.

Auch die Wiederverwendung bereits gecachter Dateien kann dadurch erschwert werden.

Entscheidender als die reine Anzahl der Dateien ist deshalb, welche Inhalte sie enthalten, wann sie geladen werden und ob die jeweilige Seite sie überhaupt benötigt.

Lazy Loading für sämtliche Bilder aktivieren

Lazy Loading ist besonders für Bilder sinnvoll, die sich deutlich unterhalb des zunächst sichtbaren Seitenbereichs befinden.

Das wichtigste Bild direkt am Seitenanfang sollte dagegen normalerweise früh geladen werden.

Wer sämtliche Bilder unterschiedslos mit Lazy Loading versieht, kann den Largest Contentful Paint verschlechtern.

Gerade bei WordPress lohnt es sich deshalb, die tatsächlich generierten loading– und fetchpriority-Attribute zu überprüfen, statt ausschließlich auf die Einstellungen eines Optimierungs-Plugins zu vertrauen.

Grundsätzlich jedes Skript verzögern

Das pauschale Verzögern von JavaScript kann einen Lighthouse-Test deutlich verbessern.

Allerdings kann es auch dazu führen, dass interaktive Elemente erst nach dem ersten Klick initialisiert werden oder Funktionen zunächst nicht verfügbar sind.

Bei Menüs, Formularen, Produktvarianten oder anderen wichtigen Komponenten kann das die tatsächliche Nutzererfahrung verschlechtern.

Deshalb sollte JavaScript gezielt verzögert werden, wenn es für den anfänglichen Seitenaufbau und die ersten Interaktionen nicht benötigt wird.

Noch besser ist es häufig, unnötige Skripte vollständig zu entfernen oder nur auf den Seiten zu laden, auf denen ihre Funktionen tatsächlich verwendet werden.

So untersuche ich eine langsame WordPress-Website

Bei der Performance-Optimierung würde ich zunächst versuchen, das Problem einer bestimmten technischen Ebene zuzuordnen.

Dafür betrachte ich nach Möglichkeit zuerst die realen Core Web Vitals. Sie zeigen, ob tatsächliche Besucher Schwierigkeiten mit LCP, INP oder CLS haben und welche Seitengruppen besonders betroffen sind.

Anschließend versuche ich, die Probleme mit Lighthouse, Chrome DevTools und Netzwerkanalysen nachzustellen.

Dabei untersuche ich insbesondere, ob die Verzögerungen hauptsächlich durch folgende Bereiche verursacht werden:

• Serverantwortzeit und Hosting
• Langsam geladene LCP-Ressourcen
• Render-blockierendes CSS oder JavaScript
• Umfangreiche JavaScript-Ausführung
• Externe Dienste und Tracking-Skripte
• Instabile Layouts und nachgeladene Komponenten
• Theme oder Page Builder
• Datenbankabfragen und PHP-Verarbeitung
• Fehlerhafte oder ineffiziente Caching-Konfigurationen

In vielen Fällen ergibt sich daraus eine relativ klare Priorisierung.

Vielleicht verursacht eine einzige große Bilddatei den schlechten LCP-Wert. Vielleicht werden mehrere umfangreiche JavaScript-Bibliotheken auf sämtlichen Seiten geladen, obwohl sie nur für einzelne Funktionen benötigt werden.

Es kann aber auch sein, dass die Performance-Probleme auf eine grundlegend ungünstige technische Architektur zurückzuführen sind und kleinere Frontend-Optimierungen deshalb kaum etwas bewirken.

Die passende Lösung hängt immer von der tatsächlichen Ursache ab.

Was ich möglichst vermeiden würde, ist die Installation eines weiteren Optimierungs-Plugins, bevor überhaupt klar ist, welche Komponente die Website ausbremst.

Fazit: WordPress-Performance sollte an echten Problemen gemessen werden

Eine schnelle WordPress-Website ist wichtig. Nicht nur für die Suchmaschinenoptimierung, sondern vor allem für die Menschen, die sie verwenden.

Die Core Web Vitals helfen dabei, wichtige Aspekte der Nutzererfahrung zu messen. Largest Contentful Paint beschreibt, wie schnell der wichtigste Inhalt erscheint. Interaction to Next Paint bewertet die Reaktionsfähigkeit auf Benutzerinteraktionen, und Cumulative Layout Shift zeigt, ob sich das Layout während der Nutzung unerwartet verschiebt.

Diese Kennzahlen sind hilfreicher als ein einzelner PageSpeed-Score, weil sie konkrete Probleme sichtbar machen.

Allerdings sollte auch hier nicht blind optimiert werden.

Ein schlecht priorisiertes Hero-Bild benötigt andere Maßnahmen als ein überlasteter WordPress-Server. Umfangreiche JavaScript-Ausführung lässt sich nicht durch Bildkomprimierung beheben, und zusätzliche Cache-Plugins lösen keine grundlegenden Probleme mit der Benutzeroberfläche.

Die wichtigste Frage lautet deshalb nicht: „Wie bekomme ich 100 Punkte bei PageSpeed?“, sondern: „Was macht meine Website für tatsächliche Besucher langsam, und wie behebe ich genau dieses Problem?“

Manchmal reicht dafür eine kleine Änderung am Theme, eine bessere Ressourcenpriorisierung oder die Korrektur einer Cache-Einstellung. In anderen Fällen müssen Plugins, Datenbankabfragen oder die technische Architektur genauer untersucht werden.

Für meine Arbeit im Bereich WordPress-Entwicklung gehört Performance-Optimierung deshalb nicht nur zur Frontend-Entwicklung. Ich betrachte auch die WordPress-Installation selbst, das Zusammenspiel der Plugins, die Caching-Ebenen sowie die Server- und Hosting-Konfiguration.

Das Ziel ist eine Website, die zuverlässig und schnell funktioniert, ohne dafür unnötige technische Komplexität einzuführen.