WordPress 7.1 verändert einen Arbeitsschritt, den viele Redaktionen kaum wahrnehmen: Nach dem Bild-Upload sollen Komprimierung, Größenberechnung, Formatkonvertierung, Drehung und Thumbnail-Erzeugung in unterstützten Browsern stattfinden. Statt jede Variante mit GD oder Imagick auf dem Webserver zu erzeugen, verarbeitet WebAssembly die Datei auf dem Gerät der Redakteurin oder des Redakteurs. Erst danach werden Original und Untergrößen in die Mediathek übertragen.

Die neue WordPress-7.1-Bildverarbeitung klingt nach einer reinen Performanceverbesserung. Für österreichische Website-Betreiber ist sie aber auch ein Anlass, den Medienworkflow vor dem geplanten Release am 19. August zu testen. Denn Browser, Content Security Policy, CDN-Plugins, Wasserzeichen, eigene Bildgrößen und externe Medien können unterschiedliche Pfade auslösen. Wer nur einen erfolgreichen JPEG-Upload im eigenen Chrome prüft, hat noch keinen belastbaren Freigabetest.

Der wichtige Status: WordPress 7.1 ist noch eine Beta

WordPress.org hat am 22. Juli Beta 3 veröffentlicht. Diese Vorabversion ist ausdrücklich für Entwicklung und Tests gedacht, nicht für produktive oder geschäftskritische Websites. Der finale Release ist für den 19. August geplant. Bis dahin können Fehler behoben und Details angepasst werden. Der richtige operative Schritt lautet deshalb nicht „sofort aktualisieren“, sondern „jetzt auf einer Testumgebung vorbereiten“.

Das ist besonders wichtig, wenn Bilder für Verkauf, Buchungen oder Veröffentlichungen zentral sind. Tourismusbetriebe laden Zimmerfotos hoch, Restaurants veröffentlichen Tagesgerichte, Ordinationen pflegen Team- und Praxisbilder, Händler importieren Produktfotos. Ein Medienfehler betrifft dann nicht nur die Mediathek, sondern Kategorieseiten, Vorschaubilder, Social Shares, Suchergebnisse und den mobilen Seitenaufbau.

Was WordPress künftig im Browser erledigt

Der bisherige Standardweg ist serverzentriert: WordPress empfängt das Original und erzeugt mit einer PHP-Bildbibliothek die registrierten Untergrößen. Große Dateien können dabei Speicherlimits oder Zeitüberschreitungen auslösen. Außerdem hängt das Ergebnis davon ab, welche Bibliothek und welche Formatunterstützung der jeweilige Hostingserver bietet.

WordPress 7.1 verlagert diese Verarbeitung in kompatiblen Browsern in einen Web Worker. Zum Einsatz kommt wasm-vips, eine WebAssembly-Variante von libvips. Der Browser komprimiert, skaliert, schneidet, dreht und konvertiert Bilder, erzeugt die benötigten Untergrößen und lädt die Dateien anschließend einzeln hoch. Ein abschließender REST-Aufruf vervollständigt die Attachment-Metadaten auf dem Server.

Die offizielle Entwicklerdokumentation nennt unter anderem folgende Funktionen:

  • Komprimierung und Größenberechnung für JPEG, PNG, WebP, AVIF und GIF,
  • EXIF-Drehung und progressive beziehungsweise interlaced Kodierung,
  • HEIC- und HEIF-Konvertierung zu einem webtauglichen JPEG,
  • Erzeugung aller registrierten WordPress-Bildgrößen im Browser,
  • Unterstützung von AVIF und HDR-Gain-Maps auch ohne entsprechende Serverbibliothek,
  • automatische Wiederholungen einzelner Uploads bei vorübergehenden Netzwerkfehlern und
  • einen transparenten Rückfall auf die bisherige Serververarbeitung, wenn Voraussetzungen fehlen.

Der Nutzen ist real, aber anders als viele erwarten

Die wichtigste Entlastung entsteht auf dem Server. PHP muss nicht mehr jede Untergröße berechnen, wodurch weniger CPU und Arbeitsspeicher für den Upload benötigt werden. WordPress nennt außerdem rund 15 Prozent kleinere JPEG-Ausgaben im Vergleich zu typischen GD- oder Imagick-Ergebnissen. Das kann die ausgelieferten Dateien reduzieren und damit Besucherinnen und Besuchern zugutekommen.

Beim Hochladen selbst sinkt die übertragene Datenmenge jedoch nicht automatisch. Der Browser sendet das Original und die erzeugten Untergrößen an den Server. Damit können während des Uploads sogar mehr Bytes übertragen werden als beim bisherigen Pfad, bei dem zunächst nur das Original ankommt. Redaktionen mit langsamem WLAN oder mobilen Verbindungen sollten deshalb nicht nur die Ladezeit der Website, sondern auch Dauer, Abbruchverhalten und Wiederaufnahme des Uploads beobachten.

Ebenso wichtig: Die neue Pipeline ersetzt keine redaktionelle Bildentscheidung. Ein automatischer Thumbnail-Prozess weiß nicht, welcher Ausschnitt die Person, das Produkt oder die Handlung verständlich zeigt. Er entscheidet auch nicht, welche Ausgangsgröße für Blog, Website oder Social Media sinnvoll ist. Mit dem AdSimple Image Resizer lassen sich Bilder vor dem WordPress-Upload lokal im Browser zuschneiden, verkleinern und als WebP, JPEG oder PNG vorbereiten. Laut Live-Leistungsseite werden die Bilder dabei weder hochgeladen noch bei AdSimple gespeichert.

Browser-Fallback gehört in den Testplan

Die vollständige WebAssembly-Pipeline setzt derzeit Chromium-basierte Browser und weitere technische Bedingungen voraus. WordPress nennt Chrome und Edge ab Version 137 als unterstützte Desktopvarianten. Firefox und Safari verwenden automatisch den bisherigen serverseitigen Pfad; Safari kann HEIC dennoch über einen eigenen Weg dekodieren. Auch wenig Arbeitsspeicher, nur ein CPU-Kern, eine sehr langsame Verbindung, aktiviertes Datensparen oder eine blockierende Content Security Policy können den Browserpfad deaktivieren.

Dieser Rückfall ist beabsichtigt und für Nutzer normalerweise unsichtbar. Genau deshalb muss er getestet werden. Ein Upload kann in Chrome funktionieren, weil der Browser alle Größen erzeugt, und in Firefox scheitern, weil auf dem Server weiterhin AVIF-Unterstützung, Speicher oder ein bestimmter Hook fehlt. Umgekehrt kann ein Plugin im Serverpfad sauber laufen, aber beim neuen Finalize-Ablauf doppelte Arbeit ausführen.

Eine Testmatrix für österreichische WordPress-Websites

Ein sinnvoller Test braucht keine hundert Dateien. Sechs bewusst ausgewählte Medien und zwei Browserpfade decken die wichtigsten Risiken ab. Verwenden Sie eine Stage- oder lokale Kopie mit denselben Themes, Plugins, Bildgrößen und PHP-Einstellungen wie im Produktivsystem. Vorabversionen gehören nicht auf die Live-Website.

1. Ausgangsdateien zusammenstellen

  • ein großes JPEG aus einer Kamera,
  • ein HEIC-Foto von einem tatsächlich genutzten iPhone,
  • ein PNG mit Transparenz,
  • ein vorhandenes WebP,
  • ein AVIF und
  • ein animiertes GIF, sofern solche Dateien im Betrieb vorkommen.

Notieren Sie Dateigröße, Abmessungen und erwarteten Einsatz. Verwenden Sie keine beliebigen Testbilder, wenn in der Redaktion regelmäßig Hochformatfotos, Produktfreisteller oder besonders große Panoramen verarbeitet werden. Die Matrix soll den echten Alltag abbilden.

2. Chromium- und Fallback-Pfad vergleichen

Laden Sie dieselben Dateien zuerst in einem aktuellen Chrome oder Edge und danach in Firefox oder Safari hoch. Kontrollieren Sie, ob der Upload abgeschlossen wird, ob das Attachment in der Mediathek erscheint und ob alle erwarteten Untergrößen existieren. Prüfen Sie zusätzlich die Bildblöcke im Editor, die Vorschau und die veröffentlichte Testseite.

3. Eigene Bildgrößen und srcset kontrollieren

Themes und Plugins registrieren häufig zusätzliche Größen für Karten, Header, Produktlisten oder Beiträge. Diese Varianten müssen im Browserpfad ebenso entstehen wie bisher auf dem Server. Öffnen Sie die HTML-Ausgabe der Testseite und prüfen Sie, ob srcset, sizes, Breite und Höhe plausibel sind. Eine Mediathek kann vollständig wirken, obwohl im Frontend eine benötigte Variante fehlt.

Der Beitrag Das Hero-Bild bekommt ein Ladebudget zeigt, warum ein korrektes Upload-Ergebnis noch keine gute Auslieferung garantiert. Responsive Varianten, Priorisierung und der tatsächlich sichtbare Ausschnitt bleiben eigene Aufgaben.

4. CDN, Wasserzeichen und Metadaten testen

WordPress will den Filter wp_generate_attachment_metadata weiterhin auslösen: einmal beim Anlegen und erneut nach dem Finalisieren der Untergrößen. Plugins für CDN-Synchronisation, Wasserzeichen oder eigene Metadaten müssen beide Aufrufe idempotent verarbeiten. Im Test ist zu prüfen, ob Dateien doppelt übertragen, mehrfach markiert oder unvollständig synchronisiert werden.

5. Externe Bilder und Editor-Einbettungen prüfen

Externe Bilder werden wegen der Browser-Isolation künftig serverseitig in die Mediathek importiert. Wer eigene Importfunktionen oder Redaktionsplugins verwendet, sollte kontrollieren, ob URL-Import, Berechtigungen und Fehlerbehandlung weiterhin funktionieren. Gleichzeitig lohnt ein Test von externen Skripten, Medienvorschauen und Page-Buildern im Editor, weil die neue Document-Isolation-Policy das Verhalten von Ressourcen über Domaingrenzen beeinflussen kann.

6. Löschen und Wiederherstellen nicht vergessen

Bei HEIC bleibt das Original als Begleitdatei erhalten. Für bestimmte animierte GIFs können zusätzlich Video und Poster entstehen. Löschen Sie ein Test-Attachment und kontrollieren Sie, ob alle zugehörigen Dateien entfernt werden. Prüfen Sie danach auch Backup, Restore und Medienbereinigung. Ein funktionierender Upload reicht nicht, wenn Begleitdateien später im Speicher zurückbleiben oder im Backup fehlen.

Der Redaktionsworkflow vor und nach dem Update

Ein robuster Ablauf beginnt vor WordPress. Die Redaktion wählt das Motiv, entfernt unbrauchbare Varianten, legt einen sinnvollen Ausschnitt fest und reduziert übergroße Originale auf einen nachvollziehbaren Rahmen. Dateiname und Alt-Text werden nicht von der Komprimierung erfunden, sondern bleiben redaktionelle Angaben. Der bestehende Beitrag Bilder für Social Media, Blog und Web vorbereiten ordnet dafür typische Zielgrößen und Formate ein.

Nach dem Upload folgt die technische Kontrolle: richtige Abmessungen, Untergrößen, Dateityp, Dateigewicht, Alt-Text und Frontend-Ausgabe. Bei wichtigen Landingpages kommt eine mobile Sichtprüfung hinzu. Für Serienuploads, Produktimporte oder von mehreren Autorinnen und Autoren gepflegte Websites sollte eine kurze Stichprobe nach jedem größeren WordPress-, Theme- oder Medienplugin-Update vorgesehen werden.

Typische Fehlannahmen rund um die neue Bildpipeline

„Der Browser optimiert alles automatisch.“ Die Pipeline verarbeitet Dateien technisch. Sie ersetzt weder Motivauswahl noch Ausschnitt, Benennung, Alt-Text oder die Entscheidung über das richtige Zielmaß.

„Wenn Chrome funktioniert, ist die Website bereit.“ Nicht unterstützte Browser verwenden den Serverpfad. Beide Wege müssen auf dem eigenen Stack funktionieren.

„Weniger Serverlast bedeutet weniger Upload-Traffic.“ Der Browser überträgt Original und Untergrößen. Der Vorteil liegt vor allem bei Serverressourcen und der späteren Auslieferung, nicht zwingend beim Datenvolumen des Uploads.

„Bestehende Plugins bleiben garantiert unverändert.“ WordPress erhält wichtige Standard-Hooks, weist Entwickler aber ausdrücklich auf Tests hin. Besonders doppelte Metadatenaufrufe, eigene Bildeditor-Hooks, CSP-Regeln und Remote-Importe verdienen Aufmerksamkeit.

„Die Beta kann kurz live ausprobiert werden.“ WordPress.org rät davon ausdrücklich ab. Ein separates Testsystem schützt Inhalte, Bestellungen, Buchungen und Redaktionsarbeit.

Abnahmekriterien statt eines allgemeinen „funktioniert“

Ein Test sollte mit klaren Kriterien enden. „Das Bild ist in der Mediathek“ ist zu wenig, weil die Datei trotz fehlender Untergrößen, falschem Format oder defekter CDN-Synchronisation sichtbar sein kann. Definieren Sie deshalb vor dem Test, welche Ergebnisse für Ihre Website zwingend sind.

Für eine typische Unternehmenswebsite kann die Freigabe so aussehen: Alle vorgesehenen Dateitypen lassen sich in einem Chromium-Browser und im Server-Fallback hochladen. Jede registrierte Größe wird erzeugt. Die Testseite liefert ein plausibles srcset, zeigt keine verzerrten Ausschnitte und lädt auf dem Smartphone die passende Variante. Alt-Text, Bildunterschrift und Copyright-Feld bleiben nach Bearbeitung erhalten. CDN und Backup enthalten dieselben Dateien wie die lokale Mediathek. Beim Löschen verschwinden auch HEIC-Originale oder GIF-Begleitdateien.

Für einen Shop kommen Produktgalerie, Zoom, Variantenbilder und strukturierte Produktdaten hinzu. Ein Tourismusbetrieb sollte Buchungsseiten, Galerien und Kartenansichten prüfen. Bei Ordinationen und beratenden Berufen sind Teamfotos, sensible Metadaten und verlässliche Freigaben besonders wichtig. Entfernen Sie Standort- oder Geräteinformationen aus Quelldateien, wenn sie für die Veröffentlichung nicht benötigt werden; die technische WordPress-Verarbeitung ist kein Ersatz für eine datenschutzbewusste Bildauswahl.

Erfassen Sie außerdem die Zeit für einen Upload und die Dateigrößen der wichtigsten Varianten. Diese Werte müssen nicht exakt einem Laborbenchmark entsprechen. Sie dienen als Vergleich zum bisherigen Produktionsweg. Wenn die Serverlast sinkt, aber Redaktionsuploads in der tatsächlichen Büroumgebung deutlich länger dauern, ist das eine relevante Beobachtung. Ebenso muss ein kleineres JPEG im Frontend noch visuell akzeptabel sein. Prüfen Sie Gesichter, feine Produktstrukturen, Farbverläufe und Schriften in fotografierten Unterlagen bei 100 Prozent Darstellung.

Die Abnahme endet mit einer verantwortlichen Person und einem Datum. Sie hält fest, welche Browser, Plugins und Dateitypen geprüft wurden, welche Einschränkungen akzeptiert sind und wer nach dem finalen Update eine Stichprobe auf Produktion durchführt. Damit wird aus einem einmaligen Techniktest ein wiederholbarer Medienprozess.

Ein kompakter Freigabeplan bis 19. August

  1. Inventar: Themes, Medienplugins, CDN, Wasserzeichen, eigene Größen, Dateiformate und Redaktionsbrowser erfassen.
  2. Stage vorbereiten: realistische Konfiguration ohne produktive Inhalte oder Kundendaten verwenden.
  3. Matrix durchführen: sechs Dateitypen im Chromium- und Fallback-Pfad hochladen, veröffentlichen und löschen.
  4. Frontend prüfen: Vorschaubilder, Hero-Bilder, Galerien, Produktkarten und mobile Ansichten kontrollieren.
  5. Abweichungen dokumentieren: Browser, Datei, Plugin, Fehlermeldung und reproduzierbare Schritte festhalten.
  6. Freigabe trennen: Erst nach stabilem finalen Release, Backup und erfolgreichem Test ein Wartungsfenster für die Live-Website planen.

Für die laufende Bildvorbereitung bleibt eine klare Trennung hilfreich: Der AdSimple Image Resizer bringt Ausgangsbilder lokal in passende Formate und Maße; WordPress erzeugt daraus die für Theme und Plugins registrierten Varianten. Wer beide Schritte kontrolliert und den neuen Browserpfad auf Stage testet, erhält nicht nur weniger Serverlast, sondern einen nachvollziehbaren Medienprozess.

Quellen