Wenn Backups von WordPress-Websites ewig dauern und riesige Dateien generieren, dann ist die Wahrscheinlichkeit gross, dass das Verzeichnis /wp-content/uploads/ dafür verantwortlich ist. Hier liegen die Bilder, die man in die Mediathek hochgeladen hat, und oft sind diese viel zu gross. Die Ursachen sind vielfältig: falsches Dateiformat, ungenügende Kompression oder zu hohe Auflösung.
Gegen letzteres hat WordPress 5.3 den Big Image Size Threshold eingeführt, der eine maximale Breite bzw. Höhe von 2’560 Pixeln vorgibt. Überschreitet ein Bild diesen Wert, wird es nach dem Hochladen automatisch auf diese Auflösung heruntergerechnet. Das Problem dabei ist: Das übergrosse Orginal liegt weiterhin im Uploads-Ordner, ohne dass man es sehen oder löschen könnte.
Ein Beispiel aus der Praxis
Wir haben nicht schlecht gestaunt, als wir uns die Website-Backups eines unserer Kunden genauer angesehen haben: 2.5 GByte gross war ein solches Backup. (Zum Vergleich: Das Backup unserer eigenen Website ist 550 MByte gross.) Nun war das zwar eine relativ umfangreiche Website mit über 100 Seiten in drei Sprachen, vielen Bildern und einer Produktdatenbank, aber 2.5 GByte sind trotzdem weit mehr als bei jedem anderen Kunden.
Die Ursache war schnell eingegrenzt: 2.3 GByte gross war allein das Backup des Verzeichnisses /wp-content/uploads/. Hier liegen alle Dateien, die via Mediathek hochgeladen werden: Bilder, Videos, Audiodateien, PDF-Dokumente. Bei diesem Kunden waren es fast ausschliesslich Bilder, und zwar stattliche 660 Stück. Aber ist das wirklich eine ausreichende Erklärung für ein derart umfangreiches Backup?
Machen wir kurz die Rechnung: 2.3 GByte geteilt durch 660 Bilder ergibt durchschnittlich 3.5 MByte pro Bild. Das ist heftig, wenn man von einer idealen Bildgrösse im Bereich von 50 KByte bis 250 KByte ausgeht. Wenn man sich allerdings das Frontend der Website anschaut, dann findet man dort keine Bilder, die auch nur annähernd 3.5 MByte gross wären. Wie passt das nun zusammen?
Auch Tumbnails belegen Speicherplatz
Zunächst muss man wissen, dass WordPress von jedem hochgeladenen Bild automatisch mehrere Versionen mit unterschiedlichen Auflösungen generiert, sogenannte Thumbnails. Dadurch hat man verschiedene Auflösungen zur Auswahl, wenn man ein Bild in eine Webpage einfügen möchte:
Diese unterschiedlichen Auflösungen belegen natürlich ebenfalls Speicherplatz. Und je nach dem, wie eine Website konfiguriert ist, werden noch weitere Auflösungen als nur die oben gezeigten Standard-Grössen generiert. In der Summe kann so ein Bild durch die generierten Thumbnails schnell doppelt so viel Speicherplatz belegen wie die Ursprungsdatei. Das erklärt aber noch nicht, warum bei unserem Kunden ein Bild durchschnittlich 3.5 MByte belegt.
Das Dateiformat ist entscheidend
In unserem Artikel über das Bildbearbeitungsprogramm RapidRAW haben wir ausführlich über die verschiedenen Dateiformate gesprochen. Dort haben wir auch gezeigt, wie man Fotos im JPEG- bzw. WebP-Format komprimieren und so die Dateigrössen massiv reduzieren kann.
Ein Blick in die Mediathek unseres Kunden zeigt, dass viele Fotos als PNG-Dateien hochgeladen wurden. PNG eignet sich gut für Grafiken wie beispielsweise Logos oder Icons, ist aber völlig ineffizient, sobald es um Fotos geht, wie das folgende Beispiel zeigt.
Dateigrössen in Abhängigkeit von Dateiformat und Auflösung
| Auflösung | PNG | WebP * |
| 2400 x 1800 px | 10.1 MB | 671 KB |
| 1920 x 1440 px | 6.79 MB | 486 KB |
| 1600 x 1200 px | 4.86 MB | 357 KB |
| 1200 x 900 px | 2.81 MB | 211 KB |
| 900 x 675 px | 1.59 MB | 122 KB |
* Qualitätsstufe 50%
Über den Daumen gepeilt kann man also bei gleicher Auflösung und vergleichbarer Qualität rund 90 Prozent Speicherplatz sparen, indem man Website-Fotos nicht als PNG-Datei, sondern als vernünftig komprimierte WebP-Datei hochlädt. Diese Einsparung wirkt sich auch bei den Thumbnails aus, zumal diese immer im gleichen Dateiformat erstellt werden wie die Originaldatei.
Der Effekt des Big Image Size Threshold
Kommen wir nun zum eigentlichen Thema dieses Artikels, dem Big Image Size Threshold. Seit der Version 5.3 gibt es in WordPress einen Mechanismus, der verhindern soll, dass Bilder mit einer zu hohen Auflösung publiziert werden. Bilder dürfen standardmässig maximal 2’560 Pixel breit und hoch sein, wobei dieser Wert mit ein paar Zeilen Code über den Filter big_image_size_threshold bei Bedarf angepasst werden kann.
Diese Massnahme ist grundsätzlich sinnvoll. Ein zeitgemässes Smartphone mit 12-Megapixel-Kamera erzeugt Bilder mit einer Auflösung von 4’032 x 3’024 Pixel. Wenn solche Bilder auf einer Website publiziert werden, wird diese deutlich langsamer, weil viel mehr Daten übertragen werden müssen. Und weil man auf einer Website selten so hohe Auflösungen benötigt, ist es richtig, dass WordPress hier einen Riegel schiebt.
Problematisch ist einzig die Art und Weise, wie das geschieht. Wenn man ein Bild mit einer zu hohen Auflösung in die Mediathek lädt, wird das weder blockiert noch gibt es eine Warnung. Es wird lediglich eine zusätzliche Datei mit der maximal zulässigen Auflösung generiert, die den Zusatz -scaled im Dateinamen erhält und dann als «Originalgrösse» in der Bildgrössenauswahl auftaucht.
Damit ist zwar sichergestellt, dass keine übergrossen Bilder auf der Website veröffentlicht werden. Die Ursprungsdatei liegt aber weiterhin im Verzeichnis /wp-content/uploads/ und belegt dort Speicher. Als Content Manager bekommt man das aber nicht mit, und WordPress bietet auch keine Möglichkeit diese Datei zu löschen.
Die Auswirkungen in der Praxis
Schauen wir uns nun in der Praxis an, wie sich das alles auf unseren Speicherplatzbedarf auswirkt. Dazu laden wir unser Testbild in einer Auflösung von 3’200 x 2’400 Pixel als PNG-Datei in die Mediathek. Wenn wir dann mit einem FTP-Client einen Blick in das Verzeichnis /wp-content/uploads/ werfen, sehen wir folgendes:
Obwohl wir nur ein einziges Foto hochgeladen haben, liegen nun auf unserem Webserver 18 Dateien mit einer Gesamtgrösse von mehr als 50 MByte. Dabei spielen drei Faktoren eine Rolle:
- Weil unser Testbild breiter ist als der Big Image Size Threshold, wurde die Datei
testbild-scaled.pngerzeugt, die WordPress fortan in der Mediathek anzeigt. Die Ursprungsdateitestbild.pngwird unter normalen Umständen nicht mehr gebraucht, belegt aber weiterhin fast 14 MByte Speicherplatz. - Diese Website erzeugt weit mehr Thumbnails als nur die Standardgrössen «Vorschaubild», «Mittel» und «Gross». Leider ist auch das im WordPress-Backend nicht erkennbar, denn unter Einstellungen » Medien lassen sich nur die Abmessungen der Standardgrössen konfigurieren. Wenn hingegen ein Theme, Plug-in oder Code Snippet zusätzliche Bildgrössen registriert, sieht man das nicht, sofern man nicht ein Plug-in wie Simple Image Sizes installiert. Im vorliegenden Fall werden die meisten zusätzlichen Bildgrössen durch das Divi-Theme registriert, und in der Summe beanspruchen diese ebenfalls ordentlich Speicherplatz, insbesondere die höheren Auflösungen. Dermassen fein abgestufte Bildgrössen sind unserer Meinung nach überflüssig.
- Wie bereits besprochen ist das PNG-Format bei Fotos ausgesprochen ineffizient: Selbst wenn wir das JPEG-Format mit einer Qualitätsstufe von 100 Prozent gewählt hätten, wären die 18 Dateien zusammen nur knapp 13 MByte Speicherplatz gross, also grob gerechnet ein Viertel. Und hätten wir das Ursprungsbild im WebP-Format mit einer Qualitätsstufe von 50 Prozent hochgeladen, wären wir bei 6.3 MByte gelandet, also bei rund einem Zehntel.
Wie man Big Images löschen kann
Kommen wir nochmals auf unsere Ursprungsdatei testbild.png mit einer Auflösung von 3’200 x 2’400 Pixel zurück. Wie können wir sie vom Webserver löschen, um Speicherplatz zu sparen?
Leider gibt es dafür keine ganz einfache Lösung. In der Mediathek gibt es nämlich keine Funktion, um gezielt solche Big Images anzuzeigen. Sie können lediglich nach Dateien mit «scaled» im Dateinamen suchen, um einen Eindruck davon zu gewinnen, wieviele solche übergrossen Bilder auf ihrem Server schlummern. Aber sie können weder die Dateigrösse der Ursprungsdateien sehen noch diese löschen.
Auch der Weg über einen FTP-Client ist nicht zu empfehlen. Erstens ist es relativ mühsam, die entsprechenden Dateien zu finden, zumal WordPress seine Mediendateien in einer Ordnerstruktur ablegt, die nach Jahren und Monaten gegliedert ist. Und zweitens löschen Sie in diesem Fall nur die Datei, nicht aber den entsprechenden Datenbankeintrag in der Tabelle wp_postmeta, wo unter dem Meta Key _wp_attachment_metadata der Dateiname des original_image hinterlegt ist.
Bei der Suche nach einem geeigneten Plug-in sind wir auf Delete Unscaled Images gestossen. Dieses bietet grundsätzlich die gewünschte Funktionalität, ist aber wenig auskunftsfreudig: Man kann lediglich sämtlich übergrossen Bilder löschen, ohne zu sehen, welche dies sind.
Für unseren Kunden haben wir deshalb ein eigenes Plug-in entwickelt, mit dem man Big Images zuerst sehen und dann einzeln entfernen kann. Zudem werden die Dateien nicht direkt gelöscht, sondern in einen speziellen Ordner verschoben, den man ggf. noch archivieren kann.
Wenn Sie den Aufwand nicht scheuen, dann gibt es allerdings eine einfachere und letztlich bessere Lösung: Löschen Sie Bilder mit «scaled» im Dateinamen komplett aus der Mediathek und laden sie diese nochmals in einer vernünftigen Auflösung hoch.