Die wichtigste Erkenntnis: Ein CDN und lokale Bildoptimierung lösen unterschiedliche Probleme — ein CDN verkürzt die Netzwerkdistanz, die eine Datei zurücklegt, während lokale Optimierung die Datei selbst verkleinert. Websites mit viel internationalem Traffic und großen Medienbibliotheken profitieren meist von beidem; Websites mit überwiegend lokalen Besuchern erzielen oft mehr, wenn sie zuerst Format und Größe beheben.
Zwei unterschiedliche Engpässe, oft als einer missverstanden
"Meine Bilder sind langsam" kann zwei verschiedene Dinge bedeuten, und die Lösung unterscheidet sich je nachdem, welches tatsächlich zutrifft:
- Die Datei ist zu groß. Ein 2MB-JPEG ist ein 2MB-JPEG, egal wie nah der Server ist. Das ist ein Format- und Kompressionsproblem.
- Die Datei muss zu weit reisen. Selbst eine perfekt optimierte 80KB-WebP-Datei braucht länger, um einen Besucher in Sydney zu erreichen, wenn dein einziger Server in Amsterdam steht. Das ist ein Netzwerklatenzproblem.
Ein CDN (Content Delivery Network) löst das zweite Problem, indem es Kopien deiner Dateien auf global verteilten Servern cacht, sodass ein Besucher vom nächstgelegenen statt von deinem Ursprungsserver herunterlädt. Es tut nichts gegen das erste Problem — ein CDN cacht und liefert eine unoptimierte 2MB-Datei aus Netzwerksicht genauso schnell wie eine kleine.
Was lokale Optimierung tatsächlich bewirkt
"Lokale Optimierung" bedeutet hier, Bilder auf dem eigenen WordPress-Server zu verarbeiten: Konvertierung in moderne Formate (WebP, AVIF), Kompression ohne sichtbaren Qualitätsverlust, Anpassung der Größe an die tatsächlichen Anzeigedimensionen und Generieren der responsiven srcset-Varianten, aus denen Browser wählen können.
Das ist ein einmaliger Aufwand pro Bild. Sobald ein Bild konvertiert und korrekt dimensioniert ist, muss diese Arbeit nicht bei jeder Anfrage wiederholt werden — die kleinere Datei ist einfach das, was von da an ausgeliefert wird, egal ob vom eigenen Server oder hinter einem CDN.
Erdo Image Optimizer macht genau das: Es nutzt die eigene GD- oder Imagick-Bibliothek deines Servers, um Bilder zu konvertieren und zu komprimieren, ohne externe API oder Gebühr pro Bild. Die technischen Details findest du in unserer Anleitung zur Konvertierung von WordPress-Bildern in WebP.
Wo welche Option tatsächlich gewinnt
| Faktor | Lokale Optimierung | CDN |
|---|---|---|
| Reduziert Dateigröße | Ja — das ist die Hauptaufgabe | Nein — liefert aus, was ihm gegeben wird |
| Reduziert Netzwerkdistanz | Nein | Ja — das ist die Hauptaufgabe |
| Einmalige oder wiederkehrende Kosten | Meist einmalige Verarbeitung | Meist wiederkehrend, skaliert mit Bandbreite |
| Hilft bei Publikum in einer Region | Ja, direkt | Begrenzt — wenig Distanz zu verkürzen |
| Hilft bei globalem Publikum | Indirekt (kleinere Dateien übertragen überall schneller) | Ja, direkt |
| Setup-Komplexität | Plugin-Installation + Massenkonvertierung | DNS/Origin-Konfiguration, Cache-Invalidierungsregeln |
Ein durchgerechneter Vergleich
Betrachte ein unoptimiertes 1,8MB-JPEG-Hero-Bild, angefordert von einem Besucher 9.000km vom Ursprungsserver entfernt:
| Szenario | Dateigröße | Ungef. Gesamtladezeit* |
|---|---|---|
| Unoptimiertes JPEG, kein CDN | 1,8 MB | ~2,9s |
| Unoptimiertes JPEG, hinter CDN | 1,8 MB | ~2,1s |
| Optimiertes WebP (~350KB), kein CDN | 350 KB | ~1,3s |
| Optimiertes WebP (~350KB), hinter CDN | 350 KB | ~0,6s |
*Ungefähre, illustrative Werte basierend auf typischen Latenz- und Bandbreitenannahmen für eine Fernanfrage — tatsächliche Zahlen variieren je nach Host, Verbindung und CDN-Anbieter.
Das entscheidende Muster: Formatoptimierung allein (Zeile 3) schlägt das Hinzufügen eines CDN zu einer unoptimierten Datei (Zeile 2). Beides kombiniert (Zeile 4) schlägt jedes für sich mit deutlichem Abstand. Wenn du nur eines zuerst tun kannst, bringt die Behebung der Dateigröße mehr als die Behebung der Distanz.
Wann sich ein CDN lohnt
- Dein Traffic ist wirklich international, nicht nur lokal mit gelegentlichen ausländischen Besuchen.
- Deine Medienbibliothek ist groß genug, dass Origin-Server-Bandbreite oder -CPU selbst unter Last zum Engpass wird.
- Du lieferst bereits optimierte Formate und Größen aus und willst das nächste Quäntchen Geschwindigkeit.
- Du betreibst WooCommerce oder ein anderes Setup mit hohem Traffic, bei dem Origin-Server-Last während Traffic-Spitzen ein echtes Risiko ist.
Wann es nicht die Priorität ist
- Dein Publikum konzentriert sich auf ein Land oder eine Region nahe deinem Hosting.
- Du hast Bilder noch nicht in moderne Formate konvertiert — das ist fast immer die wirkungsvollere Maßnahme, die zuerst kommt.
- Dein aktuelles Hosting enthält bereits ein grundlegendes CDN oder eine Caching-Schicht (üblich bei verwalteten WordPress-Hosts wie Kinsta oder WP Engine) — prüfe das, bevor du für ein zweites bezahlst.
So prüfst du, was deine Website tatsächlich braucht
Statt zu raten, führe eine schnelle Diagnose durch:
- Öffne PageSpeed Insights und prüfe im Abschnitt "Diagnose" markierte Bilder — wenn Format- oder Größenprobleme angezeigt werden, ist das ein lokales Optimierungsproblem, kein Distanzproblem.
- Nutze ein Tool wie WebPageTest mit einem Teststandort weit von deinem Server entfernt (zum Beispiel ein Test aus Singapur, wenn dein Host in Europa steht). Vergleiche "Time to First Byte" und Verbindungszeit mit einem Testlauf von einem Standort nahe deinem Server. Eine große Lücke zwischen beiden deutet auf Latenz statt Dateigröße als größeren Faktor hin.
- Prüfe die Dokumentation deines Hosting-Plans — viele verwaltete WordPress-Hosts (Kinsta, WP Engine, Cloudways) bündeln standardmäßig ein CDN oder eine Edge-Caching-Schicht. Für ein zweites CDN zu zahlen, wenn du bereits eines hast, hilft selten.
Ein paar CDN-Fallstricke, die man kennen sollte
Ein CDN ist nach dem Hinzufügen kein reiner Vorteil — ein paar praktische Probleme tauchen in echten WordPress-Setups auf:
- Cache-Invalidierung — das Ersetzen eines Bildes in der Mediathek aktualisiert nicht immer sofort die gecachte Kopie des CDN. Die meisten Integrationen handhaben das automatisch, aber es lohnt sich, das zu prüfen, besonders bei zeitkritischen Inhalten wie Preisgrafiken.
- Zusätzlicher DNS-/Verbindungs-Overhead bei kleinen Websites — bei einer Seite mit nur 2-3 Bildern kann der Overhead einer neuen DNS-Auflösung und eines TLS-Handshakes zu einer CDN-Domain den Latenzgewinn gelegentlich aufheben, besonders bei Besuchern, die bereits nah am Ursprungsserver sind.
- CORS-Konfiguration — wenn das CDN Assets von einer anderen Subdomain ausliefert, können Schriftarten und einige per JavaScript geladene Bilder auf CORS-Fehler stoßen, wenn Header nicht korrekt konfiguriert sind.
Keiner dieser Punkte ist ein Grund, ein CDN grundsätzlich zu meiden — sie sind Konfigurationsdetails, die es zu prüfen lohnt, statt anzunehmen, ein CDN sei ein rein kostenloser Gewinn.
Beides zusammen verwenden
Für Websites, die tatsächlich beides brauchen, zählt die Reihenfolge: erst optimieren, dann cachen. Erdo Image Optimizer enthält genau aus diesem Grund eine optionale BunnyCDN-Integration — Bilder werden lokal in WebP/AVIF konvertiert und korrekt dimensioniert, dann sind es diese bereits optimierten Dateien, die an den CDN-Edge gepusht und von dort ausgeliefert werden, statt die ursprünglichen übergroßen Uploads zu cachen.
Fazit
"CDN" und "Bildoptimierung" als austauschbare Lösungen für dasselbe Problem zu behandeln, ist ein häufiger Fehler — sie adressieren unterschiedliche Schichten derselben Gesamtladezeit. Wenn die Bilder deiner Website noch rohe JPEGs und PNGs sind, bringt deren Konvertierung und Größenanpassung meist mehr als das Vorschalten eines CDN. Wenn du Format und Größe bereits erledigt hast und dein Traffic wirklich global ist, ist ein CDN der logische nächste Schritt. Für die meisten WordPress-Websites lautet die richtige Reihenfolge: erst optimieren, dann entscheiden, ob die verbleibende Latenz die laufenden Kosten eines CDN rechtfertigt.