Swift Performance Lite stores its page cache as static files under wp-content/cache/swift-performance/ with one folder per host. The warmup table sits in wp_swift_performance_warmup and tracks every URL the warmup script has queued, with a status column that flows through pending, processing, cached, and failed values. The Critical CSS log lives in wp_options under the swift_performance_ccss_log key and records every generation attempt. The default dashboard exposes a Clear All Cache toggle and a counter, which works on a small site and hides every interesting detail the moment one URL hangs the warmup script for the whole queue.

SleekView Kanban reads the same warmup table and cache folder the dashboard aggregates. Pick the warmup status column as the grouping and every URL becomes a card grouped under Uncached, Warming, Cached, or Stale. Card fronts can show the URL path, the cache file size, the warmup attempt count, the Critical CSS flag, and the last update timestamp so a developer can spot bottlenecks across the warmup queue without leaving the board view at all.

Dragging a card between columns calls the Swift Performance Lite helper API. A move from Stale back to Uncached deletes the cache file and re-queues the URL in the warmup table. A move from Warming back to Uncached cancels the in-flight worker. Swift Performance Lite's automatic purge on post save keeps running, so a manual board action never collides with the plugin's normal cache invalidation flow.

Swift Performance Lite gives the free-tier audience a lot of features. A page cache writes static HTML for anonymous visitors. A warmup script walks the sitemap and forces every URL into the cache before the first visitor hits the site.

A Critical CSS generator inlines above-the-fold styles for each template. Every one of those pipelines has a status column that flows through pending, processing, cached, and failed values. The dashboard reduces all of that to a single Clear All Cache toggle and a counter, which works on a small site and hides every interesting detail the moment one URL hangs the warmup script for an entire cron cycle.

A kanban board flips that around. Every URL is a card. Every status value is a column.

A glance at the board tells the team how many URLs are uncached, how many are mid-warmup, how many are cached with Critical CSS ready, and how many are stale past their TTL. Dragging a card writes the change back through the same helpers the warmup cron already trusts. The Clear All Cache toggle still exists, and still works as a last resort.

The board exists for the rest of the time, when the team needs to see the warmup queue the way the queue already sees itself.