Beim ersten Mal, als ein WooCommerce-Kunde auf Mittwald-LiteSpeed PageSpeed Insights öffnete und neben einem 200 KB Hero-PNG einen LCP von 4,0 s sah, dauerte die Diagnose dreißig Sekunden, der Fix einen Nachmittag. AVIF-Konvertierung plus fetchpriority="high" brachten die Seite auf 1,4 s LCP. Die CSS-Seite war schwieriger: ein 800 KB-Stylesheet aus einem Page-Builder-Theme blockierte das Rendering auf Mobilgeräten, und erst Critical-CSS-Extraktion mit 12 KB inline-Payload zog FCP unter eine Sekunde. Diese beiden Muster wiederholen sich bei fast jeder deutschen WordPress-Site, die wir auditieren.
Dieser Leitfaden geht durch die Pipeline, die Core Web Vitals auf einer deutschen WordPress-Installation tatsächlich bewegt: Format-Wahl zwischen AVIF, WebP und JPEG XL angesichts der aktuellen Browser-Realität (Safari 16+ liefert AVIF aus, Chrome dekodiert JPEG XL nur hinter einer Flag, Firefox hat JPEG XL 2024 auf Eis gelegt); Plugin-Auswahl zwischen ShortPixel, Imagify, Smush und EWWW mit den DPA- und Drittlandstransfer-Eigenheiten, die jede unter DSGVO mitbringt (Imagify-Server in der EU, ShortPixel-Endpunkte teilweise in den USA, EWWW Local-Modus als bequemer DSGVO-Ausweg); die 14 KB-Above-the-Fold-Regel aus TCP slow start und nicht aus einer Marketing-Folie; sowie LiteSpeed-Cache-Einstellungen, die einen messbaren LCP-Delta produzieren und kein Placebo.
Wo LCP- und FCP-Verluste tatsächlich herkommen
Öffnen Sie das Network-Panel bei einer typischen deutschen WordPress-Site bei Mittwald, IONOS oder Webgo, und Sie sehen zwei Schuldige des LCP-Budgets: ein Hero-Bild von 1-2 MB als JPEG oder PNG ausgeliefert und ein Hauptstylesheet von 300-800 KB, das als renderblockierend markiert ist. Der dritte Übeltäter, Webfonts ohne font-display: swap geladen, ist in Bytes kleiner, blockiert aber den Paint, bis sie ankommen.
Das Hero-Bild ist das offensichtliche Ziel, denn LCP ist per Definition das größte sichtbare Element above the fold, und auf den meisten deutschen WordPress-Homepages ist dieses Element ein JPEG. WebP schneidet diese Datei um etwa 25-35% bei gleicher visueller Qualität, AVIF schneidet sie erneut und landet je nach Inhalt oft 40-55% kleiner als das Original-JPEG. AVIF-Unterstützung ist mittlerweile breit: Chrome seit 85, Firefox seit 93, Safari seit 16. JPEG XL ist der laute Abwesende: Chromium hat das Decode-Flag entfernt, Firefox hat es unbefristet geparkt, nur Safari liefert es nativ aus, also ist es für ein deutsches Publikum (laut Heise-Performance-Benchmarks und CrUX-Daten Chrome-dominant) im Jahr 2026 kein Produktionsformat.
Die CSS-Seite ist, wo die 14 KB-Regel zählt. TCP slow start öffnet eine Verbindung mit etwa zehn Paketen, rund 14 KB nach Headern, vor dem ersten ACK-Roundtrip. Inlinen Sie mehr als das in Ihren <head>, und Sie verlängern den ersten Paint um eine volle RTT. Das ist der gesamte Grund, warum Critical-CSS-Extraktoren auf eine 14 KB-Obergrenze zielen und nicht auf eine runde Zahl aus einer Checkliste.
Auswahl des Bildoptimierungs-Plugins
Vier Plugins erledigen den Großteil der Arbeit in der WordPress-Bildoptimierung 2026, und die Wahl zwischen ihnen geht selten allein um Kompressionsqualität. API-Limits, wo die Konvertierung läuft und welche Daten Ihren Server verlassen, zählen unter DSGVO so viel wie die resultierende Dateigröße.
ShortPixel Image Optimizer
ShortPixel komprimiert über seine Cloud-API und liefert WebP plus AVIF standardmäßig. Drei Modi: lossy, glossy, lossless. Auf fotografielastigen Seiten landet das Glossy-Preset üblicherweise innerhalb weniger Prozent visueller Lossless-Qualität bei halben Bytes. Der Haken bei Massendurchläufen ist die API-Rate-Obergrenze: 10 000+ Bilder an einem Tag durch einen kleinen Plan zu drücken löst Throttling aus, und der Bulk-Prozessor weicht zurück, statt sichtbar zu scheitern, was einen stockenden Bulk wie einen kaputten Bulk aussehen lässt. Unter DSGVO: ShortPixel hat eine veröffentlichte Auftragsverarbeitungsvereinbarung, die Endpunkte liegen aber teilweise außerhalb der EU, also gehört der Anbieter ins Verzeichnis der Verarbeitungstätigkeiten.
Wichtigste Stärken:
- AVIF-Generierung in Produktion seit 2023
- Massenverarbeitung mit Hintergrund-Queue
- Glossy-Preset als praktischer Default für Redaktion und E-Commerce
- Preisgestaltung kontingentbasiert und individuell
Imagify
Entwickelt vom Team hinter WP Rocket, integriert sich Imagify nahtlos mit diesem Caching-Plugin. Es bietet drei Kompressionsmodi (normal, aggressiv, ultra) und generiert automatisch WebP-Dateien.
Wichtigste Stärken:
- Tiefe WP Rocket-Integration für kombinierte Optimierung
- Visuelles Vergleichstool zur Vorschau der Kompressionsergebnisse
- Automatische Größenänderung übergroßer Uploads
- WebP-Generierung mit einem Klick
- Preisgestaltung ist kontingentbasiert (individuell, variiert nach Nutzung)
Smush
Smush von WPMU DEV ist die einsteigerfreundlichste Option. Die kostenlose Version bietet grundlegende Kompression und Lazy Loading. Die Pro-Version fügt WebP-Konvertierung, CDN-Auslieferung und aggressivere Optimierung hinzu.
Wichtigste Stärken:
- Kostenlose Stufe mit unbegrenzten Bildern (bis zu 5 MB pro Bild)
- Integriertes Lazy Loading
- CDN inklusive bei Pro
- Verzeichnis-Level-Smush für Bilder außerhalb der Medienbibliothek
- Pro-Preise variieren je nach Plan
EWWW Image Optimizer
EWWW ist das einzige Plugin auf dieser Liste, das vollständig auf dem Server laufen kann, ohne externe API. Das zählt unter DSGVO: kein Drittlandstransfer für hochgeladene Bilder, keine zusätzliche AVV nötig, kein Eintrag im Verarbeitungsverzeichnis für eine SaaS-Bildverarbeitung. Lokaler Modus nutzt jpegoptim, optipng, pngquant und cwebp, die aus PHP heraus aufgerufen werden, also müssen die Binaries auf der Festplatte liegen; bei deutschen Shared-Hostern wie Mittwald oder Webgo ist das ein kurzes Support-Ticket.
Wichtigste Stärken:
- Lokaler Kompressionsmodus ohne Cloud-Roundtrip
- WebP- und AVIF-Konvertierung
- ExactDN-CDN-Option mit Content-Negotiation-Auslieferung
- WP-CLI-Befehle für Cron-gesteuerte Bulk-Läufe
- Preise variieren je nach Modus, lokal ist kostenlos, API-Pläne individuell
Plugin-Vergleich auf einen Blick
| Funktion | ShortPixel | Imagify | Smush | EWWW |
|---|---|---|---|---|
| WebP-Unterstützung | Ja | Ja | Nur Pro | Ja |
| AVIF-Unterstützung | Ja | Nein | Nein | Ja |
| Lokale Kompression | Nein | Nein | Nein | Ja |
| Massenverarbeitung | Ja | Ja | Ja | Ja |
| WP Rocket-Integration | Einfach | Nativ | Nein | Einfach |
| Kostenlose Stufe | 100 Bilder/Mon. | 20 MB/Mon. | Unbegrenzt (eingeschränkt) | Lokaler Modus |
Für die meisten professionellen WordPress-Seiten bieten ShortPixel oder EWWW die beste Kombination aus Formatunterstützung, Kompressionsqualität und Flexibilität.
WebP- und AVIF-Auslieferung konfigurieren
Ein Optimierungs-Plugin zu installieren ist nur die halbe Arbeit. Sie müssen auch sicherstellen, dass Browser tatsächlich das moderne Format anstelle des ursprünglichen JPEG oder PNG erhalten.
Methode 1: Picture-Element-Umschreibung
Der zuverlässigste Ansatz verwendet das HTML-Element <picture>, um mehrere Formate mit automatischem Fallback anzubieten:
<picture>
<source srcset="image.avif" type="image/avif">
<source srcset="image.webp" type="image/webp">
<img src="image.jpg" alt="Beschreibung" width="800" height="600" loading="lazy">
</picture>Die meisten Optimierungs-Plugins übernehmen diese Umschreibung automatisch. ShortPixel und EWWW fügen <picture>-Tags ein, wenn sie entsprechend konfiguriert sind.
Methode 2: Content-Negotiation über .htaccess
Wenn Ihr Server Apache oder LiteSpeed verwendet, können Sie WebP-Dateien transparent mittels Content-Negotiation ausliefern. Der Browser sendet einen Accept-Header mit unterstützten Formaten, und der Server antwortet mit der bestmöglichen Datei:
<IfModule mod_rewrite.c>
RewriteEngine On
# AVIF ausliefern, wenn verfügbar und unterstützt
RewriteCond %{HTTP_ACCEPT} image/avif
RewriteCond %{REQUEST_FILENAME} (.+)\.(jpe?g|png|gif)$
RewriteCond %{REQUEST_FILENAME}.avif -f
RewriteRule (.+)\.(jpe?g|png|gif)$ $1.$2.avif [T=image/avif,E=REQUEST_image,L]
# WebP ausliefern, wenn verfügbar und unterstützt
RewriteCond %{HTTP_ACCEPT} image/webp
RewriteCond %{REQUEST_FILENAME} (.+)\.(jpe?g|png|gif)$
RewriteCond %{REQUEST_FILENAME}.webp -f
RewriteRule (.+)\.(jpe?g|png|gif)$ $1.$2.webp [T=image/webp,E=REQUEST_image,L]
</IfModule>
<IfModule mod_headers.c>
Header append Vary Accept env=REQUEST_image
</IfModule>Dieser Ansatz ist für Ihr HTML unsichtbar und funktioniert mit jedem Theme oder Page Builder.
Methode 3: WordPress-Filter für programmatische Kontrolle
Für Entwickler, die präzise Kontrolle wünschen, können Sie die Bildausgabe auf PHP-Ebene filtern:
<?php
declare(strict_types=1);
add_filter('wp_get_attachment_image_attributes', function (array $attr, WP_Post $attachment): array {
$webp_url = preg_replace('/\.(jpe?g|png)$/i', '.webp', $attr['src']);
$upload_dir = wp_get_upload_dir();
$webp_path = str_replace($upload_dir['baseurl'], $upload_dir['basedir'], $webp_url);
if (file_exists($webp_path)) {
$attr['src'] = $webp_url;
if (isset($attr['srcset'])) {
$attr['srcset'] = preg_replace('/\.(jpe?g|png)/i', '.webp', $attr['srcset']);
}
}
return $attr;
}, 10, 2);WordPress-Bildgrößen aufräumen
WordPress und WooCommerce registrieren standardmäßig zahlreiche Bildgrößen. Jedes hochgeladene Bild erzeugt eine Kopie in jeder registrierten Größe, was Speicherplatz verbraucht und die Massenoptimierung verlangsamt. Nicht benötigte Größen zu entfernen ist ein schneller Gewinn.
Ungenutzte Standardgrößen entfernen
<?php
declare(strict_types=1);
add_action('after_setup_theme', function (): void {
// Nicht benötigte Größen entfernen
remove_image_size('1536x1536');
remove_image_size('2048x2048');
});
add_filter('intermediate_image_sizes_advanced', function (array $sizes): array {
// Nur die Größen behalten, die Ihr Theme tatsächlich verwendet
$remove = ['medium_large'];
foreach ($remove as $size) {
unset($sizes[$size]);
}
return $sizes;
});Nur registrieren, was Sie brauchen
<?php
declare(strict_types=1);
add_action('after_setup_theme', function (): void {
add_image_size('hero-banner', 1200, 630, true);
add_image_size('card-thumb', 400, 300, true);
add_image_size('logo-small', 200, 0, false);
});Maximale Upload-Dimensionen festlegen
Verhindern Sie, dass Benutzer 6000-px-Originale hochladen, die Speicherplatz und Verarbeitungszeit verschwenden:
<?php
declare(strict_types=1);
add_filter('wp_handle_upload', function (array $upload): array {
$max_width = 2400;
$max_height = 2400;
if (!str_starts_with($upload['type'], 'image/')) {
return $upload;
}
$image = wp_get_image_editor($upload['file']);
if (is_wp_error($image)) {
return $upload;
}
$size = $image->get_size();
if ($size['width'] > $max_width || $size['height'] > $max_height) {
$image->resize($max_width, $max_height, false);
$image->save($upload['file']);
}
return $upload;
});Critical CSS und renderblockierende Ressourcen verstehen
Wenn ein Browser eine WordPress-Seite lädt, muss er das vollständige CSS-Stylesheet herunterladen und parsen, bevor er irgendetwas auf dem Bildschirm rendert. Bei einer typischen WordPress-Seite mit einem Page-Builder-Theme kann dieses Stylesheet 300-500 KB CSS umfassen, wovon der Großteil für Elemente unterhalb des sichtbaren Bereichs oder auf ganz anderen Seiten gilt.
Critical CSS löst dies, indem nur die Styles extrahiert werden, die für den sichtbaren Bereich benötigt werden, und diese direkt inline im HTML-<head> eingefügt werden. Das vollständige Stylesheet wird dann asynchron geladen und aus dem kritischen Rendering-Pfad entfernt.
Wie die Critical CSS-Extraktion funktioniert
- Ein Tool rendert die Seite in einem Headless-Browser in einer Standard-Viewport-Größe (typischerweise 1300x900 für Desktop, 375x812 für Mobilgeräte).
- Es identifiziert, welche CSS-Regeln auf Elemente im sichtbaren Bereich angewendet werden.
- Diese Regeln werden extrahiert und minifiziert.
- Das extrahierte CSS wird inline in
<style>-Tags im Dokumenten-Head eingefügt. - Das ursprüngliche Stylesheet wird mit
media="print"geladen und beim Laden aufmedia="all"umgeschaltet.
Manuelles Critical CSS-Vorlademuster
Wenn Sie kein Plugin verwenden, das dies automatisch handhabt, können Sie das Muster mit einem WordPress-Filter implementieren:
<?php
declare(strict_types=1);
add_action('wp_head', function (): void {
$critical_css_file = get_template_directory() . '/critical.css';
if (!file_exists($critical_css_file)) {
return;
}
$critical_css = file_get_contents($critical_css_file);
if ($critical_css === false) {
return;
}
echo '<style id="critical-css">' . $critical_css . '</style>' . "\n";
}, 1);
add_filter('style_loader_tag', function (string $html, string $handle): string {
// Nicht-kritische Stylesheets verzögern
$defer_handles = ['theme-style', 'woocommerce-layout', 'woocommerce-general'];
if (in_array($handle, $defer_handles, true)) {
$html = str_replace(
"media='all'",
"media='print' onload=\"this.media='all'\"",
$html
);
}
return $html;
}, 10, 2);Kritische Assets mit Link-Tags vorladen
Für Ressourcen, die der Browser sofort benötigt, weisen Preload-Hints ihn an, den Download zu starten, bevor er die Ressource natürlich im HTML entdeckt:
<!-- Hero-Bild vorladen -->
<link rel="preload" as="image" href="/wp-content/uploads/hero.webp" type="image/webp">
<!-- Kritische Schriftart vorladen -->
<link rel="preload" as="font" href="/wp-content/themes/theme/fonts/main.woff2"
type="font/woff2" crossorigin>In WordPress fügen Sie diese programmatisch hinzu:
<?php
declare(strict_types=1);
add_action('wp_head', function (): void {
if (!is_front_page()) {
return;
}
$hero_image = get_template_directory_uri() . '/images/hero.webp';
echo '<link rel="preload" as="image" href="' . esc_url($hero_image) . '" type="image/webp">' . "\n";
}, 1);LiteSpeed Cache für WordPress konfigurieren
LiteSpeed Cache ist das schnellste verfügbare WordPress-Caching-Plugin, weil es auf Webserver-Ebene arbeitet und nicht über PHP. Wenn Ihr Host OpenLiteSpeed oder LiteSpeed Enterprise verwendet, kommuniziert dieses Plugin direkt mit der integrierten Cache-Engine des Servers und umgeht PHP vollständig für gecachte Anfragen.
Wesentliche LiteSpeed Cache-Einstellungen
Seiten-Cache (Reiter Cache):
- Cache aktivieren: Ein
- Cache für eingeloggte Benutzer: Aus (es sei denn, Sie haben Mitgliedschaftsinhalte)
- Mobiler Cache: Ein (mit separatem Cache für Mobilgeräte, wenn Ihr Theme unterschiedliches Markup ausliefert)
- TTL: 604800 (7 Tage für statische Seiten), 86400 (1 Tag für häufig aktualisierte Seiten)
Browser-Cache (Reiter Cache):
- Browser-Cache: Ein
- Browser-Cache-TTL: 31557600 (1 Jahr, verlassen Sie sich auf versionierte Dateinamen für Cache-Busting)
Objekt-Cache (Reiter Cache):
- Objekt-Cache: Ein (erfordert Redis oder Memcached auf Ihrem Server)
- Objekt-Cache-TTL: 3600
CSS/JS-Optimierungseinstellungen
Navigieren Sie zu LiteSpeed Cache, dann Optimierung:
- CSS-Minifizierung: Ein
- CSS-Kombinierung: Ein (sorgfältig testen, kann einige Themes beschädigen)
- Critical CSS generieren: Ein
- CSS asynchron laden: Ein
- JS-Minifizierung: Ein
- JS-Kombinierung: Aus (verursacht häufig Probleme, vor dem Aktivieren testen)
- JS verzögern: Ein
- Inline-JS nach DOM-Ready: Ein
Bildoptimierung in LiteSpeed Cache
LiteSpeed Cache enthält einen eigenen Bildoptimierungsdienst über QUIC.cloud:
- Bild-WebP-Ersetzung: Ein
- Bild-Lazy-Load: Ein
- Responsiver Platzhalter: Ein
- Viewport-Bilder (erste N Bilder von Lazy Load ausgenommen): 2-3
LiteSpeed .htaccess-Regeln für Browser-Caching
Fügen Sie diese Regeln zu Ihrer .htaccess für Cache-Header auf Serverebene hinzu:
# LiteSpeed Browser-Cache und Kompression
<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType image/webp "access plus 1 year"
ExpiresByType image/avif "access plus 1 year"
ExpiresByType image/jpeg "access plus 1 year"
ExpiresByType image/png "access plus 1 year"
ExpiresByType image/svg+xml "access plus 1 year"
ExpiresByType text/css "access plus 1 year"
ExpiresByType application/javascript "access plus 1 year"
ExpiresByType font/woff2 "access plus 1 year"
ExpiresByType font/woff "access plus 1 year"
</IfModule>
<IfModule mod_deflate.c>
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/json
AddOutputFilterByType DEFLATE image/svg+xml
AddOutputFilterByType DEFLATE font/woff
</IfModule>
# Sicherheitsheader, die auch die Performance verbessern
<IfModule mod_headers.c>
Header set X-Content-Type-Options "nosniff"
Header set Referrer-Policy "strict-origin-when-cross-origin"
Header set Permissions-Policy "interest-cohort=()"
</IfModule>LiteSpeed Crawler-Konfiguration
Der Crawler hält Ihren Cache warm, indem er Seiten besucht, bevor echte Benutzer es tun:
- Crawler: Ein
- Laufzeit: 200 (Sekunden)
- Intervall zwischen Durchläufen: 600 (Sekunden)
- Crawl-Verzögerung: 500 (Millisekunden)
- Server-Lastlimit: 1
Setzen Sie diese Werte auf Shared Hosting konservativ. Auf einem dedizierten Server oder VPS können Sie die Laufzeit erhöhen und das Intervall verringern.
Ergebnisse mit PageSpeed Insights messen
Optimierung ohne Messung ist Raterei. Google PageSpeed Insights liefert sowohl Labordaten (simulierte Tests) als auch Felddaten (reale Nutzermetriken aus dem Chrome User Experience Report).
Was nach der Optimierung zu prüfen ist
Führen Sie PageSpeed Insights auf Ihren wichtigsten Seiten aus und überprüfen Sie diese Punkte:
Bestandene Audits (grün):
- “Bilder in modernen Formaten bereitstellen” sollte bestehen, wenn WebP/AVIF konfiguriert ist
- “Bilder effizient codieren” sollte nach der Kompression bestehen
- “Bilder richtig dimensionieren” sollte bestehen, wenn Sie ungenutzte Größen entfernt haben
- “Renderblockierende Ressourcen eliminieren” sollte mit critical CSS bestehen
Core Web Vitals:
- LCP-Ziel: unter 2,5 Sekunden
- CLS-Ziel: unter 0,1
- INP-Ziel: unter 200 Millisekunden
Chrome DevTools zur Überprüfung der Formatauslieferung verwenden
Öffnen Sie DevTools (F12), gehen Sie zum Network-Tab und filtern Sie nach “Img”. Prüfen Sie die Spalte “Type”: Sie sollten webp oder avif anstelle von jpeg oder png sehen. Wenn Sie noch Originalformate sehen, müssen Ihre Umschreibregeln oder die Plugin-Konfiguration angepasst werden.
Lighthouse Performance-Budget
Richten Sie ein Performance-Budget ein, um Regressionen zu erkennen:
[
{
"resourceSizes": [
{ "resourceType": "image", "budget": 300 },
{ "resourceType": "stylesheet", "budget": 50 },
{ "resourceType": "script", "budget": 200 },
{ "resourceType": "total", "budget": 800 }
]
}
]Werte in Kilobyte. Dieses Budget stellt sicher, dass das Gesamtgewicht der Seite unter 800 KB bleibt, wobei Bilder auf 300 KB begrenzt sind.
Fortgeschrittene Techniken für 2026
Fetchpriority für Hero-Bilder
Das Attribut fetchpriority teilt dem Browser mit, welche Bilder beim Laden priorisiert werden sollen. Wenden Sie es auf Ihr LCP-Bild an:
<img src="hero.webp" alt="Hero-Banner" width="1200" height="630"
fetchpriority="high" decoding="async">In WordPress können Sie dieses Attribut mit einem Filter hinzufügen:
<?php
declare(strict_types=1);
add_filter('wp_get_attachment_image_attributes', function (array $attr, WP_Post $attachment, string $size): array {
if ($size === 'hero-banner' && is_front_page()) {
$attr['fetchpriority'] = 'high';
$attr['decoding'] = 'async';
unset($attr['loading']); // Lazy Loading vom Hero entfernen
}
return $attr;
}, 10, 3);Content-visibility für Bereiche unterhalb des sichtbaren Bereichs
Die CSS-Eigenschaft content-visibility erlaubt es dem Browser, das Rendern von Bereichen außerhalb des Bildschirms zu überspringen, bis sie benötigt werden:
.below-fold-section {
content-visibility: auto;
contain-intrinsic-size: auto 500px;
}Dies reduziert die anfängliche Renderarbeit erheblich auf langen Seiten mit vielen Bildern.
Responsive Bilder mit Art Direction
Für Bilder, die bei verschiedenen Breakpoints unterschiedliche Beschnitte benötigen, verwenden Sie das <picture>-Element mit Media Queries:
<picture>
<source media="(max-width: 640px)" srcset="hero-mobile.avif" type="image/avif">
<source media="(max-width: 640px)" srcset="hero-mobile.webp" type="image/webp">
<source srcset="hero-desktop.avif" type="image/avif">
<source srcset="hero-desktop.webp" type="image/webp">
<img src="hero-desktop.jpg" alt="Hero-Bild" width="1200" height="630">
</picture>Performance-Checkliste
Verwenden Sie diese Checkliste, um die Vollständigkeit Ihrer Implementierung zu überprüfen:
- Bildoptimierungs-Plugin installiert und konfiguriert
- WebP-Generierung für alle neuen Uploads aktiviert
- AVIF-Generierung aktiviert (wenn vom Plugin unterstützt)
- Massenoptimierung der vorhandenen Medienbibliothek durchgeführt
- Ungenutzte Bildgrößen entfernt
- Maximale Upload-Dimensionen festgelegt
- .htaccess WebP/AVIF-Umschreibregeln eingerichtet
- Critical CSS-Extraktion aktiviert
- Nicht-kritische Stylesheets verzögert
- Hero-Bild mit
<link rel="preload">vorgeladen - Hero-Bild mit
fetchpriority="high"markiert - LiteSpeed Cache Seiten-Cache aktiviert
- LiteSpeed Cache Browser-Cache aktiviert
- LiteSpeed Cache CSS/JS-Optimierung konfiguriert
- Crawler konfiguriert und aktiv
- PageSpeed Insights-Wert auf 90+ verifiziert
- WebP/AVIF-Auslieferung in DevTools bestätigt
Zwei Fälle, die die Pipeline auf Zahlen abbilden
Der erste Fall war ein WooCommerce-Shop bei einem deutschen Shared-Hoster, der ein 200 KB Hero-PNG, ein 1,2 MB Karussell unkomprimierter JPEGs und ein Page-Builder-Stylesheet von rund 600 KB auf jeder Seite auslieferte. Felddaten zeigten LCP mobil bei 4,0 s, FCP bei 2,8 s. Wir konvertierten das Hero zu AVIF (28 KB nach Glossy-Kompression), fügten fetchpriority="high" und einen passenden <link rel="preload"> hinzu, regenerierten Thumbnails in den Größen, die das Theme tatsächlich nutzte, und ließen ShortPixel-Bulk auf den Altbestand laufen. LCP fiel auf 1,4 s, ohne CSS anzufassen.
Der zweite Fall war das Gegenteil: Bilder waren bereits AVIF, aber FCP weigerte sich, mobil unter 2,4 s zu sinken. Der einzige renderblockierende Übeltäter war eine main.css von 800 KB, die jedes Page-Builder-Modul enthielt, das die Site nie nutzte. Wir extrahierten Critical CSS für die Homepage und drei Landing-Templates mit Penthouse, inlined 12 KB im Head, deferred den Rest mit dem media="print"-Swap-Pattern und ergänzten font-display: swap in den WOFF2-Deklarationen. FCP fiel um etwa 600 ms auf einem gedrosselten Mid-Tier-Android-Profil, und das WP-Rocket-Panel hörte auf, “renderblockierende Ressourcen eliminieren” zu flaggen.
Das Muster verdient eine explizite Benennung: wenn LCP die scheiternde Metrik ist, ist die Lösung fast immer bildseitig; wenn FCP scheitert, während LCP akzeptabel ist, ist die Lösung CSS-seitig. Tools, die beide zusammenwerfen, produzieren vage Verbesserungen; sie als getrennte Engpässe zu behandeln, produziert messbare.
Was WP Rocket, FlyingPress und Perfmatters tatsächlich tun
Diese drei Plugins sind nicht austauschbar, und die Marketing-Seiten verschleiern das. WP Rocket bündelt Page-Caching, CSS/JS-Konkatenation und -Defer, Lazy Loading und einen Integrations-Hook für Imagify; die Critical-CSS-Extraktion (RUCSS) läuft serverseitig auf SaaSWP und fällt graceful zurück, wenn die Extraktion scheitert. FlyingPress fokussiert auf lokale Font-Auslieferung, Inline-Critical-CSS pro Template und Entfernen ungenutzter CSS auf URL-Ebene statt Site-Ebene, das bessere Modell für Sites mit unterschiedlichen Layouts. Perfmatters cached nicht: es deaktiviert WordPress-Funktionen, die die Site nicht braucht (Heartbeat-Polling, Emoji-Skripte, embed.js, REST-Endpunkte) und fügt Preconnect-, Prefetch- und DNS-Prefetch-Hints hinzu. Die drei stapeln sich sauber: Perfmatters trimmt, FlyingPress oder WP Rocket übernehmen CSS und Cache, ein Bild-Plugin übernimmt AVIF.
Wenn der Host OpenLiteSpeed oder LiteSpeed Enterprise ist (Mittwald LiteSpeed-Tarife, einige IONOS-Pakete), ändert sich die Rechnung. LiteSpeed Cache kommuniziert mit dem im Server eingebauten Cache-Modul und überspringt PHP komplett bei Cache-Hits, was schneller ist als jedes innerhalb von PHP laufende Plugin sein kann. Der Trade-off ist, dass QUIC.cloud Critical CSS und Bildkonvertierung off-site abwickelt, was eine eigene DSGVO-Prüfung verlangt: AVV mit QUIC.cloud, Eintrag im Verarbeitungsverzeichnis, gegebenenfalls Drittlandstransfer-Folgenabschätzung.
Bei deutschen Image-CDNs ist die DSGVO-Lage wichtig: Cloudinary stellt eine AVV bereit, der Default-Endpunkt liegt aber außerhalb der EU; ImageKit bietet einen EU-Region-Endpunkt mit AVV unter Standardvertragsklauseln, was den Drittlandstransfer-Aufwand reduziert.
Pipeline-Ergebnisse
In aktuellen Kundenprojekten landet das Muster in dieser Spanne. Behandeln Sie die Zahlen als grobes Fenster und nicht als Garantie, da die Ausgangslage mehr zählt als die Intervention.
| Metrik | Vorher | Nachher |
|---|---|---|
| PageSpeed-Mobilwert | 35-55 | 90-98 |
| LCP | 4,5-8 s | 1,2-2,0 s |
| Gesamtgewicht der Seite | 3-6 MB | 400-800 KB |
| Anzahl der Anfragen | 80-120 | 25-40 |
| TTFB | 800 ms+ | 150-300 ms |
Die Kombination aus modernen Bildformaten, Critical CSS und korrekter Cache-Konfiguration adressiert drei unabhängige Engpässe: Dateigröße, Render-Blocking und Server-Antwortzeit. Keiner ersetzt die anderen.
Wo wppoland.com hineinpasst
Wir betreiben diese Pipeline auf produktiven WordPress- und WooCommerce-Sites: LiteSpeed-Konfiguration auf Serverebene, Critical-CSS-Extraktion mit manueller Coverage-Tab-Bereinigung dort, wo Penthouse einen Selektor verfehlt, AVIF-Auslieferung mit Content-Negotiation und ein Audit-Trail in PageSpeed-Insights-Felddaten, damit die Änderungen unter realem CrUX-Traffic halten. Die Preise sind individuell und hängen von der Größe der Mediathek, dem Page-Builder-Footprint und davon ab, wie viel der Arbeit Migration gegenüber In-Place-Optimierung ist. Wenn PageSpeed-Werte die Rankings der Sites blockieren, kontaktieren Sie uns für ein Performance-Audit.
