WP Fastest Cache stores its page cache as static HTML on disk under wp-content/cache/all/ and wp-content/cache/wpfc-mobile-cache/, with minified CSS and JS landing in wp-content/cache/wpfc-minified/. The preload schedule and exclusion rules live in wp_options under the WpFastestCache and WpFastestCachePreload keys. The Delete Cache button on the toolbar fires a wholesale purge, which works for everyday operation and hides every interesting detail the moment a single URL misbehaves.

SleekView Kanban reads the same cache folders the plugin writes to. A derived wpfc_state field buckets URLs by whether an HTML file exists on disk, whether the preload cron has the URL queued, whether the file age is past the configured TTL, and whether the URL is in the exclude list. Card fronts can show the URL path, the cache file size, the file modification timestamp, the minified asset bundle name, and the mobile variant flag so a developer can spot stale or skipped pages without leaving the board.

Dragging a card between columns calls the WP Fastest Cache helper functions. A move from Stale back to Uncached deletes the on-disk file and re-queues the URL for the next preload tick. A move from Preloading back to Uncached cancels the in-flight cron task cleanly. The plugin's own automatic purge on post save keeps running, so a manual board action never collides with the plugin's normal cache invalidation flow.

Cache plugins make one promise. Visitors should receive a static HTML file instead of waking up PHP and the database for every request. WP Fastest Cache keeps that promise well on a small site, where the Delete Cache button and the preload schedule are enough tooling for one person to manage the cache by hand.

On a site with thousands of URLs spread across products, blog posts, and documentation, the same controls go opaque. A purge button hides the fact that only a small slice of URLs is actually stale. A preload schedule hides the fact that a handful of URLs are stuck on a slow third-party API and never finish.

The team relearns these blind spots every time a launch goes badly. A kanban board flips that around. Every URL is a card.

Every cache state is a column. A glance at the board tells the team how many URLs are uncached, how many are stuck in preload, how many are stale past their TTL, and which paths dominate each group. Dragging a card writes the change back to disk through the same helper functions the plugin already trusts.

The Delete Cache button still exists, and still works as a last resort. The board exists for the rest of the time, when the team wants to see the cache the way a cache plugin already sees it.