Flying Images rewrites image URLs to the Statically CDN for on-the-fly resizing and modern-format delivery, and lets the browser handle native lazy loading. The settings screen has a CDN toggle, a native lazy-load toggle, an exclusion list and not much else. There is no per-attachment list of which images actually go through the rewrite and which got pruned by an exclusion.

SleekView reads the same options, the cached rewrite map and the standard attachment graph (wp_posts where post_type = 'attachment' joined to wp_postmeta), then renders each attachment as a row. CDN status, MIME type, parent post type, template and upload date become first-class columns with sort, filter and inline action. A performance lead can scope the table to attachments excluded from the CDN, an editor can spot a template that loads fifty images above the fold.

Flying Images keeps rewriting URLs on the front end exactly as before. SleekView is read-only against the options, the rewrite map and the attachment graph, so the front-end image pipeline stays untouched.

Flying Images keeps its admin surface deliberately small: a CDN toggle, a native lazy-load toggle, an exclusion list. That thinness is part of why the plugin stays installed, and it is also why most teams cannot answer obvious questions a year later. Whether the rewrite still reaches every attachment.

Whether a new plugin pushed raw PNGs through a path the optimiser does not touch. Which templates carry the bulk of image weight. SleekView treats the options, the rewrite map and the attachment graph as the structured data they already are.

Attachments become rows with CDN status, MIME, parent post and upload date, sortable and filterable, with inline action to open the parent post. The plugin keeps rewriting URLs exactly as before, SleekView adds the reading layer the team can actually share and scope per role.