Imagify

On most WordPress sites, images are the largest thing on the page by a wide margin, and they are also the easiest thing to fix badly. The standard failure is not a lack of tooling — it is buying a compression product to solve a problem that was actually a 4,000-pixel photograph dropped into a 900-pixel column, or paying for a layer the host's CDN was already doing. Imagify is a competent answer to the real version of the problem. The work is establishing that you have the real version.

What Imagify is

Verified fact. Imagify is an image optimisation service published by WP Media. Compression runs on Imagify's own infrastructure rather than on your server, and is delivered to WordPress through a connector plugin distributed on WordPress.org; the vendor also documents a web app for one-off files and an API for programmatic use. The documented capabilities include several compression levels, conversion to the next-generation WebP and AVIF formats with fallback delivery for browsers that do not support them, bulk optimisation of an existing media library, automatic optimisation of new uploads, resizing on upload, and retention of originals so an optimisation can be reversed. Imagify is published by the same company as WP Rocket, but it is a separate product bought separately. TTML analysis. The cloud-processing model is the fact that matters commercially. Because the work happens off your server, a bulk pass over a large library does not consume your own PHP and memory, which is genuinely useful on cheap shared hosting — and it is also why the product is metered by volume rather than sold as a flat plugin licence. That is the trade you are making: someone else's CPU in exchange for an ongoing quota you have to size correctly.

WebP, AVIF and the part people get wrong

Verified fact. The vendor documents conversion to WebP and AVIF with fallback delivery for unsupported browsers. TTML analysis. Format conversion is usually the largest single win available, and it is also where a half-configured setup causes the most damage: converted files that are generated but never actually served, or served without a fallback, produce either no improvement or broken images depending on how it fails. Whatever you buy, the acceptance test is not the plugin's dashboard reporting a saving. It is opening your own live page in a browser, checking the network panel and confirming the modern format is what was delivered. We would not consider an image optimisation deployment finished before that check, and the dashboard figure is not a substitute for it.

Establish what is left to buy first

Before any of this is a purchase, three things may already be doing the job. Your caching plugin may include image handling. Your host or CDN may already convert and serve modern formats at the edge — several do this transparently, which means a second conversion layer adds cost and complexity for no delivered benefit. And WordPress itself resizes uploads into multiple sizes, so if the wrong size is being served the fix is your theme's markup rather than compression. Once those are ruled out, the remaining problem is real and worth paying for: an existing library of large originals, and new uploads arriving from people who will never resize anything. Our WordPress pillar sets out how the caching, hosting and image layers overlap, and it is the cheaper place to start.

Quotas, sizing and the recurring cost

The mistake specific to metered optimisation services is sizing the plan against the initial bulk pass rather than the steady state. Clearing a backlog of years of photographs is a one-off spike; what you are actually buying for the long term is the monthly upload volume afterwards, which is usually far smaller. If you buy on the basis of the spike, you overpay permanently. It is also worth knowing that every optimisation service counts differently — thumbnails and generated sizes may each consume quota — so the number that matters is not your file count but what the vendor counts, checked in its own documentation before you commit.

Originals, reversibility and quality

Verified fact. The vendor documents multiple compression levels and the retention of original files so that optimisation can be restored. TTML analysis. Keep originals. This is the single setting we would treat as non-optional, and not because compression is untrustworthy: it is because the acceptable quality level is a judgement about your own photographs that you cannot make in advance. Sites selling physical products, and photographers of any kind, should test the most aggressive setting on a handful of representative images and look at them properly before running it across a library. We have not evaluated Imagify's output quality at any level, so we make no claim about how far its aggressive mode can be pushed — that is exactly the sort of judgement that has to be made on your own images.

Strengths

• Compression runs on the vendor's infrastructure, so a bulk pass does not consume your own server resources
• Documented WebP and AVIF conversion with fallback delivery for unsupported browsers
• Bulk optimisation of an existing library plus automatic handling of new uploads, which is where ongoing value sits
• Originals retained so an optimisation can be reversed rather than being a one-way operation
• Resizing on upload addresses oversized source images at the point they enter the site
• Usable outside WordPress through a web app and an API, not only as a plugin
• Published by an established WordPress performance vendor with a maintained plugin listing

Limitations

• TTML has not installed Imagify or measured anything — no compression, file-size, quality, PageSpeed or Core Web Vitals outcomes are claimed here
• Metered by volume, so it is a recurring cost that must be sized against steady-state uploads rather than the initial backlog
• Frequently redundant on hosts and CDNs that already convert and serve modern formats at the edge
• Cloud processing means an external dependency in your upload path rather than a purely local operation
• Compression cannot fix a theme serving a full-size image into a small column; that is a markup problem
• Acceptable quality at aggressive settings is a judgement about your own images that no review can make for you

Pricing approach

Imagify publishes a free connector plugin on WordPress.org and sells optimisation as plans metered by volume, with a free monthly allowance and paid tiers above it. We publish no figures, because allowances and plan structures are revised and a stale number is worse than none, and we publish no promotional claims of any kind for this product. The useful discipline is to measure your genuine monthly upload volume, ignore the one-off backlog when choosing a tier, confirm in the vendor's own documentation how generated thumbnail sizes count against quota, and check whether your host or CDN is already delivering modern formats before you pay for a layer that duplicates it.

Alternatives

Within WordPress, ShortPixel, Smush, EWWW and TinyPNG's plugin cover the same ground with different metering models and different balances of local versus cloud processing; we have not installed or benchmarked any of them, so we make no compression or quality claim in either direction. See our ShortPixel review for the closest comparable product we cover. The more consequential alternative is architectural: an edge or CDN-level image service converts and resizes on delivery without a plugin in the upload path at all, and if your host already provides that, it is usually the better answer. It is also worth noting that Imagify's publisher, WP Media, also produces WP Rocket — a caching product, not an image one. They address different bottlenecks and neither replaces the other.

Verdict