If a site used to feel fast and now doesn't, look at the images before you blame the host. The most common cause we find is years of full-resolution phone photos uploaded straight into posts, plus a pile of thumbnail sizes registered by every theme and plugin the site has ever run.
It is rarely one dramatic file. It is hundreds of slightly-too-big ones, added over years by people doing exactly what the editor invited them to do: drag a photo in, hit publish, move on.
How a media library gets heavy without anyone noticing
Modern phones take photos that are roughly 4,000 pixels wide and three to six megabytes each. A blog post displays that photo at maybe 800 pixels wide. WordPress will politely serve a smaller version if the theme asks for one, and a lot of the time the theme does. But not always, and not everywhere.
Page builders are a frequent offender here. Background images, sliders, gallery blocks, and hero sections often reference the original file directly, because the builder had no way of knowing what size you'd want. Product images in shops do the same thing so the zoom feature has something to zoom into. The result is a page that looks fine on your laptop over office wifi and crawls on a phone in a parking lot.
Nobody notices this happening. There is no warning and no error. The site just gets a little slower each quarter, and you adjust to it, the way you adjust to a squeaky door.
Weight and perceived speed are not the same thing
Total page weight matters, but it is not what your visitor experiences. What they experience is how long it takes before the page looks finished and stops moving.
A 4 MB image at the top of the page is much worse than 4 MB spread across images further down. The one at the top blocks the thing the visitor came to see. The ones below the fold can arrive whenever they like, as long as the layout doesn't jump when they land. That is why two sites with identical page weight can feel completely different, and why a speed test score is the start of a conversation rather than the conversation.
We covered the gap between measured speed and felt speed in why your website feels slow even when hosting looks fine. Images are usually the first thing we check, and usually the thing we find.
Every thumbnail size, forever
Here is the part that surprises people. When you upload one photo, WordPress doesn't store one file. It stores a set of resized copies: thumbnail, medium, large, and whatever extra sizes your theme and plugins have registered. A gallery plugin registers two. The shop plugin registers three. The theme you replaced in 2021 registered five, and those files are still sitting there, because nothing cleans up after a theme switch.
So a single upload can become fifteen files on disk. Multiply by a library of 3,000 uploads and you have a media directory that dominates every backup and consists mostly of copies nobody has requested in years.
This doesn't slow down page loads directly. Unrequested files don't cost visitors anything. It does slow down backups, migrations, and staging copies, and it is the usual reason a site drifts toward our 100 GB per-site soft limit without the owner ever uploading a video.
Modern formats and lazy loading, without the jargon
Two things have genuinely improved in the last few years, and both are worth having.
Modern formats. WebP and AVIF are newer image formats that produce the same visible quality at much smaller file sizes. A photo that weighs 800 KB as a JPEG often lands well under half that as WebP, with no visible difference. Every browser your customers use supports WebP, and AVIF compresses further. Converting a library is mechanical work, and it is one of the few changes that makes a site faster without redesigning anything.
Lazy loading. This tells the browser not to download an image until the visitor scrolls near it. WordPress does it by default now, which is good. But defaults are blunt. Lazy loading applied to the image at the very top of the page actively hurts, because you have just told the browser to delay the single most important thing on the screen. We see this where a plugin installed to "optimize images" applied lazy loading to everything, including the logo.
What actually gets fixed in a cleanup
A media cleanup is unglamorous and reliably effective. The work looks like this.
- Find the oversized originals that are being served directly to visitors, and replace them with correctly sized versions.
- Convert the library to WebP, keeping the originals so nothing is lost.
- Turn off lazy loading for above-the-fold images and leave it on everywhere else.
- Set explicit width and height on images so the layout stops shifting while the page loads.
- Remove thumbnail sizes registered by themes and plugins the site no longer uses, then delete the orphaned files those sizes generated.
- Check what the page builder is actually requesting, because that is where the worst offenders hide.
On a typical small-business site this takes a few hours, and the difference on mobile is usually obvious without a measuring tool. It is the highest-return performance work available on most WordPress sites, and it beats buying a bigger server, which does nothing for a page that is heavy by design.
The part where this goes badly
Now the honest caveat. This is where we have seen real damage done.
Mass-regenerating thumbnails and bulk-deleting unused media are destructive operations, and neither tool knows as much as it thinks it does. "Unused media" scanners look for images referenced in post content. They routinely miss images used in theme options, widget areas, custom fields, page builder settings, and CSS backgrounds. Click delete on that list and you find out which ones mattered one broken page at a time, usually a week later when a customer mentions it.
Thumbnail regeneration has its own failure mode. It rewrites files in place and can run for hours. If it dies partway through, you get a library of half-processed images and no undo.
This is exactly why snapshots exist. We take twice-daily verified off-site backups with 30-day retention, and before any media operation we take another one immediately beforehand. Then the question stops being "are we sure this is safe" and becomes "if this goes wrong, we restore and try a different way." That is a much better question. More on how that works in backups, monitoring, and recovery.
When it isn't worth doing
Sometimes the answer is to leave it alone.
If your site is a ten-page brochure with thirty images and already loads in under two seconds, a cleanup will win you nothing you can perceive. Spend the effort on the contact form instead. If the slowness is coming from a bloated plugin stack or a cheap shared server, fixing images makes a slow site marginally less slow and you will be disappointed. And if the library is enormous but the site is fast, the only real cost is backup time, which is our problem rather than yours.
The cleanup is worth doing when large originals are reaching visitors, when mobile performance is visibly worse than desktop, or when the site handles photography as a core part of what it sells. Otherwise it is housekeeping, and housekeeping can wait.
For sites on a Hosterr plan, checking what your images are actually doing is part of the job and part of the price. Reshaping a whole library is deeper work, so it falls under performance optimization at $95/hr, quoted before we start. You will never get a surprise invoice from us.
Frequently asked questions
Will converting my images to WebP make them look worse?
Not at normal quality settings. WebP at 80 to 85 percent quality is visually indistinguishable from the JPEG it replaced for almost every photograph. Screenshots with fine text and logos with hard edges deserve a closer look, and we keep the originals either way, so anything that looks wrong can go back.
Can I just install an image optimization plugin and be done?
Partly. A good plugin will handle compression and format conversion well. What it won't do is tell you that your page builder is calling the full-size original, or that your theme registered five thumbnail sizes it no longer uses, or that lazy loading is being applied to your hero image. Those are judgment calls, and plugins don't make judgment calls.
How do I know if my media library is the actual problem?
Load your slowest page on a phone, on cellular data, away from your office. If it takes noticeably longer than it does on your desk, images are the likeliest cause. Or email us and ask. We reply the same day, and telling you your images are fine is a perfectly good answer.
