Zum Inhalt springen
Performance

WordPress Performance: So erreichen Sie Lighthouse 90+

Eine typische WordPress-Website erreicht auf Mobile einen Lighthouse-Score von 40–65. Mit den richtigen Architektur-Entscheidungen sind 90+ realistisch, ohne auf Funktionalität zu verzichten. Hier zeigen wir die konkreten Techniken aus unserer täglichen Arbeit.

Von Dennis Theis · · 10 Min. Lesezeit

Daten-Dashboard mit Performance-Metriken und Grafiken

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. Wer am falschen Ende anfängt, verschwendet Zeit:

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

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

1. Architektur: Kein Page Builder, Custom Blocks

Der wichtigste Performance-Hebel: kein Elementor, kein WPBakery, kein Divi. Stattdessen nutzen wir Custom Gutenberg Blocks mit Timber/Twig. 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. Unsere 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 typischerweise für 60–70% des Seitengewichts verantwortlich. Unsere Strategie:

  • WebP/AVIF-Konvertierung: Automatisch über das Theme, 30–50% kleiner als JPEG
  • 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. Wir hosten alle Fonts lokal als WOFF2-Dateien mit folgender Konfiguration:

  • font-display: swap: Text ist sofort sichtbar, auch wenn der Font noch lädt
  • Subsetting: Nur Latin-Glyphen, reduziert die Dateigröße um 60–80%
  • 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 Core lädt standardmäßig jQuery, wp-embed und diverse Inline-Scripts. Unser Ansatz:

  • 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 der zweitwichtigste Hebel nach der Architektur:

  • 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 3× schneller als PHP 7.4, und sicherer. 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 erreichen unsere WordPress-Projekte konsistent diese Werte:

Lighthouse-Ergebnisse (Mobile, Durchschnitt)
Metrik Typische WP-Seite Unser Stack
Performance45–6590–98
LCP3.5–6.0s< 2.0s
CLS0.15–0.35< 0.05
Total JavaScript400–800 KB30–80 KB

WP Rocket allein wird Sie 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.