WordPress 7.1 rechnet Bilder im Browser: JPEGs 15 Prozent leichter, kein PHP-Speicherlimit mehr beim Upload

Am 19. August erscheint WordPress 7.1, und das Release bringt eine Änderung, die viele Kunden-Websites unbemerkt schneller macht: Die Bildverarbeitung wandert vom Server in den Browser. Fotos werden mit einer WebAssembly-Version der Bildbibliothek libvips direkt im Endgerät verkleinert, gedreht, in Thumbnails geschnitten und formatkonvertiert, bevor auch nur ein einziges Byte an den Webhost geht.

Der praktische Effekt für Webdesigner ist zweiteilig. Erstens werden JPEGs laut Ankündigung von WordPress-Core-Entwickler Adam Silverstein um rund 15 Prozent kleiner als bei der bisherigen GD- oder Imagick-Verarbeitung, weil libvips mit einer MozJPEG-nahen Codierung arbeitet. Zweitens fällt eine Fehlerklasse weg, die bisher jeder aus Kundenprojekten kennt: der klassische Fatal error: Allowed memory size of X bytes exhausted, wenn ein Kunde ein 24-Megapixel-Foto aus der Kamera per Drag-and-Drop in die Mediathek zieht. Der Server sieht nur noch die fertigen, kleineren Dateien.

Was der Browser jetzt selbst erledigt

Die neue Pipeline unterstützt image/jpeg, image/png, image/gif, image/webp und image/avif. Interessant sind zwei automatische Konvertierungen im Hintergrund: animierte GIFs werden clientseitig in ein Autoplay-Video verwandelt (MP4 oder WebM, je nach Browser), was bei typischen Meme-GIFs die Dateigröße drastisch drückt. Und HEIC-Fotos, wie iPhones sie standardmäßig speichern, werden vor dem Upload in JPG umgewandelt. Das war bisher einer der häufigsten Uploader-Fehler in Redaktions-Zugängen.

Bis zu fünf Uploads laufen parallel, zwei davon werden gleichzeitig verarbeitet. AVIF funktioniert auch dann, wenn die Server-Bildbibliothek gar keine AVIF-Unterstützung mitbringt, weil der Browser die Umwandlung übernimmt.

Wo Firefox und Safari heute noch aussteigen

Die WebAssembly-Pipeline setzt den Document-Isolation-Policy-Header voraus, den zum Release-Zeitpunkt nur Chrome 137+ und Microsoft Edge 137+ auf dem Desktop vollständig umsetzen. Auf Firefox und Safari greift WordPress automatisch auf die alte serverseitige Verarbeitung zurück, ohne dass die Redakteurin im Backend etwas merkt. Für die Praxis heißt das: der Performance-Gewinn kommt vor allem denen zugute, die im Chrome-Backend arbeiten, während Kunden mit Safari- oder Firefox-Workflow das gewohnte Verhalten behalten. Kein Regressions-Risiko, aber auch kein garantierter Uplift für jeden.

Was Plugin- und Theme-Entwickler jetzt prüfen sollten

Der Hook wp_generate_attachment_metadata feuert in der neuen Pipeline zweimal pro Upload, einmal für die clientseitig erzeugten Thumbnails (Kontext create) und einmal, wenn der Server die Metadaten final schreibt (Kontext update). Wer bisher davon ausging, dass dieser Filter einmal pro Bild läuft, riskiert doppelte Watermarks, doppelte KI-Analysen oder doppelte Uploads in ein externes CDN. Die Empfehlung aus dem Core-Team ist eindeutig: eigene Metadaten-Filter idempotent bauen.

Wer strenge Content-Security-Policies fährt, muss worker-src 'self' blob:; ergänzen, sonst startet der wasm-vips-Worker gar nicht erst und WordPress fällt still auf die Server-Variante zurück.

Was das für Webdesigner bedeutet

Für den Wartungsalltag von Agenturen ändert sich mit 7.1 nichts, was aktiv umgestellt werden müsste. Die Verlagerung passiert transparent, das Feature ist standardmäßig aktiv. Zwei Dinge lohnen sich trotzdem: die eigenen Custom-Plugins auf den doppelten Filter-Aufruf hin gegenprüfen, und Kunden, die klagen, ihre iPhone-Fotos ließen sich nie hochladen, kurz auf Chrome umbiegen. Für Agenturen, die aktiv neue Webdesign-Kunden gewinnen, ist die Neuerung außerdem ein ehrlicher Verkaufspunkt: WordPress-Sites werden auf modernen Redakteurs-Setups von Haus aus schlanker, ganz ohne Zusatz-Plugin für Bildkompression.

Das Fazit

WordPress 7.1 bringt keine sichtbaren neuen Buttons für Endkunden, aber eine Architektur-Verschiebung mit langer Halbwertszeit. Sobald Firefox und Safari die nötigen Header umsetzen, verschwindet die serverseitige Bildpipeline in vielen Setups komplett. Bis dahin gilt: die 15 Prozent JPEG-Ersparnis sind gratis, sofern das Backend in Chrome oder Edge geöffnet wird, und der lästige Memory-Limit-Fehler beim Foto-Upload ist auf modernen Redaktions-Workflows Geschichte.