Swift Performance Lite writes cached HTML to wp-content/cache/swift-performance/ per host and per URL, and stores its configuration in swift_performance_* options. The plugin's dashboard tab counts cached files and exposes a Clear Cache button, but there is no per-URL list of state, size, age and resolved post type, so questions like which templates produce the largest cached pages have to be answered through SSH.

SleekView reads the same cache directory and option rows and turns every cached URL into a table row. Cache state, file size, last refresh time and the resolved post type behind each URL become first-class columns with sort, filter and inline action. A maintenance engineer can scope the table to stale entries with one click, an agency lead can spot oversized cached pages without opening a terminal.

Swift Performance Lite keeps writing and serving the cache exactly as before. SleekView is read-only against the directory index and option rows, so the front-end cache pipeline and the existing rewrite rules continue without change.

Swift Performance Lite is fast at writing cache and aggressive about optimization, but the reading side is still a set of aggregate counters on a single dashboard tab. Cache size grows quietly, preload schedules drift, and a deploy can empty the cache without any visible per-URL signal. SleekView treats the cache directory index and the option rows as the structured data they already are.

Cached URLs become rows with state, size, refresh time and resolved post type, sortable and filterable, with inline action to trigger Swift's own refresh. The plugin keeps caching exactly as before; SleekView adds the reading layer the team can actually share, scoped per role and embeddable on the frontend.