Bloat, den der Besucher nie sieht
Über langsame Ladezeiten durch Bilder wird viel geschrieben — zu Recht. Was seltener zur Sprache kommt, ist die andere Hälfte der Rechnung: Ein unoptimiertes Bild belastet nicht nur den Browser des Besuchers, sondern bleibt — im Dateisystem, im CMS, in jedem Backup, in der Versionsgeschichte, in jeder Deploy-Pipeline. Diese Kosten sieht niemand im Frontend, und genau deshalb wachsen sie so lange ungebremst.
Als Ausgangspunkt nehme ich die Zahl aus meiner Beispielrechnung zur Website-Größe: 1200 Seiten, je 3 Bilder à durchschnittlich 3 MB, macht rund 10,8 GB reine Originalbilder. Verfolgen wir, was daraus hinter den Kulissen wird.
Die Media-Library, die niemand aufräumt
Kein CMS speichert nur das Original. WordPress, TYPO3, Shopsysteme — sie erzeugen bei jedem Upload automatisch mehrere Bildgrößen: Thumbnail, Medium, Large, oft noch Format- und Retina-Varianten. In der Praxis kommen so pro Originalbild schnell das Zwei- bis Dreifache an abgeleiteten Dateien zusammen. Aus 10,8 GB Originalen werden damit leicht 25–30 GB Media-Library — und die wird praktisch nie aufgeräumt. Gelöschte Beiträge, ausgetauschte Bilder, Testuploads: Sie bleiben als Dateileichen liegen, weil sie im Frontend niemandem auffallen.
Backups multiplizieren alles
Jetzt kommt der Multiplikator, der aus einem Ärgernis ein echtes Kostenproblem macht: Backups. Eine ordentliche Sicherungsstrategie hält mehrere Stände vor — sagen wir 30 tägliche Voll-Backups. Jedes davon enthält die komplette, unoptimierte Media-Library:
| Posten | Unoptimiert | Optimiert |
|---|---|---|
| Originalbilder | ≈ 10,8 GB | ≈ 0,7 GB |
| + CMS-Größen (×2–3) | ≈ 20 GB | ≈ 1,3 GB |
| = Media-Library | ≈ 30 GB | ≈ 2 GB |
| × 30 tägliche Backups | ≈ 900 GB | ≈ 60 GB |
Fast ein Terabyte Backup-Speicher — für eine Website, deren sinnvoller Bildinhalt in 2 GB passt. Der Unterschied ist nicht theoretisch: Er steht auf der Rechnung des Backup-Speichers, verlängert jede Wiederherstellung und macht das „mal eben zurückspielen" zu einer Stundenaufgabe.
Deploy, Build und Repository
Bei modernen Projekten — Static-Site-Generatoren, JAMstack, Git-basierte Workflows — landen Bilder oft direkt im Repository. Das rächt sich doppelt. Erstens muss der Build bei jedem Deploy Gigabyte an Bildern kopieren, verarbeiten und hochladen; aus einem 30-Sekunden-Build wird ein Minuten-Marathon. Zweitens speichert Git jede Version jeder Binärdatei für immer — tauscht man ein 4-MB-Bild dreimal aus, liegen alle vier Fassungen dauerhaft in der Historie. Ein Repository, das einmal mit unoptimierten Bildern vollgelaufen ist, bekommt man nur mit invasiven History-Rewrites wieder schlank.
Der Bandbreiten-Posten
Und dann ist da noch der laufende Traffic. Wie im Rechenbeispiel gezeigt, summiert sich das bei realistischen Besuchszahlen auf über ein Terabyte ausgehenden Bild-Traffic pro Monat — gegenüber rund 72 GB im optimierten Fall. Bei jedem CDN, das Egress abrechnet, ist das ein wiederkehrender Posten, der linear mit dem Erfolg der Seite wächst. Ausgerechnet dann, wenn eine Seite gut läuft, wird der Bloat am teuersten.
Die Reibung im Team
Der letzte, oft unterschätzte Kostenpunkt ist Zeit. Ein Repository mit vielen Gigabyte an Bildern klont sich langsam, der lokale Entwicklungsserver startet träge, jeder neue Kollege wartet erst einmal beim ersten Checkout. Nichts davon ist dramatisch für sich — in Summe reibt es aber jeden Arbeitstag ein bisschen ab. Schlanke Projekte fühlen sich nicht nur für Besucher schneller an, sondern auch für die, die daran arbeiten.
Wo man ansetzt
Die wirksamste Regel ist die einfachste: Bilder werden optimiert, bevor sie ins System kommen, nicht danach. Wenn schon das Original in passender Größe und als modernes Format hochgeladen wird, entstehen alle abgeleiteten Fassungen, Backups und Repository-Einträge von vornherein schlank. Konkret:
- Vor dem Upload aufbereiten: auf die Zielgröße skalieren, in WebP/AVIF konvertieren und komprimieren — bei JNRT Pixel lokal im Browser, ohne Upload.
- Binärdateien aus dem Git-Repo halten und stattdessen über Media-Storage oder ein CDN ausliefern.
- Media-Library regelmäßig ausmisten — verwaiste Uploads und alte Varianten kosten Backup-Speicher, ohne je ausgeliefert zu werden.
Die Ladezeit ist der sichtbare Teil des Problems; der Speicher hinter den Kulissen der unsichtbare. Beide entstehen aus derselben Ursache — und beide lassen sich mit demselben Handgriff am Anfang der Kette vermeiden.
Quellen
HTTP Archive — Web Almanac, Page Weight · web.dev — Serve images in modern formats · Pro Git — Git Internals: Packfiles · MDN — Image file type and format guide.