Die Geschwindigkeit einer Website hat schon lange aufgehört, ein rein technisches Detail zu sein, um das sich Serveradministratoren und Programmierer kümmern. Heute wirkt sie sich unmittelbar nicht nur auf den Komfort der Nutzer, den Verkaufserfolg und die Ausnutzung des Werbebudgets aus, sondern auch auf die Sichtbarkeit der Website in Google und anderen Suchmaschinen.

Das Problem ist, dass die Optimierung von WordPress oft auf ein einfaches Schema reduziert wird: ein Cache-Plugin installieren, Google PageSpeed Insights starten und um jeden Preis versuchen, ein Ergebnis von 100/100 zu erreichen.

In der Praxis sieht gute Optimierung anders aus.

Zuerst muss man feststellen, was die Seite tatsächlich verlangsamt, und erst danach die konkreten Elemente verbessern: Server, WordPress-Backend, CSS, JavaScript, Bilder, Schriften, externe Skripte oder die DOM-Struktur.

Was ist Seitengeschwindigkeit eigentlich?

Es gibt keinen einzelnen Wert, der besagt, dass eine Seite „in 2 Sekunden lädt”.

Das Laden einer Seite ist ein Prozess. Der Browser verbindet sich zunächst mit dem Server, lädt das HTML herunter, analysiert das Dokument, lädt weitere Ressourcen, baut DOM und CSSOM auf, führt JavaScript aus, rendert Elemente und lässt den Nutzer erst danach frei mit der Oberfläche arbeiten.

Deshalb können zwei Seiten scheinbar ähnlich lange laden, und dennoch wird eine von ihnen als deutlich schneller wahrgenommen.

Wenn der Nutzer sofort die Überschrift, das Produktfoto und den Button „Kaufen” sieht, kann die Seite auch dann schnell wirken, wenn weniger wichtige Elemente noch im Hintergrund geladen werden.

Ist dagegen in den ersten zwei Sekunden nur ein weißer Bildschirm zu sehen, fällt das Erlebnis eindeutig schlechter aus.

Genau deshalb beschränkt Google die Messung der Performance nicht auf eine einzige Ladezeit.

PageSpeed Insights ist mehr als ein Wert von 0 bis 100

Google PageSpeed Insights analysiert eine Seite mithilfe von Lighthouse und zeigt sowohl Labordaten als auch Informationen zu den tatsächlichen Nutzererfahrungen, sofern genügend solcher Daten vorliegen.

Am sichtbarsten ist der Performance-Wert:

• 0-49 – schwaches Ergebnis,
• 50-89 – verbesserungsbedürftig,
• 90-100 – gutes Ergebnis.

Diese Werte sollten Sie jedoch nicht wie Schulnoten behandeln.

Eine Seite mit dem Wert 92 muss geschäftlich nicht besser sein als eine Seite mit dem Wert 86. Mehr noch: Das Ergebnis eines Lighthouse-Tests kann sich zwischen aufeinanderfolgenden Messungen ändern.

Deutlich wichtiger ist es zu verstehen, was ein schwaches Ergebnis verursacht und wie sich die Seite bei echten Nutzern verhält.

Core Web Vitals – wichtiger als die Jagd nach 100 Punkten

Google konzentriert sich derzeit vor allem auf die drei grundlegenden Kennzahlen der Core Web Vitals:

LCP – Largest Contentful Paint

Misst den Moment, in dem das größte relevante Element im anfänglichen Sichtbereich der Seite angezeigt wird. Meistens ist das ein großes Foto, ein Banner oder ein Textabschnitt.

Ein gutes Ergebnis sind maximal 2,5 Sekunden.

INP – Interaction to Next Paint

Zeigt, wie schnell die Seite auf Aktionen des Nutzers reagiert, etwa auf einen Klick auf einen Button, die Auswahl einer Produktvariante oder das Aufklappen eines Menüs.

Ein gutes Ergebnis sind maximal 200 ms.

CLS – Cumulative Layout Shift

Misst unerwartete Verschiebungen des Layouts.

Wenn der Nutzer einen Button anklicken will, im letzten Moment aber darüber eine Anzeige oder ein Bild erscheint und der Button nach unten rutscht, fällt der CLS hoch aus.

Ein gutes Ergebnis ist maximal 0,1.

Google bewertet diese Kennzahlen auf Basis des 75. Perzentils der Besuche, getrennt für Mobilgeräte und Desktop-Rechner.

Wirkt sich die Seitengeschwindigkeit auf SEO aus?

Ja, aber es lohnt sich, diesen Zusammenhang richtig zu verstehen.

Er funktioniert nicht nach einem einfachen Schema:

Seite A hat einen PageSpeed von 95, Seite B hat 80, also landet Seite A automatisch weiter oben in Google.

Google versucht nach wie vor in erster Linie, dem Nutzer den passendsten Inhalt zu zeigen. Eine gute Nutzererfahrung, zu der auch die Performance der Seite gehört, ist eines der Elemente, die in den Suchergebnissen helfen können, aber sie ersetzt weder die Qualität der Inhalte noch deren Relevanz.

Die Performance-Optimierung hat allerdings noch einen zweiten, oft wichtigeren Effekt.

Eine schnellere Seite bedeutet weniger Nutzer, die vor dem Laden abspringen, einen schnelleren Weg zum Produkt oder Formular und weniger Reibung auf dem Weg zur Conversion.

Deshalb sollten Sie die PageSpeed-Optimierung vor allem als Optimierung der Nutzererfahrung betrachten und erst danach als technisches SEO.

Wie lässt sich die Geschwindigkeit von WordPress verbessern?

Es gibt kein einzelnes universelles Plugin, das alle Probleme löst.

Die Performance von WordPress ist die Summe vieler Schichten:

1. der Serverinfrastruktur,
2. der Konfiguration von PHP und Datenbank,
3. von WordPress und den eingesetzten Plugins,
4. des Themes,
5. von HTML und DOM,
6. von CSS,
7. von JavaScript,
8. von Bildern und Schriften,
9. externer Dienste,
10. von Cache und CDN.

Die besten Ergebnisse bringt die Optimierung dieser Elemente in der richtigen Reihenfolge.

1. Beginnen Sie mit TTFB und dem Server

Wenn der Server allein zwei Sekunden braucht, um das HTML zu erzeugen, löst die Optimierung der Bilder das grundlegende Problem nicht.

TTFB, also Time to First Byte, bezeichnet die Zeit vom Beginn der Anfrage bis zum Empfang der ersten Daten vom Server.

Auf das Ergebnis wirken unter anderem:

• die Leistung des Prozessors,
• die Auslastung des Servers,
• Version und Konfiguration von PHP,
• die Leistung von MySQL/MariaDB,
• die Anzahl der ausgeführten Abfragen,
• WordPress-Plugins,
• externe APIs,
• der Cache,
• die Entfernung des Nutzers zum Server.

In Polen trifft man noch immer auf WordPress-Installationen, die auf günstigem Shared Hosting zusammen mit Hunderten anderer Websites laufen. Ein schneller Internetanschluss des Nutzers hilft wenig, wenn jede PHP-Anfrage auf die Ressourcen eines überlasteten Servers warten muss.

Eine gute Lösung kann ein passend konfigurierter VPS sein, ein für WordPress optimiertes Hosting oder eine Cloud-Infrastruktur.

Der Name der Technologie allein garantiert allerdings keine Performance. Ein schlecht konfigurierter VPS kann deutlich langsamer laufen als ein gutes Shared-Hosting-Konto.

2. Nutzen Sie einen Page Cache

WordPress erzeugt Seiten dynamisch.

Ein normaler Seitenaufruf kann bedeuten:

1. PHP starten,
2. WordPress laden,
3. die Plugins starten,
4. SQL-Abfragen ausführen,
5. HTML erzeugen,
6. das Ergebnis an den Browser senden.

Wenn das Ergebnis für die meisten Nutzer identisch ist, ist es Ressourcenverschwendung, den gesamten Vorgang bei jedem Aufruf auszuführen.

Ein Page Cache speichert das fertige HTML und kann es bei weiteren Anfragen zurückgeben, ohne die gesamte Anwendung erneut zu starten.

Bei Content-Seiten kann der Unterschied sehr groß sein.

Anders sieht es in Systemen mit Nutzerdaten, Warenkorb, Checkout oder Kundenpanel aus. Dort muss der Cache vorsichtiger konfiguriert werden.

3. Ein Object Cache hilft dem WordPress-Backend

Page Cache und Object Cache lösen zwei verschiedene Probleme.

Ein Object Cache, der zum Beispiel Redis nutzt, erlaubt es, die Ergebnisse häufig wiederholter Operationen und Abfragen aufzubewahren.

Das kann bei umfangreicheren WordPress- und WooCommerce-Installationen große Bedeutung haben.

Es bedeutet allerdings nicht automatisch, dass die bloße Installation von Redis jede Seite beschleunigt. Zuerst muss geprüft werden, wo der Bottleneck tatsächlich liegt.

4. Reduzieren Sie renderblockierendes CSS und JavaScript

Der Browser kann die Seite nicht sofort zeichnen, wenn er zuvor renderblockierende Ressourcen herunterladen und verarbeiten muss.

Ein typisches Beispiel ist eine große CSS-Datei oder synchrones JavaScript im <head>.

Bei CSS lohnt es sich:

• seinen Umfang zu begrenzen,
• ungenutzte Regeln zu entfernen,
• kritische Styles auszulagern,
• CSS, das am Seitenanfang nicht gebraucht wird, später zu laden.

Google nennt die Reduktion und das Aufschieben von nicht kritischem CSS als einen der Wege, die Renderverzögerung des LCP-Elements zu verringern.

JavaScript lässt sich dagegen mit defer oder async laden, sofern die Logik der Anwendung das zulässt.

Sie sollten defer allerdings nicht automatisch allen Skripten hinzufügen. Plugins hängen häufig von der Reihenfolge der Codeausführung ab, und eine aggressive automatische Optimierung kann die Seite beschädigen.

5. Entfernen Sie ungenutztes CSS

Ein umfangreiches Theme kann Styles enthalten für:

• WooCommerce,
• Formulare,
• Slider,
• Galerien,
• Popups,
• Tabellen,
• Blog-Elemente,
• Widgets,

auch wenn die konkrete Unterseite keines davon nutzt.

Der Browser muss die gesamte Datei dennoch herunterladen und verarbeiten.

Mit Chrome DevTools Coverage lässt sich prüfen, welcher Teil von CSS und JavaScript tatsächlich genutzt wird.

In größeren Projekten ist es eine gute Lösung, separate Ressourcenpakete für verschiedene Seitentypen zu bauen, statt überall eine einzige riesige Datei zu laden.

6. Übertreiben Sie es nicht mit JavaScript

JavaScript ist einer der häufigsten Gründe für die Situation, dass eine Seite geladen aussieht, aber weiterhin langsam reagiert.

Der Browser muss den Code:

• herunterladen,
• parsen,
• kompilieren,
• ausführen.

In dieser Zeit kann der Haupt-Thread belegt sein.

Besonders deutlich zeigt sich das Problem auf Telefonen mit schwächerem Prozessor.

Eine große JavaScript-Anwendung kann auf dem Rechner des Entwicklers hervorragend laufen und gleichzeitig auf einem einige Jahre alten Smartphone des Nutzers einen sehr schlechten INP haben.

Deshalb lohnt es sich:

• unnötige Bibliotheken zu entfernen,
• den Code in kleinere Teile aufzuteilen,
• Funktionen erst dann zu laden, wenn sie gebraucht werden,
• lange JavaScript-Tasks zu begrenzen,
• nicht alle Komponenten beim ersten Rendern zu initialisieren.

7. Achten Sie auf die WordPress-Plugins

Die reine Anzahl der Plugins ist nicht das beste Maß für Performance.

30 gut geschriebene kleine Plugins können schneller laufen als ein einziger schwerer Page Builder.

Ein Problem entsteht dann, wenn ein Plugin:

• bei jedem Aufruf teure Abfragen ausführt,
• sein CSS auf allen Seiten lädt,
• sein JavaScript überall lädt, unabhängig davon, ob es gebraucht wird,
• synchron mit einer externen API kommuniziert,
• während init viel Code ausführt,
• Aufgaben erledigt, die asynchron laufen sollten.

Deshalb sollten Sie bei ernsteren Performance-Problemen die Anwendung profilen, statt wahllos ein WordPress-Plugin nach dem anderen zu deaktivieren. Das ist technisch komplizierter, aber die Ergebnisse sind auch deutlich besser.

8. Minifizieren Sie CSS und JavaScript, erwarten Sie aber keine Wunder

Die Minifizierung entfernt aus dem Code, was der Browser nicht braucht:

• Leerzeichen,
• Kommentare,
• Formatierung,
• manche langen Namen.

Das verringert die Dateigröße.

Das ist eine gute Praxis für Produktivsysteme, aber heute ist der Unterschied zwischen einer minifizierten und einer nicht minifizierten Datei, die zusätzlich mit Brotli- oder GZIP-Kompression ausgeliefert wird, oft deutlich kleiner als noch vor einigen Jahren.

Eine deutlich größere Verbesserung kann es bringen, unnötigen Code gar nicht erst auszuliefern.

9. Behalten Sie die Zahl der Requests und den Gesamttransfer im Blick

Jede zusätzliche Ressource bedeutet weitere Arbeit für den Browser.

Das heißt nicht, dass Sie unbedingt alle Dateien zu einer einzigen zusammenfassen müssen. Bei HTTP/2 und HTTP/3 ergibt diese Strategie oft keinen Sinn mehr.

Dennoch lohnt es sich weiterhin, Ressourcen zu reduzieren, die nichts beitragen.

Insbesondere:

• JavaScript-Bibliotheken,
• Schriften,
• Tracker,
• Social-Media-Widgets,
• iframes,
• Videos,
• große Bilder,
• doppelt eingebundene Bibliotheken.

Optimierung sollte darin bestehen, die Menge der geleisteten Arbeit zu verringern, und nicht nur die Zahl, die im Bericht steht.

10. Bilder sind eine der größten Einsparquellen

Ein Foto, das auf der Seite in der Größe 800 × 500 px angezeigt wird, sollte nicht als Datei mit 5000 × 3000 px geladen werden.

Das ist einer der am einfachsten zu findenden Fehler.

WordPress kann automatisch verschiedene Bildgrößen erzeugen, und der Browser kann dank srcset und sizes die passende Version auswählen.

Es lohnt sich außerdem, moderne Formate einzusetzen:

• WebP,
• AVIF.

In vielen Fällen lässt sich damit der Transfer deutlich senken, bei weiterhin guter Bildqualität.

Sie sollten allerdings nicht mechanisch alles in ein einziges Format konvertieren. Das Ergebnis der Kompression muss an realem Material beurteilt werden.

11. Nutzen Sie Lazy Loading nicht für alles

Lazy Loading ist sehr nützlich für Bilder, die weit unterhalb des ersten Bildschirms liegen.

Ein Beispiel:

<img
    src="photo.webp"
    loading="lazy"
    width="800"
    height="600"
    alt="Bildbeschreibung"
>

Heutige Browser unterstützen natives loading="lazy", sodass in vielen Fällen keine zusätzliche JavaScript-Bibliothek mehr nötig ist.

Es gibt jedoch eine wichtige Ausnahme.

Laden Sie das Hauptbild oberhalb der Falz nicht lazy, insbesondere dann nicht, wenn es das LCP-Element ist.

Ein solches Bild sollte so früh wie möglich zu laden beginnen. Google empfiehlt ausdrücklich, Bilder im anfänglichen Viewport, vor allem das LCP-Bild, nicht per Lazy Loading zu laden.

12. Kümmern Sie sich um das Bild, das für LCP verantwortlich ist

Wenn das größte Element der Seite das Hauptproduktfoto oder ein Hero-Banner ist, sollte sein Download so früh wie möglich beginnen.

Ein Problem entsteht, wenn das Bild:

• nur als background-image im CSS gesetzt ist,
• erst durch JavaScript hinzugefügt wird,
• ein fehlerhaftes Lazy Loading hat,
• vom Browser zu spät entdeckt wird.

In bestimmten Situationen lässt sich unter anderem einsetzen:

fetchpriority="high"

oder ein Preload der Ressource.

Sie sollten allerdings nicht ein Dutzend Grafiken gleichzeitig preloaden. Wenn alles hohe Priorität erhält, erfüllen Prioritäten praktisch keine Funktion mehr.

13. Legen Sie die Größen von Bildern und anderen Elementen fest

Elemente sollten Abmessungen haben, die dem Browser bekannt sind.

Bei Bildern können das sein:

width="800"
height="600"

Dadurch kann der Browser den entsprechenden Platz reservieren, bevor die Datei selbst geladen ist.

Das verringert das Risiko von Layoutverschiebungen, also eines schlechteren CLS.

Ein ähnliches Problem tritt auf bei:

• Anzeigen,
• iframes,
• Embeds,
• dynamischen Bannern,
• Elementen, die per JavaScript geladen werden.

14. Optimieren Sie Schriften

Auch eine Webschrift ist eine Ressource, die heruntergeladen werden muss.

Eine Seite, die Folgendes nutzt:

• 4 Schriftfamilien,
• 5 Schnitte je Familie,
• Kursive,
• zusätzliche Zeichensätze,

kann deutlich mehr Daten laden, als nötig ist.

Es lohnt sich, die Zahl der Varianten zu begrenzen und WOFF2 zu nutzen.

Eine gute Praxis ist außerdem:

font-display: swap;

Dadurch kann der Nutzer den Text bereits in einer Ersatzschrift sehen, bevor die Zielschrift geladen ist.

Für die kritischsten Schriften ist ein Preload manchmal gerechtfertigt.

15. Begrenzen Sie externe Skripte

Eine Seite kann gut optimiert sein und trotzdem langsam laufen, weil Code von anderen Diensten stammt.

Typische Beispiele:

• Werbesysteme,
• Analytics,
• Chats,
• Heatmaps,
• Bewertungs-Widgets,
• Social Media,
• A/B-Testing-Systeme,
• YouTube-Videos,
• Karten.

Jedes dieser Elemente kann eigenes JavaScript laden, Event-Listener setzen und Code im Haupt-Thread ausführen.

Auf polnischen Firmenwebsites und in Online-Shops wächst das Problem oft schrittweise: Zuerst kommt die Statistik dazu, später Meta Pixel, Google Ads, ein Chat, ein Marketing-Automation-Tool und weitere Widgets. Jedes für sich wirkt klein, zusammen können sie jedoch zu einer der Hauptquellen von Performance-Problemen werden.

Eine Lösung kann sein:

• unnötige Dienste zu entfernen,
• den Start zu verzögern,
• erst nach einer Interaktion zu laden,
• leichte Platzhalter statt schwerer iframes einzusetzen.

16. Aktivieren Sie HTTP-Kompression

HTML, CSS, JavaScript, JSON, XML und andere Textformate lassen sich sehr gut komprimieren.

Der Server sollte sie daher zum Beispiel so ausliefern:

• Brotli,
• GZIP.

Das verringert die Datenmenge, die zwischen Server und Browser übertragen wird.

Formate, die bereits über eine eigene wirksame Kompression verfügen, etwa die meisten Bilder oder Videos, sollten Sie dagegen nicht erneut komprimieren.

17. Stellen Sie einen passenden Browser-Cache ein

Statische Dateien, die sich selten ändern, sollten nicht bei jedem Besuch erneut geladen werden.

Das betrifft unter anderem:

• CSS,
• JavaScript,
• Bilder,
• Schriften.

Die passenden Header:

Cache-Control
Expires
ETag

erlauben es dem Browser, bereits geladene Ressourcen erneut zu verwenden.

Bei versionierten Dateien, zum Beispiel:

app.a87c913.js

lässt sich eine sehr lange Cache-Zeit verwenden, denn eine Änderung des Inhalts führt zu einem neuen Dateinamen.

18. Vermeiden Sie unnötige Weiterleitungen

Jeder Redirect bedeutet einen zusätzlichen Request.

Zum Beispiel:

http://example.com
↓
https://example.com
↓
https://www.example.com
↓
https://www.example.com/pl/

bedeutet mehrere Operationen, bevor der Nutzer beim eigentlichen Dokument ankommt.

Bei einem einzelnen Seitenaufruf muss das keine Katastrophe sein, aber ähnliche Ketten innerhalb der Seite, in CSS, JavaScript oder Werbung können unnötige Verzögerungen erzeugen.

Verlinken Sie direkt auf die Zieladressen.

19. Kontrollieren Sie die Größe des DOM

Page Builder erlauben es, komplizierte Layouts schnell zu erstellen, erzeugen aber oft sehr umfangreiches HTML.

Ein optisch einfaches Element kann im Code so aussehen:

<div>
    <div>
        <div>
            <div>
                <div>
                    <span>Text</span>
                </div>
            </div>
        </div>
    </div>
</div>

Multipliziert man eine solche Struktur mit Hunderten von Komponenten, wächst das DOM mitunter auf enorme Größen an.

Ein großes DOM bedeutet mehr Arbeit beim:

• Parsen,
• Berechnen der Styles,
• Layout,
• Aktualisieren von Elementen per JavaScript.

Deshalb erfordert die Frontend-Optimierung manchmal eine Änderung der Art, wie Komponenten gebaut werden, und nicht die Installation eines weiteren Cache-Plugins.

20. WooCommerce verlangt einen eigenen Ansatz

Ein Online-Shop ist anspruchsvoller als eine typische Firmenwebsite.

Hier haben wir:

• den Warenkorb,
• den Checkout,
• die Nutzersitzung,
• Produktvarianten,
• Filter,
• die Suche,
• Preise,
• Lagerbestände,
• Kurier-Integrationen,
• das Zahlungssystem.

Man kann also nicht einfach alles cachen.

Es lohnt sich, getrennt zu analysieren:

• das Produktlisting,
• die Produktseite,
• die Suche,
• den Warenkorb,
• den Checkout,
• das Kundenpanel.

Oft ist das größte Problem nicht die Produktseite selbst, sondern die Abfragen der Filter, umfangreiche Produktvarianten oder Plugins, die bei jedem Request laufen.

21. Ein CDN repariert kein langsames WordPress

Ein CDN erlaubt es, Ressourcen aus einer Infrastruktur auszuliefern, die näher am Nutzer liegt.

Hervorragend eignet es sich für:

• Bilder,
• CSS,
• JavaScript,
• Schriften,
• andere statische Dateien.

Sie sollten ein CDN jedoch nicht als Heilmittel gegen ein langsames Backend betrachten.

Wenn WordPress drei Sekunden braucht, um das HTML-Dokument zu erzeugen, kann ein CDN das Problem durch Cache teilweise verdecken, es beseitigt aber nicht die Ursache.

Zuerst muss festgestellt werden, was die Anwendung tatsächlich verlangsamt.

22. Optimieren Sie nicht nur die Startseite

Das ist einer der häufigeren Fehler bei der Arbeit an PageSpeed.

Ein Unternehmen optimiert die Homepage auf den Wert 95, aber ein Nutzer, der aus Google direkt auf einen Artikel oder eine Produktseite kommt, erlebt etwas völlig anderes.

Sie sollten repräsentative Typen von Unterseiten testen:

• die Startseite,
• eine Landingpage,
• einen Artikel,
• eine Kategorie,
• ein Produkt,
• ein Formular,
• den Warenkorb,
• den Checkout.

Jedes Template kann andere Probleme haben.

23. Testen Sie vor allem mobil

Das Desktop-Ergebnis sieht sehr oft gut aus, selbst bei einer nur durchschnittlich optimierten Seite.

Mobilgeräte zeigen Probleme schneller:

• schwächerer Prozessor,
• weniger Speicher,
• langsamere Verbindung,
• höhere Kosten der JavaScript-Ausführung.

Genau deshalb sollte die PSI-Analyse immer mit der mobilen Version beginnen.

24. Labordaten und Nutzerdaten sind zwei verschiedene Dinge

Ein einzelner PageSpeed-Test ist eine Simulation unter bestimmten Bedingungen.

Felddaten zeigen dagegen die Erfahrungen echter Nutzer.

Das ist eine sehr wichtige Unterscheidung.

Es ist möglich, in einem einzelnen Labortest ein schwaches Ergebnis zu erhalten und gleichzeitig bei den Nutzern gute Core Web Vitals zu haben.

Der umgekehrte Fall ist ebenfalls möglich.

Für die Analyse einer größeren Website lohnt es sich deshalb, zu kombinieren:

• PageSpeed Insights,
• Chrome DevTools,
• Lighthouse,
• Search Console,
• CrUX-Daten,
• eigenes Real User Monitoring.

25. Versuchen Sie nicht um jeden Preis, 100/100 zu erreichen

PageSpeed ist ein Diagnosewerkzeug und kein Geschäftsziel.

Man kann mehrere Dutzend Stunden darauf verwenden, den Wert von 96 auf 100 zu heben, ohne dem Nutzer eine spürbare Verbesserung zu bringen.

Gleichzeitig kann eine Verbesserung des LCP von 5 Sekunden auf 2 Sekunden sehr viel bewirken, auch wenn das endgültige Lighthouse-Ergebnis weiterhin nicht perfekt ist.

Deshalb sollten die Prioritäten ungefähr so aussehen:

1. schwerwiegende Probleme der Nutzererfahrung beseitigen,
2. Core Web Vitals verbessern,
3. technische Bottlenecks beseitigen,
4. die größten Ressourcen optimieren,
5. und erst danach die Kosmetik des Ergebnisses angehen.

Wie sieht ein sinnvoller Prozess der WordPress-Optimierung aus?

Statt mehrere Plugins gleichzeitig zu installieren, lohnt es sich, den Prozess Schritt für Schritt zu durchlaufen.

Schritt 1. Messung

Prüfen Sie:

• PageSpeed für Mobil und Desktop,
• Core Web Vitals,
• TTFB,
• den Waterfall der Requests,
• die Transfergröße,
• die Menge an JavaScript,
• die Menge an CSS,
• das LCP-Element.

Schritt 2. Bestimmen Sie das größte Problem

Liegt die Beschränkung bei:

• dem Backend,
• dem LCP-Bild,
• CSS,
• JavaScript,
• externen Skripten,
• Schriften,
• der HTML-Struktur?

Verbessern Sie nicht alles gleichzeitig.

Schritt 3. Ändern Sie einen Bereich

Zum Beispiel:

• den Cache konfigurieren,
• das Hero-Image optimieren,
• unnötiges JS entfernen,
• den TTFB verbessern.

Schritt 4. Messen Sie erneut

Prüfen Sie, ob die Änderung tatsächlich einen Effekt hatte.

Schritt 5. Kontrollieren Sie die Nebenwirkungen

Zur Optimierung gehören auch funktionale Tests.

Nach den Änderungen müssen Sie unter anderem prüfen:

• Formulare,
• Menüs,
• Popups,
• den Warenkorb,
• den Checkout,
• das Einloggen,
• Zahlungen,
• das Tracking.

Ein Ergebnis von 100/100 hat keinerlei Wert, wenn nach der Optimierung der Checkout nicht mehr funktioniert.

Fazit

Die Optimierung von WordPress besteht nicht darin, in Google PageSpeed Insights eine einzige magische Einstellung zu finden.

Gute Performance entsteht aus vielen Elementen, die zusammenwirken:

• einem schnellen Backend,
• dem passenden Cache,
• einer vernünftigen Menge an CSS und JavaScript,
• optimierten Bildern,
• korrektem Laden der Schriften,
• der Begrenzung externer Skripte,
• einer guten HTML-Struktur,
• einer passenden Serverkonfiguration.

PageSpeed Insights ist ein sehr guter Startpunkt, denn es hilft, potenzielle Probleme zu finden. Es sollte jedoch nicht wie ein Automat behandelt werden, der sagt, was unbedingt geändert werden muss.

Am wichtigsten bleibt der echte Nutzer.

Wenn die Seite den wichtigsten Inhalt schnell zeigt, sofort auf Interaktionen reagiert, während des Ladens keine Elemente verschiebt und auch auf Mobilgeräten stabil läuft, erfüllt die Optimierung ihren Zweck.

Und ein hoher PageSpeed-Wert der Seite ist dann die Folge einer gut gebauten, schnellen Website und kein Ziel für sich.