WordPress image optimisation is something I have spent quite a bit of time looking at, not least because I built ImageCom.press as a simple way to compress images before they are uploaded to a website. On WordPress, I have also normally expected a plugin to handle much of that work after upload. WordPress 7.1 changes part of that process and gives us a good reason to look again at what WordPress can now handle for itself.
WordPress 7.1 introduces client-side media processing. On supported browsers, jobs such as compression, resizing, cropping, rotation, format conversion and thumbnail generation can now take place in the browser rather than relying entirely on the web server.
It is a significant improvement, but it does not mean every image optimisation plugin has suddenly become redundant.
That depends entirely on what the plugin is doing.
What Changes With Images in WordPress 7.1?
Until now, much of the work involved in uploading an image to WordPress has taken place on the server.
You upload the original file and WordPress creates the additional image sizes needed by the theme and front end. It may also scale a very large image, correct its orientation and apply format or quality settings.
That work has traditionally relied on server-side image libraries such as GD or Imagick.
The system works, but the result depends partly on the hosting environment. Server memory, available CPU resources and the image-processing library installed by the host can all play a part.
WordPress 7.1 introduces another route.
On a supported browser, WordPress can use WebAssembly and libvips to process the image locally. The finished image and the required additional sizes are then sent to the server for storage.
For somebody uploading an image through the WordPress editor, there should be very little difference to the normal workflow.
The interesting part is what happens behind the scenes.
Why Move Image Processing Into the Browser?
Large images can require a surprising amount of work.
A photograph taken on a modern phone or camera can be several thousand pixels wide. WordPress may then create a number of smaller versions for different uses across the website.
All of that takes processing power.
If the work happens on the server, PHP memory limits and available server CPU can become part of the equation. WordPress specifically identifies PHP memory constraints and server resources as limitations of the traditional processing system.
Moving that work into the browser means the computer being used to upload the image can take on more of the processing.
That should be particularly useful on hosting accounts with more limited resources.
It also gives WordPress a more consistent processing environment. Instead of the output depending entirely on whether a particular host has GD, Imagick or a certain version of either, supported browsers can use the same libvips-based system.
I would not use this as an excuse to ignore hosting quality, but taking unnecessary work away from the server is clearly useful.
WordPress 7.1 Can Produce Smaller JPEG Files
This is where the change becomes especially relevant to WordPress image optimisation.
According to the WordPress development team, the libvips-based system produces better-compressed output than GD or Imagick, with JPEG files around 15% smaller using the implementation developed for WordPress 7.1.
I would not read that as a promise that every JPEG uploaded to every website will suddenly become exactly 15% smaller.
The original image, dimensions, quality settings and other factors still matter.
What interests me is that WordPress Core itself is improving the quality of the initial image processing.
If an uploaded photograph is already being resized and compressed efficiently, there is potentially less work for a basic compression plugin to do afterwards.
That does not remove the need for image optimisation.
It changes where some of that optimisation takes place.
Modern Image Formats Get Better Support
Image formats have become another part of website performance that can quickly become confusing.
JPEG and PNG remain common, while WebP and AVIF can often produce considerably smaller files. Anyone transferring photographs from newer phones may also encounter HEIC or HEIF.
WordPress 7.1 improves support for modern image handling through the new processing pipeline.
The client-side system can work with JPEG, PNG, WebP, AVIF and GIF formats. WordPress also includes improved handling around HEIC and HEIF uploads.
One particularly useful benefit is AVIF.
With client-side processing available, AVIF files can be processed without relying on AVIF support from the image editor installed on the hosting server.
That reduces another difference between hosting environments.
Your choice of host still matters, but the ability to work with a modern image format becomes less dependent on the exact server image library installed.
What Happens on Unsupported Browsers?
Not everybody will use the new processing system.
WordPress currently requires a supported Chromium-based browser for the full WebAssembly processing pipeline. The developer documentation lists Chrome 137 or later and Edge 137 or later as supported, while Firefox and Safari do not currently support the full pipeline.
That does not stop somebody using Firefox or Safari from uploading images.
WordPress simply falls back to its traditional server-side processing when the requirements for client-side processing are not met.
There should therefore be no need to tell authors or editors that they have to switch browser just to upload an image.
The new system adds another processing route rather than removing the existing one.
Does WordPress 7.1 Automatically Convert Images to WebP or AVIF?
No.
This is an important distinction.
Support for WebP and AVIF does not mean WordPress 7.1 automatically looks at every JPEG and converts it into whichever modern format happens to produce the smallest file.
WordPress already has an image_editor_output_format setting that developers and plugins can use to control format conversion. The new client-side system respects that existing configuration.
A website can therefore be configured to convert certain image types during processing.
That is still different from an image delivery service that makes decisions about the best format, dimensions and version to send to each visitor.
This is where the difference between WordPress Core and a specialist optimisation service starts to become clearer.
What Is Your Image Optimisation Plugin Actually Doing?
Before removing an image plugin, I would open its settings and find out exactly what it does.
The phrase “image optimisation plugin” covers a lot of different products.
One plugin may do little more than compress JPEG and PNG files after they are uploaded.
Another might:
- compress new uploads;
- optimise existing images;
- generate WebP or AVIF versions;
- resize oversized originals;
- serve images through a CDN;
- dynamically resize files;
- retain copies of original images;
- or provide reports on how much space has been saved.
A WordPress image optimisation plugin that only performs basic compression is therefore in a very different position from one running an entire image-delivery system.
WordPress 7.1 makes the first type easier to question.
It does not automatically replace the second.
A CDN Still Does a Different Job
Compression and delivery are related, but they are not the same thing.
Compression reduces the size of the file.
A CDN helps deliver that file efficiently by storing copies across a network of servers and serving content from an appropriate location.
WordPress 7.1 can improve the file created during image processing.
It does not suddenly turn WordPress Core into a global image CDN.
If your current optimisation plugin is also responsible for CDN delivery, removing it could remove something useful from the performance setup.
That is why looking only at the word “compression” can give the wrong impression.
The whole image path matters, from the original upload to the file eventually downloaded by the reader’s browser.
Your Existing Media Library Still Matters
There is another issue if the website has been online for several years.
The new processing system improves how WordPress handles media going through its current image workflow.
It does not magically revisit every old photograph already stored on the server and optimise the entire Media Library for you.
For a new website, that may not matter much.
For an established publication with hundreds or thousands of older images, it can matter a great deal.
A plugin or external service capable of scanning and bulk-optimising existing images may still be useful even if WordPress becomes much better at handling new uploads.
That is something I would check before removing anything.
Dynamic Image Delivery Can Go Further
WordPress already creates several versions of an uploaded image.
It can then use responsive image markup to help the browser choose a suitable version for the available space and screen.
That is good.
Some specialised image services go further.
They can generate images dynamically, change formats, alter quality levels or resize files according to the device or the exact space an image occupies on the page.
That is more than basic compression.
If an optimisation tool is doing that work, WordPress 7.1 has not necessarily made it redundant.
The fact that Core has improved does not mean every product sitting above Core no longer has a purpose.
Would I Remove an Image Optimisation Plugin?
Not immediately, I would test the site first.
This is also why I prefer to plan a WordPress website before I build it, because decisions around hosting, plugins and performance are much easier to manage when they are considered from the start.
As I am writing this, WordPress 7.1 is at Release Candidate 3 and the final release is scheduled for 19 August 2026. WordPress itself recommends testing RC3 on a test or staging site rather than a production website.
That is exactly where I would start.
I would take several typical images from one of my sites:
- a large JPEG photograph;
- a PNG graphic;
- a photograph directly from a phone;
- a WebP image;
- and an AVIF file if the site regularly uses the format.
I would then upload the same originals using the current setup and compare them with the results from WordPress 7.1.
I would look at:
- file sizes;
- generated image dimensions;
- visible image quality;
- the additional sizes WordPress creates;
- the file actually delivered on the front end;
- and the finished page in PageSpeed Insights.
The front-end result is the important bit.
There is little point celebrating a smaller file in the Media Library if the browser still downloads an unnecessarily large image when somebody opens the page on a phone.
The aim is not simply to produce the smallest possible file.
The aim is a faster page without an obvious loss of image quality.
Don’t Remove a Plugin Just to Lower the Plugin Count
I like keeping a WordPress installation focused.
What I do not do is chase an arbitrary plugin count.
There is no magic number where nine plugins produce a fast website and nineteen suddenly make it slow.
A poorly built plugin can cause more trouble than several good ones.
If a plugin performs a worthwhile job efficiently, it has a reason to be installed.
The problem starts when several parts of the website are doing the same job.
If WordPress Core can now handle something well enough that another plugin adds little or nothing, removing that extra layer makes sense.
But removing useful functionality merely to say the website has fewer plugins achieves very little.
That is also one of the reasons I stopped constantly rebuilding WordPress websites. Once a site has a sound setup, I would rather understand what is already there and improve it carefully than replace parts of it every time something new appears.
WordPress 7.1 gives us a reason to review an image plugin.
It does not give us a reason to dismantle a working setup without checking it first.
WordPress Core Is Raising the Starting Point
The part I find most interesting is what this says about WordPress itself.
Plugins will remain a huge part of WordPress. That flexibility is one of the reasons the platform can be used for everything from a small blog to a large publishing website.
But the starting point keeps improving.
Tasks that once required another plugin can gradually become part of Core.
Other jobs become easier.
Performance improvements happen before a website owner installs anything.
Client-side media processing fits into that pattern.
It does not eliminate specialist image services.
It raises the standard of what a fresh WordPress installation can handle without them.
That puts more pressure on plugins to provide something genuinely useful beyond what WordPress already does.
I think that is a good thing.
So, Do You Still Need an Image Optimisation Plugin?
Possibly.
But after WordPress 7.1 I would want a clearer reason for keeping one installed.
If the plugin mainly compresses new JPEG files and WordPress is already producing images that are small enough for the site, I would test whether that extra plugin still earns its place.
If it runs a CDN, optimises an older Media Library, dynamically resizes files or handles another part of the image-delivery process that I actually use, I would keep it.
There is no prize for removing something useful.
There is equally little point maintaining or paying for another layer of software when WordPress already handles the same job well enough.
For me, WordPress image optimisation now starts from a better position in Core.
That is the important change in WordPress 7.1.
It does not kill image optimisation plugins.
It gives us a good reason to check whether ours is still doing enough to justify being there.
