WordPress behält mehrere Kopien jedes Bildes und optimiert keine davon

Lade ein Foto in WordPress hoch und du bekommst nicht eine Datei. Du bekommst ein Thumbnail, eine mittlere, eine mittelgroße, eine große, die volle Größe und alle zusätzlichen Größen, die dein Theme und dein Page-Builder registriert haben. Sechs oder acht Dateien aus einem Upload sind normal. Jede wird in WordPress’ JPEG-Standardqualität neu kodiert und danach nie wieder angefasst.

Multipliziere das über ein paar Jahre Beiträge und der Uploads-Ordner ist meist das Größte in deinem Backup und der langsamste Teil deiner Seiten. Der Großteil dieses Gewichts ist vermeidbar.

Wo das Gewicht wirklich steckt

Es sind die JPEGs. Fotos dominieren eine typische Mediathek, und WordPress kodiert sie mit fester Qualität (standardmäßig 82) mit einem alten Encoder. Das ist eine vernünftige, sichere Voreinstellung, keine kleine Datei. Screenshots und Logos, die als PNG gespeichert sind, kommen noch dazu, denn PNG ist für viele davon der falsche Container.

Es gibt zwei ehrliche Wege, das zu verkleinern, und sie haben unterschiedliche Kompromisse.

1. An Ort und Stelle neu kodieren

Nimm jede erzeugte Größe und kodiere sie in eine kleinere Version desselben Formats: JPEG bleibt JPEG, WebP bleibt WebP. Ein moderner Encoder holt aus einem WordPress-Standard-JPEG etwa ein Fünftel bis ein Viertel heraus, ohne sichtbare Änderung.

Der Reiz: Nichts anderes auf deiner Seite bemerkt es. Dateiname, Abmessungen und Endung sind identisch, also funktioniert jede URL weiter, in jedem Theme, auf jeder gecachten Seite, in jedem fest verdrahteten <img>. Es ist die langweilige, sichere Option, und für viele Seiten ist sie die richtige.

Was sie nicht tut: das Format ändern. Ein JPEG bleibt ein JPEG, du bekommst also nicht die größeren Gewinne, die dir ein neueres Format bringen würde.

2. Next-Gen-Formate ausliefern

Erzeuge ein AVIF (und ein WebP) neben jedem Original und liefere es über ein <picture>-Tag aus, wobei das originale JPEG oder PNG als Fallback für ältere Browser bleibt. Hier stecken die echten Einsparungen: bei gleicher Qualität braucht AVIF weit weniger Bytes als JPEG, und es deckt endlich auch deine PNGs ab. Wir haben den Abstand über rund 1.900 Fotos gemessen, falls du die Zahlen willst.

Die ehrlichen Einschränkungen, denn es gibt welche:

• Es schreibt das Seiten-HTML um, was es Theme-unabhängig macht, aber es fasst nur <img>-Tags an. Ein background-image in CSS wird nicht ausgetauscht.
• Ein JavaScript-Lazyloader, der src zur Laufzeit umschreibt, kann es verpassen. Natives loading="lazy" ist in Ordnung.
• GIF wird noch nicht abgedeckt.

Die Originale bleiben genau dort, wo sie sind, es geht also nichts verloren, und Browser, die kein AVIF lesen können, fallen auf die Datei zurück, die sie schon verstanden haben.

Worüber sich Leute wirklich Sorgen machen

Beide Ansätze behalten ein Backup jedes Originals, jedes Bild lässt sich also mit einem Klick auf seine exakten Bytes zurücksetzen. Eine Datei wird nur dann ersetzt, wenn die neue strikt kleiner ist, es wird also nichts größer. Und wenn eine Optimierung fehlschlägt, wird sie übersprungen, nicht fatal: dein Upload hängt nie und ein Bild bleibt nie halb geschrieben.

Es umsetzen

Genau das macht Patu Optimizer. Neue Uploads werden automatisch optimiert, ein einziger Massendurchlauf erledigt alles, was schon in der Mediathek liegt, und du wählst pro Seite zwischen an Ort und Stelle oder Next-Gen. Es läuft über die Patu-API, die Kodierung passiert also außerhalb deines Servers. Ein kostenloser Schlüssel reicht zum Start.

Beginne mit an Ort und Stelle, wenn du null Überraschungen willst. Greif zu Next-Gen, wenn du die Bytes willst und deine Seiten normale <img>-Tags verwenden. So oder so ist das Ziel dasselbe: aufhören, eine Mediathek auszuliefern, die zwei- oder dreimal schwerer ist als nötig.