WordPress Performance: Lighthouse 90+

Warum sind WordPress-Seiten so langsam?

WordPress selbst ist nicht langsam. Das Problem sind die Schichten, die darauf gestapelt werden: Page Builder (Elementor allein lädt 500+ KB JavaScript), zu viele Plugins, unoptimierte Bilder, externe Fonts von Google CDN und fehlende Caching-Konfiguration.

Dazu kommt: WordPress rendert jede Seite dynamisch aus der Datenbank, bei jedem Aufruf. Ohne Caching bedeutet das Datenbankabfragen, PHP-Ausführung und HTML-Generierung für jeden einzelnen Besucher. Das ist bei einer statischen Unternehmenswebsite völlig unnötig.

Die Performance-Pyramide

Performance-Optimierung hat eine klare Reihenfolge, und wer am falschen Ende anfängt, verschwendet Zeit. Die Basis ist die Architektur: Ein Page Builder, der 500 KB JavaScript mitbringt, lässt sich durch kein Caching-Plugin retten. Darauf folgt das Caching, dann die Assets, also Bilder, Fonts, CSS und JavaScript, danach Hosting und PHP-Version, und erst ganz oben der Feinschliff. Umgekehrt investieren viele Betreiber zuerst in ein Caching-Plugin und wundern sich, warum der Score bei 65 stehen bleibt:

Architektur (größter Impact): Kein Page Builder, schlankes Theme, minimale Plugins
Caching: Page Cache, Object Cache, Browser Cache
Assets: Bilder, Fonts, CSS, JavaScript optimieren
Server: PHP-Version, Hosting-Qualität, CDN
Feintuning: Preload Hints, Critical CSS, Lazy Loading

Ein WP Rocket auf einer Elementor-Seite bringt wenig, wenn die Architektur das eigentliche Problem ist. Deshalb beginne ich bei jedem Projekt ganz oben.

1. Architektur: Kein Page Builder, Custom Blocks

Der wichtigste Performance-Hebel: kein Elementor, kein WPBakery, kein Divi. Stattdessen nutze ich Custom Gutenberg Blocks mit Timber/Twig. Der Unterschied ist strukturell, nicht graduell: Ein Page Builder lädt sein eigenes Framework auf jeder Seite, unabhängig davon, ob die Seite dessen Funktionen nutzt. Custom Blocks liefern nur das Markup, das der jeweilige Block tatsächlich braucht. Das reduziert das JavaScript um den Faktor zehn und macht alle weiteren Schritte überhaupt erst wirksam. Das Ergebnis:

0 KB Builder-JavaScript: kein Framework-Overhead
Semantisches HTML: sauberer DOM, keine 15-Level-Div-Verschachtelung
Block-spezifisches CSS: jeder Block lädt nur sein eigenes CSS, nicht ein globales Stylesheet
Lazy Script Loading: JavaScript pro Block erst bei Bedarf (load:on="visible")

2. Critical CSS: Inline im Head

CSS blockiert das Rendering. Der Browser zeigt nichts an, bis das CSS geladen ist. Meine Lösung: Die kritischen CSS-Layer (reset, base, themes, layout, utilities) werden direkt im <head> ausgegeben. Block-CSS lädt separat und wird automatisch inline gerendert, wenn es unter 20 KB liegt.

Ergebnis: Der First Contentful Paint erfolgt, bevor ein einziges externes CSS-File geladen wurde.

3. Bildoptimierung: WebP, srcset und Aspect Ratios

Bilder sind der größte Einzelposten im Seitengewicht: Auf der medianen Seite entfallen laut HTTP-Archive-Daten für 2025 rund 1.050 KB von etwa 2,8 MB auf Bilder, also gut ein Drittel, mehr als auf JavaScript. Damit sind sie auch der größte Einzelhebel für den LCP. Drei Maßnahmen decken den Großteil ab: WebP statt JPEG spart laut Google-Studie im Median 25 bis 34 Prozent bei vergleichbarer Qualität, srcset liefert kleineren Displays kleinere Dateien, und feste width- und height-Attribute verhindern Layout-Verschiebungen, also CLS. Das Bild im sichtbaren Bereich bekommt loading="eager" und fetchpriority="high", alle anderen loading="lazy". Im Einzelnen:

WebP/AVIF-Konvertierung: Automatisch über das Theme, WebP im Median 25–34% kleiner als JPEG, AVIF noch einmal darunter
srcset + sizes: Der Browser lädt nur die passende Größe, nicht das 4K-Original
Aspect Ratios: Jedes Bild hat width und height, verhindert Layout-Verschiebungen (CLS)
Hero-Bild priorisieren: fetchpriority="high" + loading="eager" auf dem LCP-Element
Below-Fold: loading="lazy" (Standard über den renderImage-Makro)

Alles automatisiert: Ein Entwickler nutzt den renderImage-Makro in Twig, und das Theme kümmert sich um Format-Konvertierung, Responsive Sizes und Lazy Loading.

4. Font-Loading: Lokal und optimiert

Google Fonts über CDN zu laden ist ein DSGVO-Verstoß und kostet Performance. Fonts lokal zu hosten löst deshalb zwei Probleme gleichzeitig. Technisch spart der Wegfall der externen Verbindung einen DNS-Lookup und einen TLS-Handshake zur fremden Domain. Wie viel das am LCP ausmacht, hängt stark von Netz und Gerät ab, messbar ist es fast immer. Entscheidend ist daneben das Format: WOFF2 komprimiert laut W3C im Schnitt rund 30 Prozent besser als WOFF, und ein Preload im Head sorgt dafür, dass die Schrift geladen wird, bevor der Browser sie braucht. Mit font-display: swap bleibt der Text sichtbar, während die Schrift lädt. Meine Konfiguration:

font-display: swap: Text ist sofort sichtbar, auch wenn der Font noch lädt
Subsetting: Nur die Zeichensätze ausliefern, die die Seite wirklich braucht. Bei Schriften mit vielen Sprachschnitten fällt dabei der Großteil der Datei weg
Preload: Kritische Fonts im <head> mit <link rel="preload">
Ähnliche Fallback-Fonts: Minimiert den Layout Shift beim Font-Swap

5. JavaScript: Nur laden was gebraucht wird

WordPress lädt im Auslieferungszustand jQuery, wp-embed und eine Reihe Inline-Scripts, auch auf Seiten, die davon nichts brauchen. Zusammen sind das schnell 100 KB, die den INP-Wert belasten, ohne etwas beizutragen. Der Ansatz ist deshalb nicht Minifizierung, sondern Weglassen: Was eine Seite nicht braucht, wird dort auch nicht eingebunden. Was bleibt, lädt verzögert oder erst bei Interaktion. Konkret:

jQuery deregistrieren: wird durch vanilla JS ersetzt
wp-embed deaktivieren: oEmbed bei Bedarf manuell einbinden
Block-Scripts lazy: Über Custom Elements (<devslab-block>) mit IntersectionObserver
Vite Code Splitting: Shared Dependencies werden in separate Chunks extrahiert

Ergebnis: Initial werden typischerweise unter 50 KB JavaScript geladen, verglichen mit 300–600 KB bei einer typischen WordPress-Installation mit Page Builder.

6. Caching richtig konfigurieren

Caching ist nach der Architektur der zweitwichtigste Hebel, aber es ersetzt sie nicht. Ein Page-Cache liefert fertiges HTML aus, statt PHP und Datenbank bei jedem Aufruf arbeiten zu lassen, und senkt damit vor allem die Server-Antwortzeit, also TTFB. Was er nicht senkt, ist die Menge an JavaScript und CSS, die der Browser danach verarbeiten muss. Deshalb bringt Caching auf einer Page-Builder-Seite deutlich weniger, als die Werbung der Plugins verspricht. Sinnvoll gestaffelt sieht es so aus:

Page Cache (WP Rocket): Generiert statische HTML-Dateien, eliminiert PHP/DB-Aufrufe
Object Cache (Redis): Cacht Datenbankabfragen, die bei jedem Aufruf gleich sind
Browser Cache: Statische Assets (CSS, JS, Bilder) mit langen Cache-TTLs
CDN: Statische Assets über weltweit verteilte Server ausliefern

Wichtig: Caching kaschiert Performance-Probleme. Es löst sie nicht. Zuerst die Architektur optimieren, dann Caching als Turbo obendrauf.

7. Server: PHP 8.2+ und gutes Hosting

PHP 8.2 ist schneller und vor allem sicherer als PHP 7.4, das seit November 2022 keine Sicherheitsupdates mehr bekommt. Beim Tempo sind die Erwartungen oft zu hoch: Auf echten WordPress-Workloads liegt der Zugewinn gegenüber 7.4 je nach Benchmark bei etwa 5 bis 20 Prozent, nicht beim oft zitierten Faktor drei. Der stammt aus dem Sprung von PHP 5.6 auf PHP 7. Das Update lohnt sich trotzdem, aber als Sicherheits- und nicht als Performance-Maßnahme. Dazu ein Hosting-Anbieter mit NVMe-SSDs, HTTP/2 oder HTTP/3, und OPcache aktiviert. Shared Hosting mit 50 anderen Websites auf dem gleichen Server ist für professionelle Websites keine Option.

Ergebnisse aus der Praxis

Mit diesem Stack liegen die WordPress-Projekte, die ich betreue, konsistent im grünen Bereich: Lighthouse Performance zwischen 90 und 98 auf Mobile, LCP unter zwei Sekunden, CLS unter 0,05 und zwischen 30 und 80 KB JavaScript statt der üblichen 400 bis 800. Die Ausgangswerte lagen bei denselben Seiten vorher zwischen 45 und 65. Entscheidend war dabei in keinem Fall ein einzelnes Plugin, sondern die Reihenfolge aus der Pyramide oben:

Lighthouse-Ergebnisse (Mobile, Durchschnitt)
Metrik	Typische WP-Seite	Mein Stack
Performance	45–65	90–98
LCP	3.5–6.0s	< 2.0s
CLS	0.15–0.35	< 0.05
Total JavaScript	400–800 KB	30–80 KB

Diese Werte halten aber nur, wenn sie gehalten werden. Ein Plugin-Update, ein neues Skript im Tracking oder ein unoptimiertes Bild im nächsten Beitrag, und der Score fällt zurück. In meiner WordPress-Wartung gehört die Messung der Core Web Vitals deshalb zu jedem Update-Zyklus, statt einmalig nach dem Relaunch.

WP Rocket allein wird dich nicht retten

Ich muss das so direkt sagen, weil ich es ständig sehe: Ein Kunde kauft WP Rocket für 59 EUR, aktiviert alle Checkboxen, und wundert sich warum der Lighthouse-Score nur von 48 auf 55 gestiegen ist. Caching-Plugins sind wichtig, aber sie lösen Probleme auf der Auslieferungsebene, nicht auf der Architekturebene.

Wenn Elementor 500 KB JavaScript lädt, hilft auch ein Page Cache nicht gegen den schlechten INP. Wenn Bilder ohne width/height eingebunden sind, springt das Layout trotz Caching. Erst die Architektur fixen, dann Caching obendrauf. Das ist die richtige Reihenfolge. Oder gleich ein Relaunch mit dem richtigen Stack.

Quellen

HTTP Archive, Web Almanac 2025: Page Weight (mediane Seite 2,86 MB Desktop, davon rund 1.050 KB Bilder)
Google: WebP Compression Study (WebP im Median 25–34% kleiner als JPEG)
W3C: WOFF File Format 2.0 (rund 30% bessere Kompression als WOFF)
Kinsta: PHP-Benchmarks für WordPress (Zugewinn von PHP 7.4 auf aktuelle 8.x im einstelligen bis niedrigen zweistelligen Prozentbereich)
php.net: Supported Versions (PHP 7.4 seit 28.11.2022 ohne Sicherheitsupdates)

WordPress Performance: So erreichst du Lighthouse 90+