WordPress 7.1 changes an important part of the media workflow: when the browser can support it, image compression, resizing, format conversion, rotation, and thumbnail generation happen on the client before files reach the server. For site owners, that can reduce server-side image work. For plugin and theme developers, it changes which hooks run and where upload assumptions must be tested.
What client-side media processing does
The WordPress core team describes the feature as a WebAssembly pipeline powered by libvips in a Web Worker. The browser can create the registered image sizes, encode modern formats, and upload the resulting files through the media REST flow. WordPress still has a server-side fallback when the client path is unavailable.
This is not simply a new compression plugin. It is a progressive enhancement to the existing Media Library. The useful distinction is that the browser performs the expensive decode, resize, and encode work, while WordPress remains responsible for authentication, attachment creation, metadata, and storage.
Why it matters for WordPress performance
Image processing can consume CPU, memory, and temporary disk space. Moving eligible work to the browser may reduce those costs on busy shared hosts and small virtual machines. Smaller encoded files can also reduce transfer time for visitors, although the final result depends on the source image, selected quality, network conditions, and the theme’s responsive image markup.
The feature should therefore be measured, not assumed. Compare upload duration, generated file sizes, PHP memory pressure, and the resulting page’s field performance before and after enabling it. A smaller upload does not automatically fix layout shifts or poor loading if the theme still omits dimensions or serves an unnecessarily large image.
Compatibility limits developers should test
WordPress documentation says the client path is not universal. Browser capability, available memory, connection conditions, and Content Security Policy can all affect whether processing runs in the browser. Devices with 2 GB of RAM or less are excluded automatically in the documented flow. Safari and Firefox support also require special attention because the current rollout and fallbacks are not identical across browsers.
Test at least these combinations:
- Chromium on a current desktop with JPEG, PNG, WebP, AVIF, and a large image.
- Safari and Firefox with the same files.
- A lower-memory mobile device and a slow connection.
- A site with a restrictive
worker-srcContent Security Policy. - A plugin that changes image quality, output format, or registered image sizes.
Hooks that may no longer fire
On the client path, there is no server-side WP_Image_Editor instance. WordPress therefore documents that wp_image_editors, image_make_intermediate_size, and image_memory_limit do not run for that path. A plugin that relies on one of those hooks should not silently assume that every thumbnail was created by PHP.
The core documentation identifies alternative points such as wp_handle_upload for sideloaded files and the final pass of wp_generate_attachment_metadata for complete metadata. The right replacement depends on whether a plugin needs to inspect a file, alter attachment data, or apply a policy to every generated size.
REST API and validation considerations
The new flow adds media sideload behavior and image-size information to the REST API. Dimension validation matters because the server checks that a declared size matches the uploaded file. Custom upload code should use the documented parameters rather than guessing which physical file represents a named size.
Plugins that download external images should also review the documented external-image behavior, permissions, and attribution requirements. A technically valid import can still create copyright, privacy, or hotlinking problems if the source policy is unclear.
A practical rollout checklist
- Update WordPress and the editor components in a staging environment.
- Record baseline upload time, image sizes, PHP memory use, and page performance.
- Test browser, device, format, CSP, and fallback combinations.
- Audit image-processing hooks used by plugins and themes.
- Verify attachment metadata, responsive image markup, and sitemap URLs.
- Roll out gradually and monitor failed uploads and support reports.
Client-side media processing is a meaningful WordPress core development and performance tool, but it is also an API and compatibility change. See our WordPress news coverage for related platform updates. Treat it as a migration test for upload integrations rather than a switch that makes every site faster. The primary references are the WordPress Block Editor client-side media guide, the WordPress 7.1 core announcement, and the WordPress 7.1 Field Guide.
