WordPress-Geschwindigkeitsoptimierung, kompletter WPO-Leitfaden | WPPoland

Mariusz Szatkowski

Umfassende WordPress-Optimierung, wie beschleunigt man die Seite? (WPO)

Zuletzt überprüft: 12. Oktober 2026

17 Min. Lesezeit

Leitfaden

500+ WP-Projekte

“Mein WordPress ist langsam”. Diesen Satz habe ich tausendmal gehört. Und normalerweise ist die Antwort nicht “installiere noch ein Plugin”, sondern “räum auf, was du hast”. Performance-Optimierung (WPO, Web Performance Optimization) läuft über Datenbankabfragen, PHP-Laufzeit, Cache-Fronten, CDN und Assets gleichzeitig. Bilder zu komprimieren reicht nicht, wenn die Datenbank bei jeder Abfrage “hustet”.

Hier ist eine komplette WordPress-Optimierungs-Roadmap, von den Grundlagen bis zu fortgeschrittenen Techniken. Sie führt durch jede Schicht, von der Serverkonfiguration bis zum letzten Paint auf dem Bildschirm, mit echten Zahlen und Code, den du sofort einsetzen kannst.

Mehr über unsere Leistungen in der WordPress-Entwicklung erfährst du bei WPPoland.

#Wie sich die WordPress-Ladezeit auf Conversions auswirkt

Ladezeit ist eine Geschäftskennzahl. Laut Googles eigener Forschung steigt die Absprungwahrscheinlichkeit um 32 %, wenn die Ladezeit einer Seite von 1 auf 3 Sekunden wächst. Bei 5 Sekunden springt sie auf 90 %. Für E-Commerce hat Amazon gemessen, dass jede zusätzliche Latenz von 100 ms 1 % Umsatz gekostet hat (Greg Linden, Amazon, 2006).

Core Web Vitals sind seit 2021 ein bestätigtes Rankingsignal von Google. Seiten, die alle drei Schwellenwerte erreichen (LCP unter 2,5 Sekunden, CLS unter 0,1 und INP unter 200 ms), bekommen in der mobilen Suche einen Rankingvorteil. Nach Daten des Chrome User Experience Report (CrUX) von Ende 2025 bestehen nur 43 % der WordPress-Origins alle drei Core Web Vitals auf Mobilgeräten. Mehr als die Hälfte der WordPress-Seiten verschenkt also Rankingpotenzial.

Die Deloitte-Studie “Milliseconds Make Millions” hat ergeben, dass eine um 0,1 Sekunden schnellere mobile Seite die Conversion-Rate im Einzelhandel um 8,4 % und bei Reiseseiten um 10,1 % erhöht hat. Rechnest du das mit deinem eigenen Traffic durch, werden die Kosten einer langsamen Seite greifbar. Ein WooCommerce-Shop mit 50.000 € Umsatz im Monat kann jeden Monat 4.000 bis 5.000 € verlieren, wenn die Seite in 4 statt in 2 Sekunden lädt.

Denk dran: Eine schnelle Seite ist kein Selbstzweck. Sie ist ein Werkzeug für höhere Konversion und besseres SEO. Jede 100ms Verzögerung kostet dich verlorene Kunden.

Geschwindigkeitsoptimierung ist die technische Investition mit dem höchsten ROI, die du machen kannst.

#Wie man die Geschwindigkeit einer WordPress-Seite misst

Fang nie ohne Ausgangswerte mit der Optimierung an. Du brauchst Daten, keine Vermutungen.

PageSpeed Insights (PSI) liefert dir Labordaten (Lighthouse) und Felddaten (CrUX). Labordaten helfen beim Debuggen, aber für das Ranking nutzt Google die Felddaten, die 28 Tage lang bei echten Chrome-Nutzern gesammelt werden. Sieh dir immer die “Origin Summary” an, damit du weißt, wie deine ganze Domain abschneidet und nicht nur einzelne Seiten.

WebPageTest (webpagetest.org) bietet Wasserfalldiagramme, Filmstreifen-Ansichten und mehrstufige Tests. Teste von einem Standort aus, der nahe an deiner Zielgruppe liegt. Mit der “Repeat View” siehst du, wie sich Caching auf die folgenden Ladevorgänge auswirkt. Das Wasserfalldiagramm ist das beste Diagnosewerkzeug, um langsame Drittanbieter-Skripte und render-blockierende Ressourcen zu finden.

Im Performance-Tab der Chrome DevTools zeichnest du einen kompletten Seitenaufruf auf und prüfst jeden Frame, jede Layoutverschiebung und jeden Long Task. Mit dem Tab “Coverage” (Strg+Umschalt+P, dann “Coverage” eingeben) findest du ungenutztes CSS und JavaScript. So erkennst du Kandidaten, die du entfernen oder später laden kannst.

CrUX Vis (cruxvis.withgoogle.com) zeigt historische Trenddaten aus der CrUX History API. Google hat das ältere CrUX Dashboard in Looker Studio abgekündigt und verweist auf CrUX Vis. Verfolge deine Core Web Vitals über die Zeit, denn ein einzelner Wert sagt ohne Kontext nichts. Richte mit Werkzeugen wie SpeedCurve oder Calibre ein automatisches Monitoring ein, damit du Verschlechterungen bemerkst, bevor sie in Produktion gehen.

Halte deine Ausgangswerte fest: TTFB, LCP, CLS, INP, Gesamtgewicht der Seite und Anzahl der Requests. Ohne diese Zahlen kannst du nicht belegen, dass deine Optimierungen gewirkt haben.

#WordPress-Hosting, DNS und Server auf Geschwindigkeit optimieren

Wenn dein Server langsam antwortet (TTFB > 600ms), hilft kein Plugin. Die Time to First Byte (TTFB) sollte bei gecachten Seiten unter 200 ms und bei dynamischen Antworten unter 600 ms liegen.

PHP-Version: PHP 8.3 oder neuer, so lautet die Empfehlung von WordPress.org.
Datenbank: MySQL 8.0 oder neuer oder MariaDB 10.11 oder neuer.
Protokoll: HTTP/2 oder HTTP/3 (QUIC) ist ein Muss. Erlaubt dem Browser, viele Dateien gleichzeitig über eine Verbindung herunterzuladen.

#Welche PHP-Version für WordPress am schnellsten ist

WordPress.org empfiehlt PHP 8.3 oder neuer. PHP 8.1 und ältere Zweige bekommen keine Sicherheitsupdates mehr, wer dort stehen bleibt, verliert also Tempo und Sicherheit zugleich. Wie viel schneller eine konkrete Seite nach dem Update wird, hängt von Theme, Plugins und Caching ab. Miss deshalb die TTFB vor und nach dem Wechsel, statt einem pauschalen Faktor zu glauben. Prüf deine PHP-Version mit phpinfo() oder unter Werkzeuge, Website-Zustand, Bericht, und teste das Update zuerst auf Staging: alte Plugins sind die übliche Quelle für Fatal Errors nach einem PHP-Sprung.

#OPcache für WordPress konfigurieren

OPcache kompiliert PHP-Skripte in Bytecode und legt ihn im Shared Memory ab. Aktiviere es und stelle diese Werte in der php.ini ein:

opcache.enable=1
opcache.memory_consumption=256
opcache.max_accelerated_files=20000
opcache.revalidate_freq=60
opcache.jit=1255
opcache.jit_buffer_size=128M

Die Einstellung jit=1255 aktiviert in PHP 8.x den Tracing-JIT, der CPU-lastigen Vorgängen wie dem Aufbau von Seiten zugutekommt.

#Object Caching mit Redis oder Memcached

WordPress speichert Transients, Abfrageergebnisse und Sitzungsdaten standardmäßig in der Tabelle wp_options. Redis oder Memcached verlagern das in den Arbeitsspeicher und senken die Zahl der Datenbankabfragen deutlich. Eine typische WordPress-Seite mit 50 bis 80 Datenbankabfragen kommt mit einem persistenten Object Cache auf 5 bis 10. Installiere die PHP-Erweiterung redis, trage WP_REDIS_HOST in die wp-config.php ein und nutze ein Drop-in wie object-cache.php aus dem Plugin Redis Object Cache.

#HTTP/2, HTTP/3 und ein CDN für WordPress

Mit dem Multiplexing von HTTP/2 lädt der Browser Dutzende Assets über eine einzige Verbindung, das alte Head-of-Line-Blocking von HTTP/1.1 fällt weg. HTTP/3 (QUIC) geht weiter: Der Verbindungsaufbau braucht keinen zusätzlichen Round Trip, und Paketverluste werden besser abgefangen. Cloudflare, Fastly und AWS CloudFront unterstützen HTTP/3 heute alle.

CDN (Content Delivery Network): Wenn du Traffic aus aller Welt hast, nutze Cloudflare, um Dateien vom nächstgelegenen Server auszuliefern. Für jede Seite mit internationalem Traffic gehört ein CDN zur Pflicht. Lege deine statischen Assets (Bilder, CSS, JS, Fonts) auf Edge-Server. Für WordPress konfigurierst du das CDN so, dass es komplette HTML-Seiten für nicht eingeloggte Besucher cacht. Das allein kann die TTFB weltweit unter 50 ms drücken.

Shared Hosting ist der Engpass, den wir bei wppoland.com am häufigsten sehen. Überlastete Server, veraltete PHP-Versionen und fehlende Unterstützung für Object Cache machen Performance-Optimierung fast unmöglich. Wechsle zu Managed WordPress Hosting oder auf einen VPS mit sauber konfiguriertem NGINX oder LiteSpeed.

#Backend und Datenbank von WordPress optimieren

Hier passiert die “Magie”, die man nicht sieht, aber spürt, wenn man im Admin-Panel arbeitet. WordPress-Datenbanken sammeln mit der Zeit Müll an. Beitragsrevisionen, verwaiste Metadaten, abgelaufene Transients und Spam-Kommentare blähen die Tabellen auf und bremsen Abfragen.

#Revisionen, Transients und Autoload bereinigen

Revisionen: WordPress behält standardmäßig unendliche Versionen jedes Beitrags. Wenn du einen Beitrag 100 mal bearbeitest, hast du 100 Kopien in der Datenbank. Begrenze dies in wp-config.php:

define( 'WP_POST_REVISIONS', 5 );
define( 'EMPTY_TRASH_DAYS', 14 );

Transients: Bereinige alte “Transients” (temporäre Daten) aus der Datenbank. Plugins hinterlassen dort oft Müll, weil sie abgelaufene Einträge nicht selbst wegräumen. Mit dieser SQL-Abfrage siehst du, wie viele automatisch geladene Optionen du mitschleppst:

SELECT SUM(LENGTH(option_value)) AS autoload_size
FROM wp_options
WHERE autoload = 'yes';

Liegt das Ergebnis über 1 MB, hast du ein Problem. Die schwersten Zeilen findest du mit:

SELECT option_name, LENGTH(option_value) AS size
FROM wp_options
WHERE autoload = 'yes'
ORDER BY size DESC
LIMIT 20;

Typische Verursacher sind Einstellungen verlassener Plugins, serialisierte Widget-Daten und aufgeblähte Theme-Optionen. Entferne, was du nicht brauchst.

#Heartbeat API drosseln

Heartbeat API: Begrenze den WordPress-”Puls” (Autosave, Admin-Benachrichtigungen) mit dem “Heartbeat Control” Plugin, um die Server-CPU zu entlasten.

#Langsame Datenbankabfragen in WordPress finden

Mit dem Plugin Query Monitor findest du langsame Datenbankabfragen beim Laden einer Seite. Achte auf Abfragen ohne passende Indizes, auf Abfragen innerhalb von Schleifen (das N+1-Problem) und auf Abfragen, die Daten laden, die nie angezeigt werden. Für eigene Abfragen nutzt du immer WP_Query mit gezielten fields, posts_per_page und no_found_rows => true, wenn du keine Paginierung brauchst:

$query = new WP_Query( [
    'post_type'      => 'product',
    'posts_per_page' => 10,
    'no_found_rows'  => true,
    'fields'         => 'ids',
] );

Der Parameter no_found_rows überspringt den teuren Aufruf SQL_CALC_FOUND_ROWS, was die Abfragezeit bei großen Tabellen halbieren kann.

#WP-Optimize oder manuelle Datenbankbereinigung

WP-Optimize ist ein solides Plugin für die geplante Bereinigung von Revisionen, Entwürfen, Beiträgen im Papierkorb, Spam-Kommentaren und Transients. Wenn du volle Kontrolle brauchst, kombinierst du eine manuelle SQL-Bereinigung mit geplanten wp-cron-Ereignissen. Wichtig ist die Regelmäßigkeit: Pflege die Datenbank jede Woche und nicht einmal im Jahr, wenn etwas kaputtgeht.

#Bilder in WordPress optimieren

Bilder sind der größte einzelne Posten im Seitengewicht: Laut Web Almanac 2025 machen sie rund 37 % der mittleren mobilen Seite aus. Ihre Optimierung bringt die größte einzelne Verbesserung der Ladezeit.

#WebP oder AVIF für WordPress-Bilder

WebP liefert bei gleicher visueller Qualität 25 bis 35 % kleinere Dateien als JPEG. AVIF geht weiter und ist bei Fotos 30 bis 50 % kleiner als WebP. WebP wird inzwischen praktisch überall unterstützt (98 %+ weltweit). Die Unterstützung für AVIF liegt bei etwa 92 % und steigt.

Echter Vergleich der Dateigrößen aus einem Projekt von wppoland.com:

Format	Dateigröße	Qualität
JPEG (Original)	285 KB	Ausgangswert
WebP	192 KB	Optisch identisch
AVIF	128 KB	Optisch identisch

Allein der Formatwechsel spart 55 %. Multipliziere das mit 40 Bildern auf einer Seite, und du sparst Megabytes.

#Responsive Bilder und Lazy Loading

WordPress erzeugt beim Upload mehrere Bildgrößen. Nutze die Attribute srcset und sizes, damit der Browser das Bild in passender Größe lädt. Seit WordPress 5.5 wird loading="lazy" automatisch an Bilder gehängt. Bei Hero-Bildern im sichtbaren Bereich entfernst du Lazy Loading, damit sich LCP nicht verzögert:

add_filter( 'wp_img_tag_add_loading_attr', function( $value, $image, $context ) {
    if ( str_contains( $image, 'hero-image' ) ) {
        return false; // Lazy Loading für das Hero-Bild deaktivieren
    }
    return $value;
}, 10, 3 );

#Bild-CDNs für WordPress

Dienste wie Cloudflare Images, imgix und Bunny Optimizer verarbeiten Bilder direkt am Edge: Sie skalieren sie, wandeln sie in WebP oder AVIF um und entfernen Metadaten. Damit musst du auf deinem Server nicht Dutzende Thumbnail-Größen erzeugen. Setze fetchpriority="high" auf das LCP-Bild, damit der Browser seinen Download vorzieht:

<img src="hero.webp" fetchpriority="high" width="1200" height="630"
     alt="WordPress performance optimization dashboard">

#Hotlinking blockieren

Hotlinking blockieren: Lass andere Seiten nicht deine Bandbreite stehlen, indem sie deine Bilder auf ihren Seiten anzeigen.

#Render-blockierendes CSS und JavaScript in WordPress entfernen

Hier kämpfen wir um PageSpeed Insights Score und Core Web Vitals. Render-blockierende Ressourcen sind die häufigste Ursache für schlechte LCP-Werte. Der Browser kann keine Pixel zeichnen, bevor er alles synchrone CSS und JavaScript im <head> verarbeitet hat.

Minifikation: Entferne unnötige Leerzeichen und Kommentare aus CSS/JS/HTML. (Plugins wie Autoptimize oder WP Rocket machen das).
Defer JS: Verschiebe JavaScript-Laden ans Ende (nach HTML-Laden), damit es das Seiten-Rendering nicht blockiert.

#Nicht kritisches CSS asynchron laden

Hol nicht kritisches CSS aus dem <head> und lade es asynchron:

<link rel="preload" href="/css/below-fold.css" as="style"
      onload="this.onload=null;this.rel='stylesheet'">
<noscript><link rel="stylesheet" href="/css/below-fold.css"></noscript>

Bei JavaScript nutzt du defer für Skripte, die Zugriff auf das DOM brauchen, und async für unabhängige Skripte wie Analytics:

add_filter( 'script_loader_tag', function( $tag, $handle ) {
    $defer_scripts = [ 'comment-reply', 'contact-form', 'analytics' ];
    if ( in_array( $handle, $defer_scripts, true ) ) {
        return str_replace( ' src=', ' defer src=', $tag );
    }
    return $tag;
}, 10, 2 );

#Critical CSS inline einbinden

Zieh das CSS heraus, das für den sichtbaren Bereich nötig ist, und binde es direkt im <head> ein. Werkzeuge wie Critical (von Addy Osmani) oder der Critical-CSS-Generator von WP Rocket automatisieren das. Das eingebundene CSS sollte unter 14 KB bleiben (die Größe des Congestion Window beim ersten TCP-Round-Trip). So kann der Browser schon mit der ersten Serverantwort sinnvollen Inhalt darstellen.

#Ungenutztes CSS mit PurgeCSS entfernen

Mit PurgeCSS oder UnCSS analysierst du die gerenderten Seiten und entfernst ungenutzte CSS-Regeln. Eine typische WordPress-Seite mit Page Builder lädt 300 bis 500 KB CSS, davon bleiben auf einer bestimmten Seite 70 bis 80 % ungenutzt. Nach dem Bereinigen:

# Beispielkonfiguration für PurgeCSS
purgecss --css ./style.css \
         --content ./**/*.php ./**/*.html \
         --output ./style.purged.css

Nach sauberem Tree Shaking sehen wir regelmäßig, wie CSS-Dateien von 400 KB auf unter 60 KB schrumpfen. Kombiniere das mit Minifikation (cssnano) und Brotli-Kompression, um möglichst viel zu sparen.

#Skripte und Styles von Plugins per Dequeue abschalten

Viele Plugins laden ihre Assets auf jeder Seite, auch dort, wo sie niemand braucht. Schalte sie gezielt ab:

add_action( 'wp_enqueue_scripts', function() {
    if ( ! is_page( 'contact' ) ) {
        wp_dequeue_style( 'contact-form-7-css' );
        wp_dequeue_script( 'contact-form-7-js' );
    }
}, 100 );

#Caching-Ebenen in WordPress vom CDN bis zum Browser

Caching ist die wirksamste Performance-Technik, weil es Arbeit komplett einspart. Eine durchdachte Caching-Strategie arbeitet in Ebenen.

#Page Cache

Speichere die fertig gerenderte HTML-Ausgabe, damit WordPress und PHP nicht bei jedem Request laufen. Der FastCGI-Cache von NGINX, LiteSpeed Cache oder Plugin-Lösungen wie WP Super Cache und WP Rocket liefern nicht eingeloggten Besuchern statisches HTML aus. Eine Seite, deren dynamische Erzeugung 800 ms dauert, kommt aus dem Cache in 10 ms.

#Object Cache

Redis oder Memcached halten die Ergebnisse von Datenbankabfragen, API-Aufrufen und berechneten Werten im Arbeitsspeicher. Der persistente Object Cache ist die wirksamste Cache-Ebene für eingeloggte Nutzer und dynamische Seiten, die sich nicht komplett per Page Cache abdecken lassen.

#Cache-Control-Header für statische Assets

Setze passende Cache-Control-Header für statische Assets. Unveränderliche Assets (versionierte CSS- und JS-Dateien) sollten lange gecacht werden:

location ~* \.(css|js|woff2|avif|webp|jpg|png|svg)$ {
    expires 1y;
    add_header Cache-Control "public, immutable";
}

Für HTML-Seiten nutzt du kürzere Cache-Zeiten oder stale-while-revalidate, um Aktualität und Geschwindigkeit auszubalancieren:

Cache-Control: public, max-age=300, stale-while-revalidate=86400

#CDN-Cache

Dein CDN sollte statische Assets an Edge-Standorten auf der ganzen Welt cachen. Richte das Leeren des Caches so ein, dass es bei Inhaltsänderungen automatisch ausgelöst wird. Cloudflare APO (Automatic Platform Optimization) für WordPress cacht komplette HTML-Seiten am Edge und leert den Cache automatisch, wenn du Inhalte veröffentlichst oder aktualisierst.

Die Ebenen greifen in dieser Reihenfolge: CDN-Edge-Cache, dann Page Cache auf dem Server, dann Object Cache, dann Browser-Cache. Jede Ebene fängt ab, was die vorherige durchlässt.

#Webfonts in WordPress schneller laden

Webfonts bremsen oft unbemerkt. Ein einziger Request an Google Fonts kann den kritischen Rendering-Pfad um 200 bis 500 ms verlängern, wegen DNS-Lookup, Verbindungsaufbau und Download von einem fremden Origin. Lade Google Fonts lokal oder nutze font-display: swap, damit Text sofort sichtbar ist, bevor die schöne Schrift lädt.

#Fonts in WordPress selbst hosten

Lade die Fontdateien herunter und liefere sie von deiner eigenen Domain aus. Damit entfällt der Aufwand für die Verbindung zum Drittanbieter, und dein CDN kann die Dateien cachen. Nutze ausschließlich das Format woff2: Es wird von über 99 % der Browser unterstützt und komprimiert am besten.

@font-face {
    font-family: 'Inter';
    src: url('/fonts/inter-var.woff2') format('woff2');
    font-weight: 100 900;
    font-display: swap;
    unicode-range: U+0000-024F; /* Lateinische Teilmenge */
}

#font-display swap und Preload für Fonts nutzen

Die Angabe font-display: swap sagt dem Browser, dass er Text sofort in einer Ersatzschrift zeigen und dann zur eigenen Schrift wechseln soll, sobald sie geladen ist. Das verhindert unsichtbaren Text (FOIT) und verbessert LCP.

Lade deine Hauptschrift per Preload vor, damit ihr Download Vorrang bekommt:

<link rel="preload" href="/fonts/inter-var.woff2" as="font"
      type="font/woff2" crossorigin>

#Variable Fonts und Subsetting

Variable Fonts enthalten mehrere Schriftstärken und Stile in einer Datei. Statt einzelne Dateien für Regular (400), Medium (500), Semibold (600) und Bold (700) zu laden, deckt eine variable Fontdatei den ganzen Bereich ab. Die variable Inter ist als woff2 97 KB groß, gegenüber 180 KB für 4 einzelne statische Dateien.

Reduziere deine Fonts auf die Zeichenbereiche, die du wirklich brauchst. Eine Teilmenge nur mit lateinischen Zeichen kann die Datei um 40 bis 60 % gegenüber voller Unicode-Abdeckung verkleinern. Werkzeuge wie glyphhanger oder der Parameter &text= der Google Fonts API machen das einfach.

#LCP, CLS und INP in WordPress verbessern

Die Core Web Vitals von Google sind die drei Metriken, die sich direkt auf dein Suchranking auswirken. Wenn du weißt, warum jede einzelne scheitert, kannst du gezielt optimieren.

#LCP verbessern

LCP misst, wie schnell das größte sichtbare Element (meist ein Hero-Bild oder eine Überschrift) dargestellt wird. Das Ziel liegt unter 2,5 Sekunden.

Häufige Ursachen für schlechte LCP-Werte:

Langsame Serverantwort (hohe TTFB)
Render-blockierendes CSS und JavaScript
Nicht optimierte Hero-Bilder ohne fetchpriority="high"
LCP-Bilder mit Lazy Loading (entferne loading="lazy" bei Bildern im sichtbaren Bereich)
Webfonts, die das Rendern von Text blockieren

Verbessere LCP, indem du die TTFB per Caching senkst, Critical CSS inline einbindest, das LCP-Bild per Preload lädst und fetchpriority="high" auf das Hero-Element setzt.

#CLS senken

CLS misst die visuelle Stabilität, also wie stark sich das Layout beim Laden unerwartet verschiebt. Das Ziel liegt unter 0,1.

Häufige Ursachen für schlechte CLS-Werte:

Bilder und iframes ohne explizite Attribute width und height
Dynamisch eingefügte Inhalte (Werbung, Embeds, Cookie-Banner)
Webfonts, die Text neu umbrechen lassen (FOUT)
Spät geladenes CSS, das die Maße von Elementen ändert

Gib Medienelementen immer Abmessungen. Nutze aspect-ratio in CSS für responsive Container. Reserviere Platz für Werbung und dynamische Inhalte mit Platzhaltern über min-height.

#INP verbessern

INP hat im März 2024 FID abgelöst und misst die Reaktionsfähigkeit über die gesamte Lebensdauer der Seite, nicht nur bei der ersten Interaktion. Das Ziel liegt unter 200 ms.

Häufige Ursachen für schlechte INP-Werte:

Lange JavaScript-Tasks, die den Main Thread blockieren
Schwere Event-Handler für Klick-, Scroll- oder Eingabe-Events
Zu großes DOM (über 1.500 Knoten)
Drittanbieter-Skripte, die um Zeit auf dem Main Thread konkurrieren

Zerlege lange Tasks mit requestIdleCallback oder scheduler.yield() in kleinere Stücke. Nutze Event Delegation, statt Listener an Hunderte einzelner Elemente zu hängen. Prüfe Drittanbieter-Skripte streng: Jedes Skript, das du entfernst, gibt dem Main Thread Zeit zurück.

// Lange Tasks mit Yield-Punkten aufteilen
async function processItems(items) {
    for (const item of items) {
        processItem(item);
        // Zwischen den Einträgen an den Browser abgeben
        await scheduler.yield();
    }
}

#Checkliste für die WordPress-Geschwindigkeitsoptimierung

Nutze diese Checkliste Schritt für Schritt in jedem WordPress-Projekt. Die Reihenfolge zählt: Fang beim Server an und arbeite dich nach außen bis zum Browser vor.

#Serverebene

Auf PHP 8.3+ mit aktiviertem OPcache und JIT aktualisieren
MySQL/MariaDB mit passender Buffer-Pool-Größe konfigurieren
HTTP/2 aktivieren (oder HTTP/3, falls unterstützt)
Redis oder Memcached für Object Caching einrichten
Von Shared Hosting zu Managed Hosting oder auf einen VPS wechseln

#Datenbankebene

Beitragsrevisionen auf 5 begrenzen
Abgelaufene Transients und verwaiste Metadaten löschen
Automatisch geladene Optionen prüfen (unter 800 KB halten)
Indizes für eigene Meta-Abfragen anlegen

#Asset-Ebene

Bilder mit passenden Fallbacks in WebP/AVIF umwandeln
width, height und fetchpriority="high" für LCP-Bilder setzen
loading="lazy" bei Bildern im sichtbaren Bereich entfernen
Fonts im Format woff2 mit font-display: swap selbst hosten
Wichtige Fonts und LCP-Bilder per Preload laden

#Code-Ebene

Critical CSS inline einbinden (unter 14 KB)
Alles nicht kritische JavaScript mit defer oder async laden
Ungenutztes Plugin-CSS/JS auf Seiten ohne Bedarf per Dequeue abschalten
Ungenutztes CSS mit PurgeCSS per Tree Shaking entfernen
Alle Assets minifizieren und mit Brotli komprimieren

#Cache-Ebene

Full-Page-Caching für nicht eingeloggte Besucher aktivieren
CDN mit passenden Cache-Headern konfigurieren
Cache-Control: immutable für versionierte statische Assets setzen
stale-while-revalidate für HTML-Antworten einsetzen

#Monitoring

Trends der 28-Tage-Felddaten in CrUX Vis verfolgen
Core Web Vitals in der Search Console überwachen
Lighthouse CI in der Deployment-Pipeline laufen lassen
Performance-Budgets festlegen (Seitengewicht, Zahl der Requests, LCP-Ziel)

Performance-Optimierung hört nach dem ersten Durchgang nicht auf, sie ist laufende Praxis. Jedes neue Plugin, jedes Theme-Update und jedes Drittanbieter-Skript kann die Seite wieder langsamer machen. Miss fortlaufend, optimiere systematisch und behandle Geschwindigkeit von Anfang an als Kernfunktion deines Produkts.

Caching, Bildformate, Hotlink-Schutz und CDN wirken erst zusammen, einzeln verpufft fast jede Maßnahme. Diese Kette nehmen wir uns in der Performance-Arbeit an WordPress der Reihe nach vor.