WordPress 7.1 Client-Side Media Processing With wasm-vips

Every agency running a WordPress content shop has the same folder somewhere in the ticket queue: image upload failed. Someone dropped a 22 MB HEIC straight out of an iPhone into the media library, the PHP worker hit its 256 MB limit, Imagick blew up on a colour profile it did not recognise, and the client wants to know why the block editor “does not work”. Twenty years in, this is still where a surprising amount of hosting cost lives.

I have said for a while that the honest fix is not more PHP memory. It is to stop pretending the browser is a dumb pipe. Browsers have had WebAssembly SIMD, Web Workers, WebCodecs and structured file APIs for years. The mismatch was that WordPress kept doing the pixel math on a shared PHP process with a five year old GD build.

WordPress 7.1 is where that assumption ends. Adam Silverstein published the dev note on Make/Core yesterday, the feature is on trunk, it is in Beta 3, and it is default-on for supported browsers when the release ships August 19. This is not a plugin. This is a first-class core capability and it deserves a proper read.

What is actually new

The Client-Side Media Processing in WordPress 7.1 dev note describes it plainly: image compression, resizing, format conversion, rotation and thumbnail generation now happen in the user’s browser using WebAssembly. The engine is wasm-vips, Kleis Auke Wolthuizen’s WebAssembly build of the libvips image library, running inside a Web Worker so the main editor thread stays responsive. This ships behind three new JavaScript packages — @wordpress/upload-media, @wordpress/vips, and @wordpress/video-conversion — plus a PHP feature gate wp_is_client_side_media_processing_enabled().

The supported operations are the ones that used to eat servers alive: JPEG / PNG / WebP / AVIF / GIF conversion, EXIF rotation, progressive encoding, HEIC and HEIF decoding straight from iPhone, full end-to-end AVIF including 10-bit and 12-bit HDR sources, UltraHDR gain map preservation, and animated GIF conversion to muted looping MP4 / WebM. Every registered image sub-size is generated locally, then each sub-size uploads individually through new REST endpoints POST /wp/v2/media/{id}/sideload and POST /wp/v2/media/{id}/finalize. Uploads pause and resume across offline periods and retry with exponential backoff. Dev-facing details land in Gutenberg 23.6, published the same day, which also flipped the GIF-to-video conversion to opt-in via block transform and preserved bit depth for high-bit-depth AVIF sub-sizes.

Browser support matters and it is narrower than the marketing suggests. Chrome 137 and Edge 137 get the full pipeline. Chrome on Android needs 146+. Firefox and Safari fall back to server-side processing today because they do not implement Document-Isolation-Policy, which is what enables SharedArrayBuffer for wasm-vips. Runtime checks also gate the pipeline on device memory greater than 2 GB, at least two CPU cores, network faster than slow-2G, and a Content Security Policy that allows blob: workers. When any check fails, WordPress silently uses the existing server-side path. The WordPress 7.1 Beta 3 release note yesterday specifically calls out fixes for animated GIF, EXIF-rotated images and duplicate HEIC entries in Safari, which tells you the surface is still being polished a month before GA.

Why it matters for WordPress and WooCommerce people

Three things change at once, and they compound.

First, the server-side image work that used to define the hosting bill for content-heavy sites moves off the origin. On a WooCommerce catalogue upload session — one merchandiser, forty product photos, six sub-sizes each — that is 240 resize operations the PHP worker no longer performs. Multiply by the number of editors your busiest client has on a Monday morning, then compare against your managed host’s plan tier. This is the first WordPress release where “install a persistent object cache and buy more PHP memory” is not the only lever left.

Second, format support stops depending on what the host installed. Every user who meets the browser gate now gets libvips-powered processing regardless of whether the server compiled GD with WebP or has an Imagick build that understands AVIF. HEIC uploads from a modern iPhone finally work without a paid conversion service. AVIF ships end-to-end, HDR intact. JPEGs come out roughly fifteen percent smaller than the current GD default because encoding is MozJPEG-style. Front-end delivery gets faster on its own, without a single theme change.

Third — and this is the one that will bite people who do not read the dev note — the server-side extension points shift. The wp_generate_attachment_metadata filter still fires, twice now, once with context 'create' at initial upload and once with 'update' after the client finalises. Watermarking plugins, CDN sync, and metadata-processing extensions stay compatible if they hook that filter properly. But wp_image_editors, image_memory_limit, and wp_image_make_intermediate_size never fire for client-processed uploads. If your custom image pipeline sits on any of those hooks, it silently stops running for the sixty-plus percent of your editors on Chromium. That is the audit that has to happen before 7.1 GA on August 19, not after.

What I would do (or not do) about it

Four passes this week, on staging, on a block theme, on Chrome 137 or newer.

One: grep every custom plugin and mu-plugin for wp_image_editors, wp_image_make_intermediate_size, image_memory_limit, and any code that inspects $_FILES directly during upload. Every hit is a candidate. Move the logic to wp_generate_attachment_metadata where possible, because that is the one filter that fires in both paths. If a plugin absolutely requires the server-side path — a licensed image-recognition SDK, a custom DAM sync that reads pixel data from PHP — decide now whether to disable the feature globally with add_filter( 'wp_client_side_media_processing_enabled', '__return_false' ); or to accept the split behaviour and instrument both branches.

Two: audit Content Security Policy headers on every managed site. If the CSP does not include worker-src 'self' blob:; the wasm worker cannot start and every Chromium user silently falls back to server-side processing. You will not see an error. You will only see that the promised performance never materialised. This is the single most likely reason a real production site shows no measurable improvement after 7.1 lands.

Three: test HEIC upload with an actual iPhone photo, an EXIF-rotated portrait, a 40 MB AVIF, and an animated GIF larger than 8 MB. These are the four failure modes Beta 3 specifically fixed, which is a strong hint they were the most common. Confirm the animated GIF now converts to a muted looping Video block on transform, and that the original image/gif attachment still exists with the video variant recorded in media_details.animated_video. Do not enable auto-conversion in the UI until your client has explicitly asked for it — that is why Gutenberg 23.6 moved it back behind an opt-in.

Four: for WooCommerce stores, do not stack this with the WooCommerce 11.0 upgrade window. WooCommerce 11.0 lands July 28 with product object caching default-on for new stores. WordPress 7.1 lands August 19 with client-side media processing default-on for supported browsers. Two moving targets in the same triage queue is how weekends disappear. Run the WooCommerce 11.0 pass on WordPress 7.0.2 stable first. Add 7.1 to the schedule only after your client’s product photography workflow is on a browser you trust — meaning Chrome or Edge on desktop, Chrome 146+ on Android.

Do not disable the feature reflexively because “we do not trust WebAssembly in production”. Chrome and Edge have shipped wasm-vips-class workloads for years, the isolation model is per-document not site-wide, and the fallback path is the code you are running today. And do not build production tooling on the new sideload and finalize REST endpoints yet. Let the surface settle one release cycle.

The bigger read is that WordPress core just moved a category of work off the server that has been there since 2003. It is the kind of quiet infrastructure change that only pays back if you audit the seams — and only hurts you if you do not.