375 MB Bilder, die niemand brauchte
Geschätzte Lesezeit: 5 Minuten
Wichtigste Erkenntnisse
– Härtung erzeugt unsichtbare Abhängigkeiten.
– Stiller Rückfall kann schlimmer sein als ein Fehler.
– Ladezeit ist oft nicht die einzige Ursache für Probleme.
Inhaltsverzeichnis
1. Der Messwert, der nicht stimmen konnte
2. Die Regel war noch da
3. Was passiert war
4. Die Reparatur
5. Zwei Details, die den Unterschied machen
6. Was ich daraus mitnehme
7. FAQ
Der Messwert, der nicht stimmen konnte
Der erste Blick ging auf die Ladezeit. Das Ergebnis für die Startseite, mobil gemessen:
| Messwert | Wert |
|---|---|
| Largest Contentful Paint | 8,3 Sekunden |
| Bilder gesamt | 2,6 MB |
| davon vermeidbar | 2,37 MB |
8,3 Sekunden. Das ist die Zeit, bis das größte sichtbare Element fertig geladen ist — und der Wert, bei dem Besucher längst wieder weg sind. Die Ursache stand direkt daneben: unkomprimierte PNG-Dateien. Jedes Beitragsbild zwischen 340 KB und 2,7 MB, insgesamt 706 PNG-Dateien mit 389 MB.
Das kannte ich. Ich hatte das gelöst. Vor Monaten, als ich mein eigener Mail-Server lief und ich merkte, wie wichtig performante Systeme sind.
Die Regel war noch da
In der Serverkonfiguration steht seit langem ein Block, der genau dafür gebaut ist. Er prüft, ob der Browser moderne Bildformate versteht, und liefert ihm dann eine kleinere Variante aus:
try_files /wp-content/uploads-webpc/$path.$ext$ext_avif
/wp-content/uploads-webpc/$path.$ext$ext_webp
$uri =404;
Der Ablauf ist elegant. Kommt ein moderner Browser, bekommt er die schlanke Fassung. Kommt ein alter, bekommt er das Original. Die Adresse bleibt in beiden Fällen identisch — kein Redirect, keine geänderten Links, kein Eingriff ins Content-Management-System.
Die Regel war intakt. Sie war korrekt. Sie wurde bei jedem Bildaufruf ausgeführt. Sie fand nur nichts.
Was passiert war
Das Verzeichnis uploads-webpc existierte nicht. Nicht leer — gar nicht. Erzeugt wurden diese Dateien von einer Erweiterung im Content-Management-System. Und die war weg. Ich hatte sie selbst entfernt, Wochen zuvor, nach einem Einbruch auf dem Server. Damals habe ich radikal aufgeräumt und sämtliche Erweiterungen gelöscht, um die Angriffsfläche zu verkleinern. Von über 9000 auf knapp 1500 Dateien.
Diese Entscheidung war richtig und würde ich wieder so treffen. Was ich dabei übersehen habe: Eine dieser Erweiterungen war nicht nur ein Feature. Sie war der Zulieferer für eine Regel, die an ganz anderer Stelle steht und die ich nie angefasst habe.
Und weil try_files am Ende auf $uri zurückfällt — also auf das Original — hat nichts einen Fehler gemeldet. Kein 404, kein defektes Bild, kein Eintrag im Log. Die Seite sah aus wie immer. Sie war nur zehnmal so schwer.
Das ist die Sorte Fehler, die man nicht findet, weil sie sich als Normalzustand tarnt.
Die Reparatur
Kein Eingriff in die Konfiguration nötig. Es fehlten ja nur die Dateien.
Ein Skript, das zu jeder Bilddatei eine Variante im erwarteten Layout ablegt:
wp-content/uploads/2026/08/Bild.png -> wp-content/uploads-webpc/uploads/2026/08/Bild.png.webp
Umgesetzt mit cwebp bei Qualität 82, absichtlich wiederholbar: vorhandene und aktuelle Dateien werden übersprungen. Und mit einer kleinen Sicherung, die mir wichtig war — wird die neue Variante nicht kleiner als das Original, fliegt sie wieder weg. Bei Bildern mit wenigen Farben kann das passieren, und dann wäre sie schlicht schädlich.
Das Ergebnis kam schneller, als ich erwartet hatte.
| Konvertiert | 904 Dateien in 80 Sekunden |
| Fehler | 0 |
| Eingespart | 375 MB |
| Zusätzlicher Speicher | 37 MB |
Und am konkreten Beispiel des größten Bildes auf der Startseite:
| Original | 526 KiB PNG |
| Neue Variante | 41 KiB |
| Ersparnis | 92 Prozent |
Auf Seitenebene: Startseite von 1,12 auf 0,09 MB Bildlast, ein Artikel von 2,79 auf 0,19 MB. Rund 93 Prozent weniger, ohne dass sich eine einzige Adresse geändert hätte.
Ein Cronjob alle 15 Minuten fängt neue Bilder ab. Der Leerlauf dauert 0,85 Sekunden bei 910 Dateien.
Zwei Details, die den Unterschied machen
Der `Vary: Accept`-Header muss gesetzt sein. Ohne ihn liefert jeder zwischengeschaltete Cache die Variante aus, die er zufällig zuerst gesehen hat — moderne Browser bekommen dann das Original, alte bekommen ein Format, das sie nicht anzeigen können. Bei meiner Konfiguration war er drin. Wer so etwas selbst baut, sollte das prüfen, bevor er sich über kaputte Bilder wundert.
Die Originale bleiben liegen. Alte Browser, Bildbearbeitungsprogramme und manche Vorschaufunktionen wollen sie. Der Platzgewinn entsteht bei der Übertragung, nicht auf der Platte — im Gegenteil, es kommen 37 MB dazu. Das ist der Preis und er ist es wert.
Was ich daraus mitnehme
Härtung erzeugt Abhängigkeiten, die man nicht sieht. Wenn man Software entfernt, denkt man an das, was sie tut. Nicht an das, was sie für etwas anderes bereitstellt. Bei mir war es ein Verzeichnis, auf das eine Regel in einer völlig anderen Datei zeigte, die ich beim Aufräumen nie geöffnet habe.
Stiller Rückfall ist schlimmer als ein Fehler. Hätte die Regel bei fehlender Datei einen 404 geliefert, wäre es am selben Tag aufgefallen. Der elegante Rückfall auf das Original hat den Ausfall wochenlang unsichtbar gemacht. Beim Entwerfen solcher Ketten lohnt sich die Frage: Wie merke ich, dass der bevorzugte Weg gar nicht mehr genommen wird? Das erinnert mich an meine Überlegungen, warum ein Homelab mit Solarstrom sinnvoll ist – eine gute Planung schließt solche versteckten Fehlerquellen aus.
Und der ursprüngliche Anlass? Der hat sich nicht erledigt. Ladezeit war nicht der Grund für die fehlenden Klicks, sie war nur das Erste, worauf ich gestoßen bin. Die eigentliche Ursache steckt woanders, und darüber schreibe ich noch.
Aber 375 MB weniger sind trotzdem 375 MB weniger. Und ein Wert von 8,3 Sekunden war ohnehin nicht zu halten.
FAQ
Was sind unkomprimierte PNG-Dateien? – Unerwünschte Bilder in Größen, die lange Ladezeiten verursachen können.
Wie kann ich die Ladezeiten meiner Seite verbessern? – Durch die Optimierung von Bildformaten und die Überprüfung von Servereinstellungen.
