Bildoptimierung selbst hosten: die ehrlichen Kompromisse

Der Standardrat bei Bildern lautet: ein verwalteter Dienst – Cloudinary, imgix und ähnliche. Dieser Rat ist oft richtig, und das hier ist kein „SaaS ist schlecht"-Beitrag. Es ist ein ehrlicher Blick auf den Kompromiss, von einem Projekt aus, das auf der selbst gehosteten Seite steht.

Was die verwalteten Dienste wirklich bieten

• Kein Betriebsaufwand. Keine Server, keine Encoder-Toolchains, kein CDN zu konfigurieren. Es funktioniert am Tag der Anmeldung.
• Transformationen am Edge, global. Größe ändern, zuschneiden, Format spontan aushandeln, gecacht an Hunderten Standorten. Ohne echte Infrastruktur schwer zu erreichen.
• Jemand anders trägt die schwierigen Teile – neue Formate, Encoder-Bugs, Skalierung bei einer Traffic-Spitze.

Für ein kleines Team ohne Infrastruktur-Leute ist das sein Geld wert. Nicht selbst hosten, nur um einen Punkt zu beweisen.

Wo das verwaltete Modell teuer wird – und nicht nur finanziell

Die Reibung zeigt sich beim Wachstum entlang drei Achsen:

• Kosten, die mit dem Erfolg skalieren. Verwaltete Bilddienste rechnen nach einer Mischung aus Transformationen, gespeicherten Assets und Bandbreite ab. Die Rechnung wächst mit dem Traffic, und die Preislogik legt der Anbieter fest, nicht man selbst. Ein Hobbyprojekt ist kostenlos; ein beliebtes wird zu einem Posten, der nur steigt.
• Die Bilder verlassen die eigene Kontrolle. Jedes Asset – und jeder Nutzer-Upload – läuft über die Infrastruktur eines Dritten und wird dort gecacht. Für manche Produkte ist das ein Datenschutz-, Compliance- oder Vertragsproblem, keine Geschmacksfrage.
• Man optimiert nach deren Regeln. Man bekommt die Qualitätsregler, die der Anbieter zur Verfügung stellt. Wer eine wahrnehmungsbasierte Qualität pro Bild anstreben will statt einer festen Einstellung (der Unterschied zwischen konsistenter Qualität und einer Vermutung), bekommt das, was die Plattform anbietet.

Keiner dieser Punkte ist ein Grund, am ersten Tag zu wechseln. Alle sind Gründe, warum sich die Rechnung ab einer gewissen Größe umdreht.

Die selbst gehosteten Optionen sind inzwischen ausgereift

Self-Hosting bedeutete früher, ImageMagick an einen Cache zu kleben und zu hoffen. Die aktuellen Tools sind solide:

• imgproxy und Thumbor – selbst betriebene Server für spontane Größenänderung/Transformation.
• wsrv.nl (images.weserv.nl) – ein quelloffenes Bild-CDN zum Selbsthosten.
• Patu – eine selbst gehostete Optimierungs-API, qualitätsgesteuert per wahrnehmungsbasiertem Wert, mit CDN-Schicht.

Stellt man ein CDN vor eines davon, hat man die verwaltete Erfahrung, auf eigener Rechenleistung, mit Kosten, die die eigene Server-Rechnung sind statt eine Abrechnung pro Bild.

Was Self-Hosting tatsächlich kostet

Ehrlichkeit geht in beide Richtungen. Self-Hosting ist nicht aufwandsfrei:

• Man betreibt es selbst. Verfügbarkeit, Skalierung unter Last, das CDN und die Encoder-Toolchain aktuell zu halten, liegen jetzt bei einem selbst.
• Man braucht einen Cache. Gut zu optimieren ist CPU-intensiv – eine Qualitätssuche über ein großes Foto ist nicht billig. Dasselbe Asset bei jeder Anfrage neu zu encodieren ist der klassische Fehler beim Self-Hosting; das ganze Modell hängt daran, einmal zu encodieren und aus Cache/CDN auszuliefern.
• Man trägt die Randfälle selbst. Ein defekter Upload, ein pathologisches Bild, ein neues Format – kein Anbieter fängt das für einen ab.

Der Lohn ist eine planbare Kostenstruktur, die nicht mit dem Traffic skaliert, Daten, die nie die selbst kontrollierte Infrastruktur verlassen, und die Freiheit, genau so zu optimieren, wie man will.

Wie man tatsächlich entscheidet

• Kein Infra-Team, Bilder sind nebensächlich für das Produkt → verwalteter Dienst. Das ist ohne Wenn und Aber die richtige Wahl.
• Bilder sind zentral, Traffic ist real, oder die Rechnung pro Bild fängt an wehzutun → selbst hosten, mit Cache und CDN.
• Nutzer-Uploads, die nicht an Dritte gehen dürfen, oder eine bestimmte Qualitätsschwelle, die man halten will → selbst hosten, und das ist weniger eine Kosten- als eine Kontrollentscheidung.

Patu existiert für den zweiten und dritten Fall: dasselbe Ergebnis, das ein verwalteter Dienst liefert – AVIF-first, qualitätsgesteuert, hinter einem CDN – auf selbst betriebener Infrastruktur, bepreist wie Software statt wie ein Zähler. Ob das der richtige Tausch ist, entscheidet jeder selbst; dieser Beitrag ist dazu da, dass diese Entscheidung mit den echten Kompromissen vor Augen fällt, nicht mit der Marketingversion.

Patu macht keinen Hehl daraus, nur eine Option unter mehreren zu sein; die oben verlinkten Projekte sind die echten Alternativen, und die richtige Wahl hängt vom eigenen Team, Traffic und Datenanforderungen ab, nicht davon, welchen Beitrag man zuletzt gelesen hat.