Flying Pages Pro stores its prefetch rules in wp_options under flying_pages_settings, with serialized values for hover delay, viewport detection threshold, max RPS, max prefetches per session, and URL ignore lists. The Pro version adds keywords, regex patterns, and per device prefetch budgets, all serialized into the same option. When the optional logging add on is enabled, hit counts and prefetch attempts can be persisted to wp_options keys like flying_pages_log or a custom table.

The default Flying Pages Pro admin is a single settings screen. There is no view that lists every exclusion pattern as a row, no count of how many URLs each pattern matched, and no per template breakdown of prefetch behaviour. Operators tune settings, refresh the front end, and guess at impact. Multi site administrators face the same problem times every blog id.

SleekView reads flying_pages_settings and any companion log keys, unpacks the serialized lists into rows, and presents them as a queryable surface. Inline edits write back through Flying Pages Pro's own settings update path, so the plugin keeps owning the runtime behaviour. Saved views like Active exclusions or Recent prefetch failures can be scoped per role for delegating performance tuning.

Prefetch tuning sits between performance and reliability. Set the hover delay too aggressively and you flood the backend with speculative requests; set it too conservatively and the prefetch never fires before the user clicks. Flying Pages Pro exposes those knobs but offers no visibility into what is actually happening at runtime.

Operators end up tweaking values and reloading the front end to guess at impact. Multi site administrators face the same problem at network scale, with no way to compare prefetch posture across blogs. A queryable view turns the configuration into data.

SleekView reads the same options Flying Pages Pro already writes and surfaces them as flat rows alongside any match counts. That is enough to spot dead exclusions, find missing protections on cart and checkout paths, and tune budgets with evidence rather than guesswork. The plugin keeps owning the runtime; SleekView just makes the state legible.