WP Meteor delays third-party JavaScript until a user interaction or timeout, with its global configuration stored in the wpmeteor_settings option. The Pro version exposes per-page overrides via wpmeteor_page_override postmeta, exclusion lists for handles or URLs that should run immediately, and trigger event configuration (timer, scroll, click). The default admin shows the global toggle and a textarea for exclusions but no audit of which pages override the default behaviour or which handles are delayed where.

SleekView reads the WP Meteor options and the per-page postmeta so the same data sits as flat rows. One row per page can show whether delay is on, how long the timer is, which handles are excluded, and which trigger events are active. Exclusion patterns become a second table with their match counts so unused entries become candidates for removal. Trigger events surface as their own grouping with timer duration and the registered DOM events.

SleekView is read-only against page configuration unless an inline edit is invoked, in which case writes go through WP Meteor's standard option and meta APIs. The plugin continues to gate JavaScript execution exactly as before. Saved views like Pages overriding the global delay or Handles never excluded scope per role so a developer can audit delays without access to the licence key or trigger event configuration.

WP Meteor sells a simple idea: delay every third-party script until the user interacts with the page, and the LCP report improves overnight. The plugin executes that idea well, but the configuration drifts. Six months in, a few campaign landing pages have been excluded, a couple of admin reports have lost their delay because someone toggled a checkbox, and the global timer no longer matches what the developer onboarded with.

The default admin shows the toggle and the textarea, but nothing pivots the data into a list. Most teams notice a regression only when an interactive element feels sluggish or when a campaign reports zero events for the first hour. SleekView treats wpmeteor_page_override postmeta as the ledger it already is.

Each page is a row, each handle is a filter, and each exclusion is a pattern with a match count. Performance engineers can refactor delay rules in bulk, agencies can audit client configuration before a launch, and developers can toggle a page back to the global default without combing through admin tabs. The plugin keeps doing the delay; SleekView just lets the team read the rules.