EWWW Image Optimizer creates a dedicated wp_ewwwio_images table containing one row per processed file with columns like attachment_id, path, image_size, orig_size, level, updated, and updates. WebP conversions and async queue state live in wp_ewwwio_queue. Global settings (API key, compression mode, exclusions) live in wp_options under ewww_image_optimizer_* keys. The default Tools screen shows a Bulk Optimize button and a totals widget but no per-file list with savings.

SleekView reads wp_ewwwio_images directly and joins to wp_posts through attachment_id. One row per file can show the attachment, the file size, the original size, the saved bytes, the compression level used, whether a webp is present, and the last update time. Sort by saved bytes to find heavy wins, filter to attachments without a webp variant to triage delivery gaps, or group by level to confirm that aggressive compression is being applied where it should be.

SleekView never reoptimizes files itself. Inline actions invoke EWWW's own reoptimize function so the bulk queue, API quota, and conversion hooks behave exactly as the standard admin. Saved views like No webp variant or Updates over 3 can be scoped per role, useful for letting a developer triage regressions without giving them write access to ewww_image_optimizer_settings.

EWWW Image Optimizer is unusual among image plugins in that it keeps a real database table, not just postmeta. The intent is clear: every optimization event is a row, joinable to the attachment and queryable across the whole library. The default Tools screen does not lean into that design.

It shows totals, a bulk button, and per-attachment status only inside the media library row. The result is that the table's potential as an operational ledger is hidden behind a UI built for one-off conversions. SleekView reframes wp_ewwwio_images as exactly what its schema suggests: a list of compression events.

Saved bytes, level, webp flag, and update count become columns. Missed webp variants surface as a filter, reoptimization churn shows up as a high updates count, and developers can hand off a compression audit without writing a single line of custom SQL. The plugin keeps owning the optimization pipeline; SleekView just lets the team responsible for the library read the table.