Warum große Bilder WordPress auch mit CDN verlangsamen können

Große Bilder WordPress verlangsamen die Ladezeit sogar mit CDN, weil riesige Dateien erst vom Ursprungsserver auf Edge-Knoten gelangen und dann on-the-fly optimiert werden müssen, was Rechenzeit kostet. Ich zeige, wie Bildergrößen, CDN-Setup und Core Web Vitals zusammenspielen und weshalb unoptimierte Uploads LCP und Time-to-First-Byte spürbar verschlechtern.

Zentrale Punkte

• Ursprungsgröße bleibt der Flaschenhals – selbst mit CDN.
• LCP-Belastung durch schwere Hero-Bilder und fehlendes Preload.
• On-the-fly-Resizing kostet CPU und Zeit an Edge-Nodes.
• WebP/AVIF senken Datenvolumen massiv, Fallbacks sichern Kompatibilität.
• Workflow mit Vorab-Resize, Qualität ~85 % und responsiven Größen.

Warum große Bilder trotz CDN bremsen

Ein CDN senkt zwar die Latenz, doch übergroße Originaldateien bleiben schwer. Zuerst muss der Edge-Knoten die Datei vom Ursprungsserver ziehen, was bei 5–10 MB-Bildern lange dauert und im Worst Case zu Timeouts führt. Dann folgt die Verarbeitung: Komprimierung, Formatwechsel, Resizing – jeder Schritt kostet CPU-Zeit. Während dieses Prozesses wartet der Browser auf das wichtigste Bild, was LCP verschlechtert. Selbst nach dem ersten Hit bleibt die Gefahr, dass erneute Purges oder Variantenwechsel das Caching entwerten und erneut Verzögerungen auslösen.

So arbeiten CDNs mit Bildern

Ein modernes CDN liefert statische Dateien aus Caches nahe am Nutzer und kann Bilder zusätzlich transformieren. Dazu zählen Komprimierung (Brotli/Gzip), Formatkonvertierung (WebP/AVIF), Resizing je Viewport und Lazy Loading. Klingt schnell, doch der erste Request muss die Originaldatei beziehen, analysieren und transformieren. Ohne passende Cache-Strategie entstehen pro Variante (Breakpoints, DPR, Qualität) mehrere Versionen, die erst entstehen müssen. Das beschleunigt spätere Abrufe, aber der Aufbau kann bei sehr großen Uploads den initialen Seitenaufbau spürbar verzögern.

Bildformate im Überblick: Wann JPEG, PNG, SVG, WebP und AVIF?

Ich wähle das Format bewusst nach Motivtyp, denn der größte Hebel liegt oft im richtigen Container:

• JPEG: Für Fotos mit vielen Farbabstufungen. Ich nutze 4:2:0-Chroma-Subsampling und Qualität ~80–85 %; feine Kanten bleiben sauber, die Datei schrumpft deutlich.
• PNG: Für Transparenz und Grafiken mit harten Kanten. Vorsicht bei Fotos – PNG bläht sich auf. Für reine Vektorformen bevorzuge ich SVG.
• SVG: Logos, Icons, einfache Illustrationen. Skalierbar ohne Qualitätsverlust, extrem klein. Wichtig: nur vertrauenswürdige Quellen verwenden und bei Bedarf sanitizen.
• WebP: Mein Standard für Fotos und Mischmotive; gute Balance aus Qualität und Kompression, transparente Hintergründe sind möglich.
• AVIF: Beste Kompression, aber teils langsamere En-/Deko­dierung und schwierig bei feinen Gradients. Ich prüfe Motive individuell und setze bei Problemfällen auf WebP.

Art Direction löse ich über das <picture>-Element: unterschiedliche Zuschnitte für Mobil/Desk und Formate per type-Hint. Wichtig ist ein robuster Fallback (JPEG/PNG), falls der Browser AVIF/WebP nicht kann.

Einfluss auf Core Web Vitals und LCP

Die Metrik LCP reagiert empfindlich auf Bildgrößen, da Hero-Bereiche häufig das größte sichtbare Element enthalten. Ein 300–500 KB Hero-Bild kann schnell sein, ein 4–8 MB Motiv bremst massiv. Kommt noch eine langsam erzeugte WebP-Variante hinzu, erhöht sich die Wartezeit weiter. Ohne Preload für das LCP-Bild blockiert der Browser zusätzliche Ressourcen, bevor das zentrale Motiv erscheint. Auf mobilen Verbindungen mit hoher Latenz fällt dieser Effekt stärker ins Gewicht als auf Desktop-Leitungen.

Typische Fehlkonfigurationen und ihre Folgen

Fehlen width- und height-Attribute, kann das Layout springen und der CLS-Wert steigt. Werden LCP-Bilder per Lazy Loading verzögert, startet das Rendering zu spät und der Nutzer sieht erst spät Inhalte. Ein zu aggressiver Cache-Purge löscht mühsam erzeugte Varianten, was den nächsten Besucher wieder auf den langsameren Transformationsweg schickt. Außerdem blockiert ein fehlender Fallback bei WebP ältere Browser, die nur JPEG können. Warum automatisches Lazy Loading manchmal schadet, erkläre ich im Beitrag Lazy Loading nicht immer schneller; dort zeige ich, wie ich LCP-Bilder vom Verzögern ausnehme.

WordPress-spezifische Stellschrauben

In WordPress lege ich den Grundstein über Bildgrößen und Filter. Mit add_image_size() definiere ich sinnvolle Breakpoints (z. B. 360, 768, 1200, 1600 px). Nicht benötigte Zwischengrößen entferne ich per remove_image_size() oder filtere sie über intermediate_image_sizes_advanced heraus, damit der Upload-Prozess nicht ausufert. Über big_image_size_threshold verhindere ich übergroße Originale, indem ich einen Deckel (z. B. 2200 px) setze.

Für das Markup verlasse ich mich auf wp_get_attachment_image(), weil WordPress automatisch srcset und sizes generiert. Stimmt das Theme-Layout nicht, passe ich das sizes-Attribut per Filter an – zu generös gewählte Werte sind ein häufiger Grund, warum mobile Geräte unnötig große Bilder laden. Lazy Loading ist seit WordPress standardmäßig aktiv; über wp_lazy_loading_enabled bzw. wp_img_tag_add_loading_attr nehme ich das LCP-Bild gezielt aus. Zusätzlich setze ich bei diesem Bild fetchpriority="high", um die Priorisierung im Netzwerk-Stack zu erhöhen.

Konkrete Optimierungsschritte vor dem Upload

Ich verhindere Staus, indem ich Uploads vorab zurechtschneide, komprimiere und in passende Formate überführe. Für typische Themes reichen 1200–1600 px Breite für Content-Bilder und 1800–2200 px für Header. Ich setze Qualitätsstufen um 80–85 %, die visuell sauber bleiben und Bytes sparen. Zusätzlich entferne ich EXIF-Daten, die auf der Website keinen Nutzen bringen. Durch diese Vorarbeit sinkt die Last am CDN-Edge, und Varianten entstehen deutlich schneller.

Maßnahme	Nutzen	Hinweis
Resize vor Upload	Time-to-Image sinkt deutlich	Maximale Breite an Theme anpassen
Qualität ~85 %	Dateigröße stark reduziert	Visuell kaum sichtbar bei Fotos
WebP/AVIF	Einsparung bis 80 %	JPEG/PNG als Fallback bereitstellen
Preload LCP-Bild	LCP spürbar besser	Nur das größte Above-the-Fold-Bild preladen
Langes Cache-Expiry	Edge-Trefferquote steigt	Unnötige Purges vermeiden

Farbmanagement, Qualität und Metadaten

Farbräume können Performance und Darstellung beeinflussen. Ich konvertiere Assets für das Web in sRGB und verzichte auf große ICC-Profile, die Bytes kosten und Farbverschiebungen zwischen Browsern begünstigen. Bei JPEGs setze ich auf moderate Schärfung und kontrollierte Rauschminderung – übertriebene Weichzeichnung spart zwar Bytes, macht aber Gradients fleckig. Chromatische Subsampling-Settings (4:2:0) bringen gute Einsparungen ohne sichtbaren Qualitätsverlust bei Fotos. EXIF, GPS und Kameradaten entferne ich konsequent; sie sind ballast und bergen teils Datenschutzrisiken.

CDN-Einstellungen, die wirklich zählen

Ich priorisiere Image-Optimierungen direkt im CDN: automatische Formatwahl, Resizing nach DPR, moderates Sharpening und verlustbehaftete Kompression mit Obergrenze. Für Hero-Bilder definiere ich feste Breakpoints, damit nicht für jeden Viewport eine neue Variante entsteht. Cache-Keys binde ich an Format und Größe, um saubere Treffer zu erzielen. Außerdem halte ich Cache-Expiry für Bilder lang, damit Edge-Knoten warm bleiben. Wer konkrete Integrationsschritte braucht, wird bei der Anleitung zur Bunny CDN Integration fündig.

HTTP-Header und Cache-Strategien im Detail

Die richtigen Header verhindern Cache-Fragmentierung. Für Bilder setze ich Cache-Control mit hohem max-age (und optional immutable) und halte sie strikt public. Für CDNs nutze ich s-maxage, um eine längere Lebensdauer an den Edges als im Browser zu erlauben. ETag oder Last-Modified helfen bei Revalidierung, sollten aber stabil bleiben. Wenn das CDN per Content-Negotiation zwischen AVIF/WebP/JPEG entscheidet, muss der Cache-Key das Accept-Header berücksichtigen, sonst kommt es zu Fehltreffern. Alternativ trenne ich Varianten per URL-Parametern oder Pfad, damit das Edge-Caching stringent bleibt. Wichtig: Statische Assets dürfen keine Cookies senden; Set-Cookie killt den Cache.

Mobile Performance und responsive Größen

Smartphones profitieren stark von responsiven Größen und sauberen srcset-Attributen. Ich sorge dafür, dass WordPress passende Zwischenformate erzeugt und das CDN diese Varianten cacht. So erhält ein 360 px breites Display kein 2000 px Foto. Für starke Pixeldichten liefere ich 2x-Varianten, aber mit Limit, damit kein 4K-Bild auf ein Mini-Display gelangt. Auf Mobilfunk senkt das die Datenmenge und stabilisiert LCP deutlich.

Preload, Priorisierung und die richtigen Attribute

Für das LCP-Bild kombiniere ich rel="preload" (als Image) mit einem klaren Ziel: exakt die benötigte Variante vorziehen, nicht eine generische. Zusätzlich setze ich am tatsächlichen <img> fetchpriority="high" und lasse das Default-Lazy-Loading weg (loading="eager" nur für dieses Element). decoding="async" beschleunigt das Dekodieren, ohne den Haupt-Thread zu blockieren. Liegt das CDN auf einer separaten Domain, hilft ein früher Preconnect, um TLS-Handshake und DNS schneller zu erledigen – aber gezielt und nicht inflationär. Alles zusammen verkürzt die kritische Kette bis zur Bilddarstellung.

Resizing on-the-fly vs. Preprocessing

On-the-fly klingt bequem, doch große Originale bleiben eine Last für die Edge-CPU. Ich mixe daher Preprocessing vor dem Upload mit kontrolliertem Edge-Resizing. So fallen die schwersten Arbeiten lokal an, während das CDN Feintuning übernimmt. Für Bildformate wähle ich WebP als Basis und prüfe bei heiklen Motiven AVIF. Die Unterschiede zwischen beiden Formaten erläutere ich hier: WebP vs. AVIF Vergleich.

Kosten, Limits und Skalierung im CDN-Betrieb

Transformationsfunktionen sind nicht gratis: Viele CDNs rechnen Bildkonvertierung, CPU-Zeit und Egress separat ab. Riesige Originale erhöhen nicht nur Latenz, sondern auch Kosten. Ich plane daher konservative Varianten – wenige, gut gewählte Breakpoints statt jeder Pixelbreite. Das reduziert die Anzahl an Dateien, die erzeugt und vorgehalten werden müssen. Bei hohem Traffic hilft ein Origin Shield, um den Ursprungsserver zu schützen. Fehlerbilder (429/503) an Edge-Nodes sind oft ein Zeichen, dass on-the-fly-Resizing überlastet ist; hier lohnt es sich, besonders große Motive vorzurendern oder Limits für gleichzeitige Transformationen zu setzen.

Fehleranalyse: So finde ich die wahren Bremsen

Ich starte mit einem Lab-Test über mehrere Messpunkte und prüfe dabei Filmstrips, Wasserfalldiagramme und LCP-Elemente. Danach vergleiche ich First-View gegen Repeat-View, um Caching-Effekte zu erkennen. Große Abweichungen zeigen an, dass der erste Hit Transformationskosten trägt. Anschließend isoliere ich das LCP-Bild, teste es in verschiedenen Größen und bewerte Qualität gegen Kilobytes. Abschließend prüfe ich Server-Logs und CDN-Analytics, ob Edge-Misses oder Purges den Cache leeren.

RUM und Field-Daten richtig deuten

Laborwerte erzählen nicht die ganze Geschichte. Ich werte Field-Daten aus, um reale Geräte, Netze und Regionen abzudecken. Hohe Varianz zwischen Regionen deutet auf kalte Edges oder schwache Peering-Strecken hin. Sehe ich schlechte LCP-Werte primär bei Mobilfunknutzern, prüfe ich zuerst das Hero-Bild, srcset-Treffer und Preload. Eine wiederkehrende Kluft zwischen First-View und Repeat-View weist auf zu kurze max-age-Werte oder häufige Purges hin. Ich korreliere außerdem Veröffentlichungszyklen mit Ausschlägen in den Metriken – neue Headerbilder oder Kampagnenvisuals sind oft die Auslöser.

Workflow und Automatisierung im Alltag

Ohne festen Prozess schleichen sich wieder große Dateien ein. Ich setze daher auf automatisches Resizing beim Upload, einheitliche Qualitätsprofile und feste Maximalbreiten. Ein Bildstil-Guide hilft, Motive konsistent und leicht komprimierbar zu halten. Vor Livegang kontrolliere ich die LCP-Bilder manuell und aktiviere Preload nur für das größte Element. Nach Deployments messe ich erneut, weil neue Hero-Motive schnell aus dem Rahmen fallen.

SEO, Barrierefreiheit und Redaktionsleitfaden

Performance und Qualität gehen Hand in Hand mit SEO und A11y. Ich vergebe aussagekräftige alt-Texte und sinnvolle Dateinamen, halte Bildabmessungen konsistent und vermeide CSS-Upscaling. Für Social Previews (Open Graph) bereite ich separate, komprimierte Motive vor, damit sie nicht aus Versehen als LCP-Bild dienen. Hotlink-Schutz setze ich mit Bedacht ein – Crawler und Previews benötigen Zugriff. Für redaktionelle Teams dokumentiere ich Maximalbreiten, Formate, Qualitätsstufen und eine einfache Checkliste: Zuschneiden, Format wählen, Qualität prüfen, Dateiname vergeben, in WordPress hochladen, LCP-Kandidat markieren und Preload testen. So bleibt die Qualität reproduzierbar, auch wenn mehrere Personen Inhalte pflegen.

Kurz zusammengefasst

Ein CDN beschleunigt Auslieferung, doch übergroße Originale bleiben der Bottleneck – sie kosten Zeit beim ersten Abruf und verschlechtern LCP. Ich verhindere das, indem ich Bilder vorab in Breite, Qualität und Format optimiere und nur feine Anpassungen dem Edge überlasse. Saubere srcset-Attribute, Preload für das LCP-Bild und lange Cache-Expiry machen den Unterschied. Bei Konfigurationen prüfe ich Fallbacks für WebP/AVIF, Dimensionsangaben und Cache-Keys für Varianten. So bleibt WordPress flott, auch wenn viele Bilder die Seite tragen.