An older media library is rarely as simple as its entry count suggests. One entry may have an original plus several generated sizes, and some of those files already appear in live articles. Count the work and test a small selection before using the full-library button.
Estimate the workload
One media entry can contain an original and several generated sizes. Review which sizes are selected in the WordPress plugin and how many API credits remain before starting.
Open a few real pages before starting and use the browser network panel to identify the image sizes the theme actually serves. Count both original uploads and selected variants, since an attachment may represent several files. Estimate the API workload from that list rather than from the attachment count alone. If a size belongs to an old theme and is never requested, decide whether it belongs in the batch at all.
Try a small set first
Choose JPEG photographs, a PNG with transparency and a WebP file. Compress them individually and inspect their pages. The plugin replaces a file only after validating the result and confirming it is smaller.
Choose samples that exercise different cases: a large photograph, an image with transparency and a small graphic containing text. After processing each one, check the attachment and the page that displays it. Compare the downloaded URL with the variant the plugin processed. Clear the relevant cache if the page still shows an older copy. Restore one sample original before a full run so the recovery path is familiar.
Three cases to check before a bulk run
- A new uploadTest one attachment and its variants before processing the library.
- Existing mediaEstimate the sizes in use and the remaining API balance.
- Repeated errorsInvestigate one file, fix the cause, then resume the queue.
Start a full pass
Use the bulk run in Settings → ANK Compress to process the full media library via WP-Cron. Progress is saved; you can pause and resume. The table button for the current page applies only to its 50 visible rows.
A background queue depends on WP-Cron being triggered. On a quiet test site, progress may pause until another request reaches WordPress or a server cron job invokes it. Record the pending and completed counts, then check whether they change over time. If progress stops, read the job error before restarting the batch; repeating a failing request without fixing its cause can waste time and API operations.
Choose a safe workflow
- A few files
- Process individually and inspect the pages immediately.
- A large library
- Start with a small sample, then monitor a background batch.
- A restore is needed
- Find the attachment in the plugin table and verify it on the page.
Check errors and originals
Look at the processed count and errors. For a failed file, check format, size, pixel count, balance and permissions for private original backups. Restore the original if the outcome is unsuitable.
Investigate recurring errors one file at a time. Confirm the file still exists, WordPress can open it, and its format and dimensions fall within the service limits. Check available disk space for the private original as well. Once the cause is fixed, retry that file, inspect the published page and only then resume the wider batch. A rising processed count is useful, but a working page is the real confirmation.
A practical example
A library with 600 entries does not necessarily mean 600 API operations: each photograph may have additional sizes. Choose one JPEG, one transparent PNG and one WebP. Inspect their live pages, check the remaining balance, and only then start a full pass.
Before you publish
- Match selected sizes to the variants your theme actually uses.
- Keep a restore path and try it on a test image.
- Watch progress and repeated errors separately during the batch.
Explore more
Check the result on your own website and keep an original when you may need to restore it.