Why your WordPress Media Library should not be overlooked…
Images are one of the easiest things to let get out of hand on a WordPress site. Every upload adds file size, every theme and plugin tends to generate its own set of resized copies, and it’s genuinely easy to end up with a media library several times heavier than it needs to be without ever noticing, because none of it happens in one obvious moment. I treat image handling as a two-stage process — what I do before an image ever reaches WordPress, and what happens automatically once it’s there — and keeping those stages distinct is most of what keeps things manageable.
Before it ever gets uploaded…
I lean on three tools here, each doing a different job:
- Canva is where most images start — building featured images, social graphics, or anything that needs proper design work, and critically, cropping and resizing to the actual dimensions I need rather than uploading whatever size an image happened to arrive in.
- BeFunky is my go-to for quick photo touch-ups — enhancement, cropping, format conversion — for images that need adjusting but don’t need a full design treatment. It fills the gap between “needs Canva” and “just needs to be smaller.”
- TinyJPG / TinyPNG is the last stop before upload. It compresses images losslessly enough that there’s no visible quality drop, but the file size reduction is often substantial. Running every image through this before it ever touches the media library means every size WordPress subsequently generates from it inherits that efficiency, rather than compounding an already-heavy original.
That order matters. Compressing after the fact, once an image already has ten different WordPress-generated sizes sitting on the server, means redoing the work ten times over instead of once.
What happens once it’s in WordPress…
WordPress generates multiple copies of every image you upload — thumbnail, medium, large, plus whatever custom sizes your theme or page builder registers — and serves the appropriate one via srcset depending on the visitor’s screen. That’s genuinely useful and not something I’d want to turn off, but it does mean the size of your original upload matters more than it might seem, since every one of those generated copies starts from it. I try to upload at a sensible maximum dimension for how the image will actually be used, rather than defaulting to whatever resolution came straight off a camera or a stock site.
WordPress’s native lazy loading also does a lot of quiet work here — images below the fold don’t load until a visitor actually scrolls to them, which keeps initial page weight down without me having to configure anything extra.
The backend pass — LiteSpeed and QUIC.cloud…
Beyond what I do manually before upload, LiteSpeed* Cache’s built-in image optimisation feature runs a second, automated pass — it sends images off to the QUIC.cloud* service, which compresses them further and can generate WebP (and increasingly AVIF) versions, then serves those optimised formats automatically to browsers that support them. I think of it as belt-and-braces: my own TinyJPG pass handles the baseline compression before anything reaches the server, and QUIC.cloud handles format conversion and any additional optimisation on top, without me needing to manually export WebP versions of everything myself.
Obviously there are a number of plugins and tools out there that do a similar job. I’ve tried several of them. I’ll be upfront in saying this part of my own setup is still being refined (even after all these years) rather than fully bedded in — it’s one of the pieces I’m actively working through as part of ongoing performance testing, alongside the render-blocking CSS/JS and Core Web Vitals work I’ve mentioned elsewhere. I’d rather say that plainly than pretend it’s a finished, perfect system.
* I have using Litespeed/QUIC.cloud in recent builds as it is part of my Hostinger Hosting package.
Keeping the library itself tidy…
The last piece is just housekeeping: periodically clearing out unused or orphaned images, not letting duplicate uploads pile up when I re-crop or replace something, and generally being aware that storage isn’t infinite. That last point isn’t abstract for me — running into real storage and inode limits with a previous host is exactly what eventually pushed a hosting migration, so keeping the media library lean isn’t just about page speed, it genuinely affects how much runway you’ve got before storage becomes a real constraint rather than a background number.
The short version
Compress before you upload, size deliberately rather than by default, let LiteSpeed and QUIC.cloud (or your tools of choice) handle the automated backend pass, and don’t let the library itself become a dumping ground. None of it is complicated on its own — it’s just a workflow worth actually having, rather than reacting to a slow page speed test after the fact.
