Lazy Load by WP Rocket keeps a small surface: one options screen, the rocket_lazyload_options row, and a render-time rewrite that adds the loading attribute and data-lazy-src to img, iframe and video tags. There is no per-post list of what was rewritten, no way to filter by post type, and no audit screen for the assets the plugin actually defers.

SleekView reads the same option row and scans the post_content of published wp_posts for the markers Lazy Load by WP Rocket writes at render time. Asset type, host post title, host post type and post date sit as sortable, filterable columns next to a permalink. Pull every lazy iframe across page templates, or every lazy video on a custom post type, without opening each post.

Inline edits run through the standard WordPress CRUD layer, so post-save hooks still fire and Lazy Load by WP Rocket continues to rewrite tags at render time as before. Bulk-update the host post status or fix a slug across many rows; the plugin's rewrite pipeline is not touched.

Lazy Load by WP Rocket is intentionally small. A few toggles, one option row, a render-time rewrite. That keeps configuration honest, but it leaves the team with no feel for how the rewrite plays out across hundreds or thousands of posts.

SleekView reads the option row and indexes the rewritten asset markers as the structured data they already are. Engineers stop guessing whether the rewrite reached the new product template. Agencies stop opening posts to confirm coverage.

Editors stop wondering whether the iframe they just embedded is being deferred. The plugin keeps doing the lightweight rewrite work it does well, and SleekView gives the team a reading layer they can share.