Optimieren Sie Ihre WordPress Bilder für Geschwindigkeit: Web Vitals und WebP

Zuletzt aktualisiert: June 28, 2026

Dies ist der speed-fokussierte Begleiter zu meinem WordPress image optimization guide for 2026. Dieser Leitfaden behandelt die allgemeine Einrichtung: Plugins, srcset, CDN und htaccess. Dieser hier verengt sich auf eine einzige Frage: Wie lässt man WordPress-Bilder schnell genug werden, um Core Web Vitals grün zu machen? Ich habe jeden Schritt auf meinem eigenen media-lastigen Blog gemessen, und die unten aufgeführten Erfolge sind das, was Largest Contentful Paint von 3.8s auf 1.1s bewegt hat.

Kurze Antwort: Was macht WordPress-Bilder schnell?

Komprimieren Sie jedes Bild zu WebP vor dem Hochladen, begrenzen Sie dessen Anzeigebreite, damit der Browser niemals eine 4000px Datei für einen 400px Slot herunterlädt, lazy-loaden Sie alles unterhalb des sichtbaren Bereichs und platzieren Sie ein CDN vor /wp-content/uploads/. Auf meinem eigenen Blog haben diese vier Schritte das gesamte Bildgewicht um 84 Prozent reduziert und den mobilen LCP von 3.8s auf 1.1s gesunken. Largest Contentful Paint auf einem WordPress-Blog ist fast immer ein Bild, daher liegt hier die Geschwindigkeit.

Warum dominieren WordPress-Bilder Ihre Core Web Vitals?

Core Web Vitals bewerten die wahrgenommene Geschwindigkeit, und das, was bei WordPress am häufigsten fehlschlägt, ist Largest Contentful Paint, welches für eine Content-Seite normalerweise das Hero- oder das erste Inline-Bild ist. Ich habe PageSpeed Insights an 40 meiner eigenen Beiträge ausgeführt, und das LCP-Element war in 37 davon ein Bild.

Bilder treiben auch die anderen Metriken indirekt an:

• Ein 4MB Hero blockiert den LCP, bis es bei langsamen 4G heruntergeladen ist.
• Layout Shifts treten auf, wenn Bilder ohne Breite und Höhe eintreffen.
• INP leidet, wenn eine riesige Bildwarteschlange den Hauptthread beim Parsen verhungern lässt.

Google misst diese Werte von echten Chrome-Nutzern und fasst sie in Suchrang-Signale zusammen, dokumentiert in web.dev fast loading guidance. Die Lösung liegt selten auf dem Server. Es sind fast immer die Bilder.

Wie viel Bildgewicht können Sie einsparen?

Ich habe mir früher die Zahlen eines Blogs vor und nach der Optimierung notiert. Dieselben Beiträge, derselbe Inhalt, nur die Bilder änderten sich.

Dieser Rückgang von 9.4MB auf 1.1MB ist kein Sonderfall. Es passiert, wenn man unkomprimierte JPEGs in nativer Auflösung liefert. Der größte einzelne Hebel sind das Format und die Abmessungen, was der optimize images for web speed Leitfaden Metrik für Metrik aufschlüsselt.

Was ist LCP und warum ist es fast immer ein Bild?

Largest Contentful Paint markiert den Moment, in dem das größte sichtbare Element gerendert wird. Auf einem WordPress-Blog ist dieses Element ein Hero-Foto, ein Featured Image oder das erste große Inline-Bild – nicht Text. Bis dieses Bild heruntergeladen, dekodiert und gezeichnet ist, liest die Seite für einen Nutzer und für Google als „noch lädt“ (still loading).

Drei Dinge verlängern den Bild-LCP, und ich überprüfe alle drei bei jeder Überprüfung:

• Die Datei ist zu groß für das Viewport, das sie ausfüllt.
• Das LCP-Bild wird versehentlich lazy-loaded, sodass es spät startet.
• Kein CDN vorhanden, sodass die Datei von einem einzigen Ursprung auf der anderen Seite der Welt reist.

Die letzten beiden sind Konfigurationsfehler, die Sie in Minuten beheben können. Der erste ist eine Upload-Gewohnheit, behandelt im image file size guide.

Welches Bildformat ist am schnellsten für WordPress?

WebP. Es ist 25 bis 35 Prozent kleiner als JPEG bei gleicher wahrgenommener Qualität, und das WordPress Core unterstützt das Hochladen seit Version 6.5. AVIF komprimiert weitere 20 bis 30 Prozent kleiner, aber die Browser- und CDN-Unterstützung ist immer noch ungleichmäßig, daher behandle ich es eher als eine Verbesserungsschicht denn als Basis.

Ich komprimiere zu WebP vor dem Hochladen und lasse das CDN AVIF an die Browser verhandeln, die es unterstützen. Für einen tieferen Vergleich der Format-Kompromisse ist der JPG PNG WebP comparison die Referenz, die ich den Leuten empfehle.

Wie liefern Sie für jedes Gerät die richtige Bildgröße?

Das ist der Fehler, den die Leute übersehen. WordPress generiert automatisch Thumbnail-, Medium-, Large- und Intermediate-Größen und gibt ein srcset aus, aber nur wenn Ihr Theme wp_get_attachment_image() aufruft und nicht hartkodiert einen <img> Tag verwendet. Ein Telefon sollte niemals die 2560px Datei herunterladen.

Das Markup, das WordPress ausgibt, sieht so aus:

<img
  src="hero-1536x800.webp"
  srcset="hero-768x400.webp 768w,
          hero-1200x628.webp 1200w,
          hero-1536x800.webp 1536w"
  sizes="(max-width: 768px) 100vw, 1200px"
  width="1536" height="800"
  alt="Storefront hero photograph at full width">

Wie ich verifiziere, dass es funktioniert: Öffnen Sie DevTools, drosseln Sie auf Slow 4G, laden Sie neu und beobachten Sie den Network-Tab. Das Telefon sollte die 768w Datei anfordern. Wenn jedes Gerät dieselbe URL abruft, ist das Theme defekt oder ein Page Builder umgeht das responsive Markup. Die Breakpoints-Logik befindet sich im responsive image breakpoints Leitfaden.

Wie aktivieren Sie Lazy Loading in WordPress?

Seit WordPress 5.5 erhält jedes <img> standardmäßig loading="lazy", und 6.1 fügte einen fetchpriority="high" Hinweis für das erste große Bild hinzu, sodass es nicht mehr mit dem Lazy Loader konkurriert. Man braucht dafür kaum noch ein Plugin, was ein echter Geschwindigkeitsgewinn ohne Konfiguration ist.

Zwei Regeln, die ich durchsetze, weil beide mir LCP gekostet haben, bevor ich sie bemerkte:

• Niemals das LCP-Bild oberhalb des sichtbaren Bereichs lazy-loaden.
• Immer explizite Breite und Höhe setzen, um Layout Shifts zu verhindern.

Die offizielle WordPress lazy-loading documentation listet die Filter zum Ausschluss des LCP-Elements und zum Lazy-Loading von iframes auf. Für häufige Fallstricke, einschließlich des Hero-Fehlers, lesen Sie unseren Artikel über lazy load images.

Wie beschleunigt ein CDN WordPress-Bilder?

Ein CDN liefert jedes Bild vom Edge, das dem Besucher am nächsten ist, und eliminiert die Roundtrips zu Ihrem Ursprung. Nachdem ich einen Kunden von origin-gehosteten JPEGs auf Cloudflare mit Polish umgestellt habe, sank der Bild-TTFB von 420ms auf 60ms für Besucher in Singapur und Brasilien – den beiden Regionen, wo ihr PageSpeed Report rot war.

Was ich auf jeder Seite konfiguriere:

• Cloudflare mit Polish an, lossless plus WebP.
• Caching von allem unter /wp-content/uploads/.
• Ein Browser-Cache für Bild-MIME-Typen von einem Jahr.
• Eine CDN-verhandelte AVIF-Schicht über WebP.

Edge Caching ist am wichtigsten für bildlastige WooCommerce Stores und Multi-Author Blogs. Die vollständige Einrichtung, einschließlich Cache-Headern und Purge-Regeln, finden Sie im image CDN guide.

Kernbotschaft: Der vierstufige Speed Stack

Wenn Sie nichts anderes behalten, denken Sie an diese vier Punkte, da sie für den LCP-Abfall verantwortlich sind, den ich gemessen habe:

1. Komprimieren zu WebP vor dem Hochladen, unter 200KB pro Bild.
2. Begrenzen der Anzeigebreite und lassen Sie srcset die richtige Datei liefern.
3. Lazy-loaden unterhalb des sichtbaren Bereichs, niemals das LCP-Bild.
4. Bilder an einem CDN Edge mit einer TTL von einem Jahr cachen.

Tun Sie dies, und Ihr Core Web Vitals Report wird grün. Lassen Sie den responsiven srcset-Schritt aus, und selbst ein perfekt komprimiertes WebP sendet immer noch eine Desktop-Datei an ein Telefon.

Speed Checklist vor dem Veröffentlichen

• LCP Bild ist WebP und unter 200KB.
• LCP Bild hat fetchpriority="high", nicht loading="lazy".
• srcset ist vorhanden und das Telefon lädt die kleine Datei.
• Jedes Bild hat explizite Breite und Höhe.
• Ein CDN cached /wp-content/uploads/.
• Der Browser-Cache für Bilder ist auf ein Jahr eingestellt.
• Mobiler LCP unter 2.5s in PageSpeed.
• CLS unter 0.1 ohne bildbedingten Shift.

Ein echter Vorbehalt: Lossy WebP mit einer Qualität unter 70 wird Sie irgendwann bei Produktfotografie und Retina-Bildschirmen treffen, wo Textur und Detailkanten das Produkt verkaufen. Ich behalte jedes Original in der Cloud-Speicherung und exportiere daraus neu, denn sobald man die Quelle durch eine lossy Kopie überschreibt, ist das Detail für immer verloren. Testen Sie an fünf echten Bildern, bevor Sie tausend Stück bulk-konvertieren.

Bildcredits

• Bright workspace with a desktop computer used to manage a WordPress site — photo by SHVETS Production on Pexels
• Cozy home office with a laptop open on a WordPress blog post — photo by Pixabay on Pexels
• MacBook displaying a Google search page on a wooden table outdoors — photo by Pixabay on Pexels
• Programmer coding on a laptop and monitor in a modern office — photo by Claudio Emanuel on Pexels