Flying Pages prefetches internal links on hover, on viewport entry, or on idle, governed by the flying_pages_* options (delay, max requests, ignore keywords, excluded URLs). The settings screen is a handful of toggles and an exclusion textarea, and that is the entire admin surface. There is no per-URL list of which links actually qualify and which got pruned by an ignore keyword.

SleekView reads the same options and joins them to the internal link graph in wp_posts, then renders every candidate URL as a table row. Prefetch mode, post type, template, exclusion match and event count (when the optional prefetch log is enabled) become first-class columns with sort, filter and inline action. A performance lead can scope the table to URLs excluded by a single rule, an editor can spot a template that funnels disproportionate prefetch candidates.

Flying Pages keeps prefetching on the front end exactly as before. SleekView is read-only against the options, the link graph and the optional event log, so the prefetch path on visitor sessions is untouched.

Flying Pages keeps its admin surface deliberately thin: a few toggles, an exclusion textarea, no per-URL list. That minimalism is fine on install day and frustrating a quarter later when a CDN rule changes, an editor adds a campaign landing page or an exclusion keyword starts matching more URLs than intended. SleekView treats the rules and the internal link graph as the structured data they already are.

Prefetch candidates become rows with mode, template, exclusion match and event count, sortable and filterable, with inline action to edit the relevant rule. The plugin keeps prefetching exactly as before, SleekView adds the reading layer the team can actually share and scope per role.