WordPress 7.1 moves image processing out of PHP and into the browser

WordPress 7.1 is moving one of the most server-heavy parts of an image upload out of PHP — and into the browser.

And I think this is one of the more interesting architectural changes in WordPress this year. Traditionally, when you upload a large image, the server does most of the work:

• PHP receives the file.
• GD or Imagick processes it.
• WordPress generates the different image sizes.
• The server handles resizing, rotation, compression and format conversion.

Anyone who has maintained WordPress sites long enough has probably seen the downside of this approach: large images consuming a surprising amount of memory, CPU spikes during media processing, or an upload failing because PHP hit its memory limit.

WordPress 7.1 changes where that work happens.

On supported browsers, image processing can now happen directly on the user’s device using WebAssembly and libvips, running inside a Web Worker. The browser can generate the resized versions, compress them, handle rotation and format conversion, and then send the processed files to WordPress.

That has some interesting consequences:

• Less image-processing work for PHP.
• Less CPU and memory pressure on the web server.
• Large images that might have exceeded PHP’s memory limit can be processed in the browser instead.

And because the pipeline uses libvips, WordPress reports JPEG output around 15% smaller than typical GD/Imagick processing in its testing. There is also better support for modern media workflows, including HEIC images from iPhones, which can be decoded in the browser and converted before they reach a server that may not support HEIC at all.

What I particularly like is that WordPress didn’t make this an all-or-nothing architectural decision. If the browser or device doesn’t meet the requirements, WordPress simply falls back to the traditional server-side pipeline. And existing plugin integrations are not just ignored either. Important metadata hooks still run as the upload is finalized, which helps preserve compatibility with things like CDN integrations, metadata processing and watermarking.

To me, this is a good example of what modernizing WordPress should look like.

Not replacing PHP for the sake of replacing PHP.

Moving work to a better place when the architecture allows it.

We spend a lot of time discussing faster servers, larger PHP memory limits and more infrastructure.

Sometimes the better optimization is simply making the server do less.

If you operate WordPress sites at scale, what would you measure first after enabling this: PHP memory usage, server CPU, or media upload time?