Choosing an Image Optimization Plugin for WordPress

Every image optimizer compresses — that part is a commodity. What separates them is where the processing runs, whether your originals survive, how modern formats reach the browser and what remains when the subscription ends. Decide those four things first and the choice narrows to two or three candidates in minutes.

If you have not yet worked through resizing and lazy loading, start with how to optimise images in WordPress: a plugin compresses what you give it, and a 5000-pixel photo compressed well is still a 5000-pixel photo.

What a plugin actually does

An upload of one photo produces six or more files: the original, the -scaled copy and every registered size — see WordPress image sizes. An optimizer works on all of them:

1. Compresses each file, lossy or lossless (the difference is in lossy vs lossless compression).
2. Converts to WebP or AVIF and stores the copies alongside the originals.
3. Serves the modern copy to browsers that accept it.
4. Optionally resizes oversized originals to a maximum width.
5. Bulk-processes the library you already have.

The first is the same everywhere. Steps 2–5 are where products diverge.

The four decisions

Where compression runs

Local optimizers call image libraries on your hosting. They cost nothing per image, but every upload makes PHP do heavy work, bulk runs can hit execution limits, and the quality depends on which tools the host has installed — many shared hosts lack an AVIF encoder, and some lack WebP.

Cloud optimizers upload each file to the vendor, receive the optimised version and write it back. Uploads stay quick and the encoders are always current, at the cost of a monthly quota and sending your images to a third party.

Originals

A plugin that overwrites originals makes a bad setting permanent. Keep the backup, check a sample of results at full size, and only then decide whether to delete the backups to recover disk space. Restoring originals is also what lets you regenerate thumbnails later without compounding compression.

WebP and AVIF delivery

Rewriting <img> into <picture> works everywhere but fights with page builders, lazy loaders and HTML caching. A server rule (Apache .htaccess, nginx map) or CDN negotiation leaves the markup alone and is more robust — unless a CDN that ignores Vary: Accept sits in front of the site, in which case <picture> is the safe choice. The trade-offs are covered in WebP and AVIF in WordPress.

What happens when you stop paying

Files already optimised and converted should stay in place and keep working. Check that cancelling does not remove the WebP copies or disable the rewrite rules that serve them — otherwise your site silently reverts to heavy JPEGs.

Cloud optimizers on shared hosting

On shared hosting, the cloud model usually wins: the server never runs the encoders, bulk jobs do not time out, and AVIF works even where the host's image library has no support for it. Imagify is an example of that model — compression on its servers, WebP and AVIF generation, a backup of each original, a maximum-width resize for oversized originals and a bulk optimiser for the existing library, with a free monthly quota to test against your own images.

On a VPS with modern image libraries installed, a local optimizer is a reasonable free alternative. Measure one image of each type both ways before committing.

Overlap with performance plugins

All-in-one performance plugins often include lazy loading, WebP rewriting or their own image compression. Running two systems on the same images is the most common configuration fault:

• Compression belongs to exactly one plugin.
• WebP rewriting belongs to one plugin or the CDN, never both.
• Lazy loading belongs to WordPress core unless you have a specific reason — see lazy loading images in WordPress.

Common mistakes

• Choosing the most aggressive setting and judging it at thumbnail size. Artefacts show on full-width hero images first.
• Bulk-optimising without a backup. Back up wp-content/uploads before the first bulk run, as described in WordPress backup plugins.
• Compressing twice — once before upload at low quality, again in the plugin.
• Ignoring the generated sizes. A plugin that only processes the original misses the files visitors actually load.
• Measuring a score instead of bytes. Compare page weight before and after.

Verify

1. Upload a test photo and open the attachment details: the plugin should report savings for the original and each size.
2. Load a post in a private window with the Network tab open, filter by images and confirm the type column shows webp or avif.
3. Disable the plugin temporarily on staging and confirm the images still display — broken images mean the originals were replaced or the markup points directly at converted files.
4. Compare total image bytes for one long page before and after the bulk run.