EWWW Image Optimizer Cloud reports a single big number on its settings page: total bytes saved across the library. That summary is useful once, but it hides everything interesting underneath. Which post types compress the best? Which conversion target (WebP, AVIF, JPG) carries the bulk of the savings? Is the queue draining? Are cloud credits being spent evenly across the month or in one burst after an import? The default admin answers none of those questions.

SleekView Charts reads the same EWWW data as a normal source. A Number KPI sums the savings column on ewwwio_images, a Donut splits the library by conversion target using the converted column, a Horizontal Bar ranks post types by saved bytes (joined through attachment IDs), and a Gradient Area traces optimized bytes by month using the updated timestamp. Cloud credit usage joins from the API key option for a fifth view when needed.

EWWW keeps writing rows where it always has. Charts query the same ewwwio_images and ewwwio_queue tables EWWW maintains, and saved dashboards can be scoped per role so a content lead reads savings while a developer watches the cloud queue. No second store and no rebuilt aggregator.

EWWW Image Optimizer Cloud earns its money by squeezing every JPEG, PNG, WebP, and AVIF on the site. The savings are real, and they end up in a single global counter that is good for marketing copy and not much else. The data underneath, per-image bytes, conversion target, optimization level, and updated timestamp, already sits in two small tables EWWW maintains with the right indexes.

Visualising those tables as Number, Pie, Bar, and Area cards costs nothing on the writing side and reframes the same rows as a dashboard. The cadence of media review shifts from a quarterly counter check to a daily glance, and the library stays exactly where EWWW left it.