WordPress Image Compression: What Actually Cuts File Size
A freshly uploaded JPEG can sit at 4MB and nobody bats an eyelid. The image looks fine in the media library, the page loads slowly, and the site owner wonders why their scores are poor. Image compression in WordPress is one of those areas where the settings exist, plugins promise the world, and yet most sites are still carrying far more weight than they should. What actually shifts the numbers is a shorter list than most guides admit.
On this page
Why “compressed” does not always mean smaller
Compression is not a single dial you turn up. There are two fundamentally different methods, and picking the wrong one for your image type can shave almost nothing off the file size.
Lossless compression removes redundant data without touching the visible image, which sounds ideal until you consider how little redundant data a photograph holds. Run a high-resolution JPEG of a product shot through a lossless compressor and you might trim 3 to 5 percent off the file. That same image put through a well-tuned lossy process, which selectively discards fine detail the eye rarely notices, can drop 60 to 70 percent with no visible degradation at normal screen sizes. The method matters far more than the act of compressing.
PNG files are the other common trap. They respond well to lossless tools because they carry a lot of flat colour and clean edge data, but throw a PNG compressor at a photographic PNG and the savings are meagre. Converting it to a JPEG or WebP first, then compressing, is where the real reduction happens.
The assumption that any compression pass is doing meaningful work is what causes bloated media libraries. A plugin can report “image optimised” and deliver a file that is still 900 KB. Always check the actual byte count before and after, not just the percentage the tool claims.
The format question comes before the compression setting
Most people reach straight for the quality slider. Format choice does heavier lifting than any compression setting will. A JPEG exported at 80% quality is still a JPEG. Switch that same image to WebP and you typically get a smaller file at the same visual result, without touching the quality number at all.
AVIF pushes that further still, often cutting file size noticeably compared to an equivalent WebP, though browser support means it works best as a progressive enhancement rather than a hard default. For photographs and anything with gradients or subtle tonal variation, WebP is the right call. PNG stays useful only where you need a transparent background and cannot accept any quality loss. AVIF is worth serving where your audience’s browsers will reliably support it.
Flat graphics, logos and icons are a different matter. Those suit SVG where possible, or a well-compressed PNG where SVG is not practical. Serving a photograph as a PNG because it was exported that way originally is one of the most common causes of bloated page weight. Once the format is right, compression settings become a fine-tuning exercise rather than the main event. Get the format wrong and no slider value will rescue the result. You can read more about the practical choices around file size, format and lazy loading if you want to go deeper on this.
What WordPress plugins do to your images
How the processing works
When you upload a JPEG or PNG, a plugin like ShortPixel or Imagify sends that file to its own remote servers, processes it through compression algorithms, then returns a smaller version and overwrites the original (or keeps a backup, depending on your settings). What happens under the hood varies by mode. Lossy discards pixel data the eye struggles to notice, which gets file sizes down dramatically. Lossless strips metadata and redundant colour information without touching the visible image. Most sites use lossy for photographs and lossless for logos or flat graphics, and the better plugins let you set that per image type rather than applying one blanket rule.
The thumbnail problem
Where plugins stop short is thumbnail regeneration. WordPress creates multiple resized versions of every upload, and a plugin that only processes the full-size image leaves those smaller crops untouched.
That matters more than most people realise because those thumbnails are often what loads on the page. A product grid, a blog index, a widget sidebar, all of these pull cropped versions, not the original. If you install a compression plugin after uploading hundreds of images, it will not automatically reprocess the old thumbnail sizes. You need to trigger a bulk regeneration, either through the plugin itself or a tool like Regenerate Thumbnails, otherwise a significant portion of your image file size savings stays on the table.
The original file is the problem most plugins cannot fix
Compression works on what you give it. Upload a photograph straight from a camera or a stock site and you are often looking at something 4000, 5000, even 6000 pixels wide. A plugin will squeeze the file, strip some colour data, maybe convert it to WebP, and hand it back noticeably smaller. That feels like progress.
But if your content column is 800 pixels wide, the browser is still downloading an image more than five times the size it needs, then scaling it down on the fly. No amount of compression closes that gap entirely. A 400 KB version of a 5000px image is still a bloated file for a slot that a 90 KB, properly sized image would fill without complaint.
The real savings come from resizing before compression, not after. Serving a correctly dimensioned source file and then compressing it is a fundamentally different outcome to compressing an oversized one and hoping for the best. Most plugins do offer some form of resizing, but the default settings often cap dimensions at figures that still leave plenty of unnecessary pixels in place. It pays to check what your plugin is doing, because what plugin defaults skip is almost always the source size rather than the compression level.
Where lazy loading fits in
Two different mechanisms
Lazy loading and compression are not the same thing. People conflate them because both reduce what the browser downloads, but they operate at completely different points in the process. Compression shrinks the file itself. Lazy loading delays when the browser fetches it.
If you have a 900 KB hero image sitting uncompressed at the top of the page, adding loading="lazy" to it fixes nothing for that first page load. The browser still pulls the full 900 KB the moment it renders. Where lazy loading earns its place is below the fold, deferring images the visitor may never scroll to at all. For a page with a dozen product shots or a long gallery, that deferral cuts the volume of data transferred on arrival. That matters for how search engines score your pages on performance signals and how quickly the page becomes usable.
Never lazy load your LCP image
The image you must never lazy load is your Largest Contentful Paint candidate, typically the hero image or the first prominent photo a visitor sees above the fold. Lazy loading that image actively damages your LCP score because the browser has to wait before it even begins fetching it. Compress that image hard, serve it in a modern format, and let it load immediately. Everything below the fold is fair game.
Reading your results, not the plugin’s promises
Plugin dashboards are optimistic by design. A compression tool might report that it saved 68% on an image, but that figure often measures the reduction from an uncompressed original, not from what your server was already storing or what the browser downloads. The number looks impressive on a settings screen and means very little in practice.
To get an honest picture, open Chrome DevTools, go to the Network tab, filter by “Img”, reload the page without cache, and look at the Transfer Size column. That column shows exactly what the browser fetched. If a 400 KB image is still showing 380 KB there after “optimisation”, the plugin has not done what it claimed.
PageSpeed Insights gives you a second check. Load your URL, scroll to the “Serve images in next-gen formats” or “Efficiently encode images” diagnostics, and look at the potential savings listed per file. Google measures what it sees from the outside, which is the only measurement that matters for your rankings and load time. You can see this reflected in how technical SEO improvements tie directly to page performance scores rather than internal tool metrics.
Cross-reference both sources. If DevTools and PageSpeed agree a file is still oversized, no plugin dashboard percentage will change that reality.