Türkei (Türkisch)
Germany (German)
Worldwide (English)
Client-Side Media Processing ist in WordPress 7.1 auf unterstützten Browsern standardmäßig aktiviert.
Halkali Merkez Viertel Fatih Str. Ozgur Apt. No. 46, Kucukcekmece, Istanbul, 34303, TR
WordPress 7.1: wasm-vips im Browser für Resize, Thumbnails und Konvertierung; PHP-Memory, HEIC, AVIF, Hooks und Fallback verstehen.
Client-Side Media Processing ist in WordPress 7.1 auf unterstützten Browsern standardmäßig aktiviert.
Kompression, Resize, Formatkonvertierung, EXIF-Rotation und Thumbnails können per wasm-vips/libvips im Browser erfolgen; anschließend werden die Ergebnisse hochgeladen.
WordPress Core hebt ausdrücklich hervor, dass PHP-Memory-Limit-Fehler bei großen Bildern vermieden und Server-CPU/RAM entlastet werden können.
Sind die Voraussetzungen nicht erfüllt, fällt WordPress transparent auf den klassischen serverseitigen GD/Imagick-Pfad zurück.
Im klassischen WordPress-Pfad decodiert PHP das Original über GD oder Imagick, skaliert es, erzeugt Zwischenformate, rotiert per EXIF und konvertiert Formate. Ein hochauflösendes Bild benötigt im Speicher oft deutlich mehr RAM als seine komprimierte Dateigröße.
Deshalb sind Allowed memory size exhausted, Post-Processing-Fehler und fehlende Thumbnails auf knappem Hosting häufig. WordPress 7.1 verlagert einen großen Teil dieser Arbeit in den Browser des Uploaders.
WordPress nutzt wasm-vips, eine WebAssembly-Version von libvips, in einem Web Worker. Kompression, Resize, Formatkonvertierung, Rotation und Sub-Sizes entstehen vor dem Upload im Browser, sodass PHP nicht jede Variante im Server-RAM erzeugen muss.
Nach der Verarbeitung werden erzeugte Dateien zum Server übertragen und ein Finalize-Schritt vervollständigt die Attachment-Metadaten. Der Media-Lifecycle bleibt bestehen; nur die teure Pixelverarbeitung wurde verlagert.
Laut Entwicklerhandbuch hängt die vollständige WASM-Pipeline derzeit von Document-Isolation-Policy und unterstützten Chromium-Browsern wie Chrome/Edge 137+ ab. Benötigt werden WebAssembly, SharedArrayBuffer, Web Worker und passende CSP-Regeln.
Bei 2 GB oder weniger gemeldetem Gerätespeicher, weniger als zwei CPU-Cores, sehr langsamer Verbindung oder Save-Data kann die Client-Pipeline deaktiviert werden. Der Upload funktioniert weiter, Processing fällt aber auf den Server zurück.
Ein wichtiger Vorteil ist die browserseitige HEIC-Decodierung und JPEG-Konvertierung auf unterstützten Plattformen. Dadurch kann ein Upload auch ohne HEIC-Unterstützung auf dem Server funktionieren.
AVIF wird bei Client Processing weniger von der serverseitigen Image-Editor-Unterstützung abhängig. Opaque Animated GIFs können zusätzlich effiziente MP4/WebM-Begleitdateien erhalten; Themes und Plugins sollten damit getestet werden.
Einige serverseitige Image-Editor-Hooks spielen im Client-Pfad nicht mehr dieselbe Rolle, da die Pixelverarbeitung nicht in PHP stattfindet. Beim Finalize läuft weiterhin `wp_generate_attachment_metadata`, sodass Plugins die vollständigen Sub-Size-Metadaten sehen können.
Plugins mit eigener WP_Image_Editor-Implementierung oder Abhängigkeit von image_make_intermediate_size sollten in Staging getestet werden. WordPress dokumentiert das Abschalten von Client Processing für solche Fälle.
WordPress 7.1 stellt den Filter `wp_client_side_media_processing_enabled` bereit. Bei Plugin-/Workflow-Inkompatibilität kann damit siteweit auf die klassische serverseitige Verarbeitung zurückgeschaltet werden.
Die Funktion nicht sofort dauerhaft deaktivieren. Browser-Konsole, CSP, Plugin-Hooks und Server-Fallback vergleichen, um die fehlerhafte Ebene zu finden.
add_filter( 'wp_client_side_media_processing_enabled', '__return_false' );Nein. WordPress 7.1 reduziert PHP-Memory-Druck bei aktiver Client-Pipeline. Plugins, Imports, Backups, WooCommerce, Admin-AJAX, Cron und der Fallback-Media-Pfad benötigen weiterhin PHP-Memory.
upload_max_filesize, post_max_size, Webserver-Body-Limits sowie Disk-/Inode-Limits verschwinden nicht. Der Server muss die verarbeiteten Dateien weiterhin annehmen und speichern.
| Aufgabe | Klassischer Server-Pfad | 7.1 Client-Pfad |
|---|---|---|
| Resize/Thumbnails | PHP + GD/Imagick | Browser + wasm-vips |
| PHP-Memory-Druck | Kann hoch sein | Für Pixelverarbeitung weitgehend entfernt |
| Bei fehlender Unterstützung | N/A | Server-Side-Fallback |
Vor Änderungen in Produktion Kontext, Backup und Rückfallplan prüfen. Bei DNS, TLS, Recovery, Docker oder WordPress nicht mehrere Variablen gleichzeitig ändern, da sonst die Ursache schwerer zu isolieren ist.
Nein. Nur die clientseitige Bildverarbeitung wird entlastet; andere WordPress-PHP-Workloads benötigen weiterhin ausreichend Memory.
Laut aktueller Entwicklerdokumentation nicht; wegen DIP-Anforderung wird der serverseitige Fallback verwendet.
Ja. Über `wp_client_side_media_processing_enabled` kann auf den klassischen Server-Pfad zurückgeschaltet werden.
Wenn das Problem in Hosting-, VPS-, Docker-, Cloudflare-, Windows- oder WordPress-Infrastruktur weiter besteht, können Sie mit Fehlerausgabe und Architektur einen technischen Supportfall erstellen.