Before you start
- ✓File access (SFTP or SSH) to the site's uploads folder
- ✓A full backup of the uploads folder
- ✓An image tool that can batch-process files (we used ImageMagick 7)
- ✓A way to regenerate thumbnails (WP-CLI or the Regenerate Thumbnails plugin)
- ✓A staging site to check the result on first
1. Measure what's actually in the uploads folder
Before changing anything, take a copy of the uploads folder and list every image by type and size. On a manufacturer's site we recovered there were 14,372 image files totalling 4.7 GB, and 11,041 of them were thumbnails WordPress had generated. Those came to only 1.3 GB. The weight was in the originals.
2. Target the originals, not the thumbnails
WordPress's own resized copies are easy to spot by their file names, so we set those aside and looked at originals above a size threshold. We used 500 KB, though the right cut-off depends on the site, and grouped what we found to see where the weight was:
| Original size | Files |
|---|---|
| Over 10 MB | 81 |
| 5–10 MB | 85 |
| 1–5 MB | 292 |
| 0.5–1 MB | 168 |
That gave 626 target files, about 3 GB between them.
3. Test the settings on the worst file first
Ours was a 73 MB PNG at 10,117 × 7,152 pixels. It came out at 6.9 MB, which told us the settings were safe for the rest.
4. Run a logged batch into a separate folder
We used ImageMagick 7, a free image tool, with three rules: cap the longest side at 2,560 pixels (only ever shrinking), strip hidden metadata such as camera details, and save JPGs at quality 82. PNGs stay lossless.
The output goes to a separate folder with the same structure, never over the originals, and every file is logged with its size and dimensions before and after. Our run processed all 626 files (413 JPG, 213 PNG) in about 8 minutes with no failures.
5. Read the log before you replace anything
This is where judgement comes in. Anything that got bigger keeps its original (see below), and anything that barely changed may be better in a different format. Only then do the optimised files go live.
6. Swap the files in and rebuild thumbnails
- Back up the uploads folder on the server.
- Upload the optimised originals over the old ones, with the same file names and locations.
- Have WordPress regenerate its thumbnails from the new originals (with WP-CLI or the Regenerate Thumbnails plugin).
- Check the pages with the heaviest images, and re-test with PageSpeed Insights.
7. Stop it happening again
WordPress already scales down uploads larger than 2,560 pixels, but it keeps the full-size original alongside, so a 50 MB photo still costs 50 MB of storage and backups. Resize images before upload, agree expectations with whoever uploads photography, and repeat the check once a year.
What usually goes wrong
From our own projects, not the manual.
Some PNGs got bigger after optimising
25 of the 213 PNGs grew, the worst by 12%, and 108 more saved under 5%. PNGs already under 2,560 pixels only had their metadata removed. Keep the original whenever the new file is larger, and convert large photographic PNGs to JPG or WebP instead.
Editing an image in WordPress doubled its weight
Cropping or rotating in the media editor saves a new full-size copy alongside the original. On this site a 73 MB original had a 63 MB edited twin. Include those copies when you hunt for big files.
Print-resolution photos went straight into the library
Originals up to 11,648 × 8,736 pixels had been uploaded as they came off the camera. The largest photo went from 49.8 MB to 0.5 MB once capped at 2,560 pixels.
The saving applied to the originals, not the whole library
The 3 GB to 0.7 GB result is across the 626 oversized originals. The whole uploads folder held 4.7 GB of images, mostly thumbnails. Measure both, so the number you report is the one you actually got.
Optimising originals doesn't touch existing thumbnails
Thumbnails are separate files WordPress generates. Until you regenerate them, pages keep serving the old ones, so don't skip that step.
Do it yourself, or get help?
If you're comfortable with command-line tools and have file access and a backup, you can do this yourself in an afternoon: the batch itself takes minutes. If there's no staging site, no reliable backup, or you're not sure which files are safe to replace, get help, because a bad bulk replace across thousands of images is painful to undo.
Get a developer on it