Das Problem, das im Editor niemand sieht
In fast jedem Web-Projekt, das ich über die Jahre begleitet habe, war am Ende dieselbe Komponente für den Löwenanteil des Seitengewichts verantwortlich: die Bilder. Nicht das JavaScript, nicht die Schriften, nicht das CSS — die Bilder. Das Tückische daran ist, dass man es beim Pflegen der Inhalte nicht merkt. Man zieht ein Foto aus dem Kamera-Export in den CMS-Editor, es sieht gut aus, man klickt auf „Veröffentlichen". Dass diese eine Datei 4,2 MB wiegt, steht nirgends im Blickfeld.
Über eine einzelne Seite hinweg fällt das kaum auf. Erst wenn man es über ein ganzes Projekt hochrechnet, wird die Größenordnung sichtbar — und genau das will ich hier tun, mit einer bewusst nüchternen Beispielrechnung. Der Median einer Webseite liegt laut den jährlichen Auswertungen des HTTP Archive seit Jahren im Megabyte-Bereich, und der größte Einzelposten sind praktisch immer die Medien. Die folgende Rechnung zeigt, warum.
Die Beispielrechnung: 1200 Seiten, 3 Bilder, 1–5 MB
Nehmen wir eine mittelgroße Website an — ein Unternehmensauftritt mit Blog, ein Reiseportal, ein Vereins- oder Immobilien-Katalog: 1200 Seiten, auf jeder im Schnitt 3 Bilder. Die Bilder kommen direkt aus Kamera, Handy oder Stockportal und wiegen unbearbeitet zwischen 1 und 5 MB. Das sind zusammen 1200 × 3 = 3600 Bilder. Je nach durchschnittlicher Dateigröße ergibt das:
| Ø Bildgröße | Bilder gesamt | Speicher gesamt |
|---|---|---|
| 1 MB (beste Annahme) | 3.600 | 3.600 MB ≈ 3,6 GB |
| 3 MB (realistischer Mittelwert) | 3.600 | 10.800 MB ≈ 10,8 GB |
| 5 MB (schlechteste Annahme) | 3.600 | 18.000 MB ≈ 18 GB |
Schon der Mittelwert liegt bei rund 10,8 GB reinem Bild-Datenbestand — und das ist nur das, was auf dem Server liegt. Kein CSS, kein Code, keine Backups, keine Thumbnails, keine Retina-Zweitfassungen. Nur die Originalbilder. In der Praxis produzieren die meisten CMS pro Upload noch mehrere zusätzliche Bildgrößen (Thumbnail, Medium, Large), sodass sich der tatsächliche Speicher gern verdoppelt bis verdreifacht.
Was diese Zahl pro Seite bedeutet
Interessanter als der Gesamtspeicher ist für den Nutzer das Gewicht einer einzelnen Seite. Drei Bilder à 3 MB sind 9 MB allein an Bilddaten, die der Browser laden muss, bevor die Seite fertig ist. Zum Vergleich: Googles Zielwert für den Largest Contentful Paint liegt bei 2,5 Sekunden. Eine einzige 3-MB-Hero-Grafik reißt diesen Wert auf einer durchschnittlichen mobilen Verbindung im Alleingang.
Rechnen wir es durch: Auf einer typischen 4G-Verbindung mit real nutzbaren ~10 Mbit/s dauert die Übertragung von 9 MB rund 7 Sekunden — nur für die Bilder, ohne Verbindungsaufbau, ohne den Rest der Seite. Auf einem gedrosselten Tarif oder in einem vollen Zug wird daraus schnell das Doppelte. Genau in dieser Zeitspanne springt ein erheblicher Teil der Besucher wieder ab, und das ist keine Vermutung, sondern seit Jahren gut dokumentiert. Mehr dazu im Beitrag Ladezeit optimieren.
Der Traffic-Multiplikator, den man leicht übersieht
Speicher ist einmalig — Traffic fällt bei jedem Seitenaufruf erneut an. Nehmen wir bescheidene 100 Besuche pro Seite und Monat an und lassen den Cache außen vor (erste Besuche, wechselnde Nutzer, mobile Verbindungen ohne aufgewärmten Cache):
1200 Seiten × 100 Besuche × 9 MB ≈ 1.080.000 MB ≈ 1,08 TB Bild-Traffic pro Monat. Bei einem CDN, das ausgehenden Traffic abrechnet, ist das ein realer Posten auf der Rechnung — und er wächst linear mit den Besuchern. Dieselbe Website mit optimierten Bildern läge bei rund 72 GB. Der Unterschied ist nicht kosmetisch, er ist der Faktor, um den die Infrastrukturkosten steigen.
Die Gegenrechnung: dieselbe Website, sauber optimiert
Jetzt der andere Fall — dieselben 3600 Bilder, aber vor dem Einbinden korrekt aufbereitet: auf die tatsächlich angezeigte Größe skaliert, als WebP oder AVIF exportiert und vernünftig komprimiert. Ein großformatiges Inhaltsbild landet damit realistisch bei 150–300 KB statt bei mehreren Megabyte. Rechnen wir konservativ mit 200 KB:
| Variante | Ø pro Bild | Gesamt (3600 Bilder) | pro Seite |
|---|---|---|---|
| Unoptimiert | 3 MB | ≈ 10,8 GB | ≈ 9 MB |
| Optimiert | 0,2 MB | ≈ 0,72 GB | ≈ 0,6 MB |
Aus 10,8 GB werden rund 0,7 GB — ein Faktor von etwa 15, gut 10 GB gespart, bei einem Bildeindruck, den kaum ein Besucher vom Original unterscheiden kann. Der monatliche Bild-Traffic sinkt im gleichen Verhältnis von ~1,08 TB auf ~72 GB, und die 9-MB-Seite lädt ihre Bilder statt in 7 Sekunden in unter einer halben. Das ist der ganze Hebel — und er kostet keine neue Server-Hardware, sondern einen Schritt im Workflow.
Woher der Bloat kommt — aus der Praxis
Warum passiert das so oft? In den Projekten, die ich gesehen habe, waren es fast immer dieselben vier Ursachen, und keine davon ist böser Wille:
- Originalauflösung im Slot. Ein 6000-×-4000-Pixel-Foto aus der Kamera landet in einem Container, der auf dem Bildschirm 800 Pixel breit ist. Der Browser skaliert herunter — lädt aber die volle Datei. Das ist der mit Abstand häufigste Fall.
- Falsches Format. Fotos als PNG gespeichert, weil „PNG ja hochwertig ist". Für Fotos ist PNG fast immer die größte und schlechteste Wahl — mehr dazu im Formate-Vergleich.
- Kein modernes Format. JPG statt WebP/AVIF. Allein der Formatwechsel spart bei gleichem Aussehen oft 30–50 %.
- Retina-Missverständnis. Das Original wird „für scharfe Displays" unverändert eingebunden, statt gezielt eine 2×-Fassung in passender Größe zu liefern. Wie man das richtig macht, steht unter Retina-Bilder optimieren.
Was ich Projekten empfehle
Die gute Nachricht: Man muss dafür kein Bildbearbeitungsprogramm beherrschen und nichts hochladen. Der Ablauf, der in der Praxis den größten Effekt hat, ist schlicht:
- Auf die Anzeigegröße skalieren. Braucht der Slot 1200 Pixel, exportiere 1200 (bzw. 2400 für Retina) — nicht 6000. Dafür reicht das Skalieren-Tool.
- Ins richtige Format wandeln. Fotos nach WebP oder AVIF über den Konverter.
- Komprimieren mit Augenmaß. Qualität um 75–82 ist meist der Sweet Spot — über den Komprimierer in Sekunden erledigt.
- Technisch sauber einbinden.
loading="lazy"für alles unter dem Fold,srcset/sizesfür passgenaue Auslieferung. Der komplette Web-Ablauf steht im Komprimier-Leitfaden.
Bei JNRT Pixel läuft jeder dieser Schritte lokal im Browser — die Bilder verlassen dein Gerät nicht, und ob 3 oder 3600 Dateien: für uns kostet das nichts, weil dein Rechner rechnet. Genau deshalb halte ich die Beispielrechnung oben für so lohnend: Der Aufwand steht in keinem Verhältnis zu den gesparten Gigabyte.
Quellen
HTTP Archive — Web Almanac, Page Weight · web.dev — Optimize Largest Contentful Paint · web.dev — Serve images in modern formats · MDN — Lazy loading (img loading).