NitroPack's strength is offloading optimization to a service. The plugin glue handles configuration and reporting, the service handles rendering, and the front end ships an optimized page. The trade-off shows up when a global PageSpeed score on the dashboard hides per-URL trouble. A handful of templates can fail optimization, accumulate warnings, and quietly serve unoptimized HTML while the headline number still looks fine.

SleekView Charts reads the nitropack_* options and per-URL post meta the plugin keeps locally and renders dashboard cards over the same data. A Number card carries the daily cache hit ratio, a Donut splits the optimization state across HIT, MISS, Pending, and Failed, a Bar surfaces the post types producing the most warnings, and an Area chart traces warning volume so the post-deploy spike becomes obvious before the next standup.

Charts never call the NitroPack service API directly. They only read what the plugin already stores locally, and inline purge actions route through the plugin's existing REST integration. The service stays the source of truth for cache state; the dashboard just surfaces it.

NitroPack does the heavy work on a service. That works as long as the service is succeeding for every URL, and it stops working the moment a template starts failing optimization while the dashboard score still looks healthy. The data needed to spot the gap already sits on the WordPress side: cache flags in options, warning counts per URL, and build timestamps in post meta.

Visualising those locally stored fields as Number, Pie, Bar, and Area cards turns the score into a dashboard, while the service keeps doing exactly what it did before.