The WebP Migration That Wasn't About WebP: A WordPress Audit Story
Discovering why a simple image conversion task on a WooCommerce site revealed orphaned files, missing thumbnails, and hidden server bottlenecks.

Stock photo for illustration only, not from the actual event
- Auditing upload directories before installing plugins prevents accumulating digital clutter.
- Image optimization plugins often leave behind orphaned files after uninstallation.
- Fixing missing image size ladders improves performance more than simply changing formats.
When a site administrator decided to spend a quick afternoon converting images to WebP on an 8-year-old WooCommerce and LearnDash platform running on a Divi theme, the goal seemed straightforward. The plan was nearly finalized by installing ShortPixel and calling it a day to reduce overall page weight.
Instead of rushing into the installation, a twenty-minute pre-audit revealed that WebP format was perhaps the fourth most important issue facing the site. Installing an automated optimizer plugin immediately would have exacerbated existing problems, especially since the site runs on a 4GB VPS that had already experienced two out-of-memory crashes for MySQL that quarter.
Running terminal commands inside the uploads directory produced a startling discovery: 12,301 WebP files existed on a site that supposedly had none. The naming convention ending in .jpg.webp identified them as sidecar files generated by EWWW Image Optimizer, which had long since been removed from the environment.

Stock photo for illustration only, not from the actual event
These files constituted 241 megabytes of dead weight, continuously scanned by malware utilities and included in every backup despite having zero references in the database. Verifying their absence through WP-CLI queries allowed for safe deletion, reclaiming valuable storage space. The key takeaway is that optimization plugins leave their output behind when uninstalled.
Inheriting legacy WordPress sites requires thorough investigation of upload folders using command-line tools before introducing new plugins, ensuring that redundant legacy assets do not silently consume server performance and backup quotas.
Further investigation uncovered an improperly configured thumbnail threshold plugin that disabled eighteen intermediate sizes. Consequently, WooCommerce performed on-the-fly Imagick resizing for 94% of product image requests, heavily taxing a CPU-constrained server environment.
Ultimately, solving the performance bottleneck required correcting the missing image size hierarchy and render-time filters rather than blindly converting raster formats into WebP.
Source: Dev.to
Found something wrong in this article? Report an issue with this article
Comments
Leave a Comment