Image Optimisation in WordPress: What Plugins Miss
Plugins make image optimisation feel easy. Upload, compress, done. Except it is not done, not by a long way. The compression part is maybe thirty percent of the job. The rest sits in file format choices, delivery settings, markup decisions, and server config that no plugin touches automatically. This post covers what the plugins actually handle, where they stop, and what you have to do yourself if you want the full gain.
On this page
What Compression Plugins Actually Do
Compression plugins do one thing well. They reduce file size by stripping data from your images, either losslessly or by discarding some visual detail.
That is genuinely useful, and most sites benefit from it. A plugin like ShortPixel or Imagify will take a 2MB JPEG uploaded by a client and bring it down to 300KB or less, often without any visible quality loss. It does that automatically, in the background, without you touching a thing. Some plugins also convert images to modern formats like WebP, which loads faster in supporting browsers. That combination of smaller file size and a more efficient format is the bulk of what plugin-based optimisation actually delivers, and for many sites it moves the needle on page load time in a meaningful way.
What plugins cannot do is fix the problems that exist before compression runs. If someone uploads a 5,000-pixel-wide photograph to fill a 400-pixel thumbnail slot, the plugin compresses that oversized image and serves it anyway. The browser still has to download far more data than the layout requires. Similarly, no compression plugin sets your width and height attributes correctly, controls how images are loaded relative to the viewport, or decides which image should be in the critical path and which can wait. Those decisions sit outside the plugin’s scope entirely.
File Format Choices That Plugins Get Wrong
Most image optimisation plugins default to converting everything to WebP, and on the surface that makes sense. WebP is well supported, compresses well, and Google likes it. The problem is that “convert everything” is a blunt approach. A photograph with thousands of subtle colour gradients suits WebP or JPEG well. A logo or icon with flat colours, hard edges, and transparency is a different matter entirely. PNG preserves that kind of image cleanly without introducing the blocky artefacts that lossy compression creates. Converting a transparent logo to WebP with aggressive settings can leave halos and colour fringing that look fine in a thumbnail and terrible at full size. AVIF compresses even smaller than WebP and handles both photographic and graphic content well, but browser support is still catching up, and if you’re not serving a fallback, older browsers will simply show nothing. The technical side of format selection matters far more than most plugin settings pages suggest.
The plugin does the conversion. You have to decide the rules it follows. Blanket settings applied across an entire media library are where the real optimisation decisions get made, and most people never look at them.
Don’t expect a single toggle to cover every image type correctly. Format choice is context-dependent, and that judgment still sits with you.
Dimensions and Display Size: The Gap Nobody Closes
Most compression plugins do exactly what they say. They take whatever image you upload and reduce the file size. The problem is that “whatever you upload” is often a 4000px wide photo straight from a camera or a stock site, destined for a sidebar slot that displays at 600px. The plugin compresses it faithfully at full resolution, hands it back, and marks the job done. You end up with a smaller version of a still-enormous image. The browser then downloads all those pixels it will never use and scales the image down in the viewport, which costs loading time and does nothing for your Core Web Vitals score.
That gap, the distance between upload dimensions and display dimensions, is almost never closed by a plugin automatically. It is the one thing you have to sort out yourself before compression even becomes relevant.
The fix is straightforward once you know what to look for. Check what size the image actually renders at on your page, using browser dev tools or a tool like Google’s PageSpeed Insights. Then resize the source file to match that display size before uploading. A 600px display slot needs a source image somewhere around 1200px wide to account for high-density screens, not 4000px. Once you have the dimensions right, a good approach to format and compression will actually move the needle. Getting the dimensions wrong first means you are optimising the wrong thing entirely.
Lazy Loading: What WordPress Gives You by Default and Where It Falls Short
WordPress has added loading="lazy" to images automatically since version 5.5. That sounds like a job done, and for most images buried halfway down a page, it is. The browser defers loading them until they’re close to entering the viewport, which cuts initial page weight and helps load times on image-heavy posts. The problem is that WordPress applies this attribute broadly, and it doesn’t always distinguish between images the user will never see until they scroll and images that land directly in front of them the moment a page opens. That distinction matters a lot more than most people realise when you’re trying to improve your overall Core Web Vitals score.
The image most likely to hurt you is your Largest Contentful Paint element. That’s usually a hero image, a large featured photo, or a banner sitting above the fold. If that image carries a lazy load attribute, the browser deliberately delays fetching it. Your LCP time suffers directly as a result. Google’s own guidance on LCP is clear on this point, and yet it’s the one thing WordPress native lazy loading doesn’t protect you from out of the box.
The fix is simple but manual. Remove loading="lazy" from your LCP image, or add fetchpriority="high" alongside it. Neither happens automatically. That’s the part no plugin reliably handles for you.
CDN Delivery and Why Local Hosting Limits Your Gains
Compress an image down to 40KB and it still has to travel from your server to your visitor. That journey matters more than most people realise.
A CDN, or content delivery network, stores copies of your images across servers in different locations. When someone in Sydney loads your site, they get the image from a nearby node rather than a server sitting in a data centre in London. The file size stays the same, but the physical distance it travels shrinks dramatically, and that cuts latency in a way no compression plugin can touch. Most WordPress image plugins do not come anywhere near this. They optimise the file, then leave it sitting on your origin server waiting for every request. Cloudflare, BunnyCDN and similar services handle the delivery side, and they need to be set up separately. It is not complicated, but it does not happen automatically.
The honest trade-off is that a CDN adds a layer to your setup, and if it is misconfigured you can end up serving stale images or breaking cache rules you spent time putting in place. Done right though, delivery improvements on a properly configured caching setup compound each other. That is where real-world load time improvements come from, not from shaving off another few kilobytes.
The Manual Checks No Automation Replaces
Plugins will compress a file and move on. They won’t tell you that your hero image is 2400px wide when the container only ever renders at 1200px, or that the same background graphic is loading on mobile where it contributes nothing to the page. That kind of judgement comes from actually looking at the site, not reading a plugin dashboard. The hero image is worth real attention. It loads first, it sits above the fold, and if it’s oversized or the wrong format it costs you on Core Web Vitals before the rest of the page has even started. Resize it properly for the breakpoints you actually use, and test it on a real device, not an emulator.
Alt text is the other area that automation gets badly wrong. A plugin can flag a missing attribute, but it can’t write accurate alt text. Decorative images should have an empty alt attribute so screen readers skip them entirely. Content images need a short, plain description that tells both the user and Google what’s actually there. Stuffing keywords into every alt tag is an old habit that does more harm than good, and getting the format and load behaviour right matters just as much as the words you write.
Don’t trust plugin scores as a final answer. Load the page over a real mobile connection and watch what actually happens.