When we shipped a cross-site dashboard in v1.6.2 — a single view that shows plugin-update status across multiple WordPress sites — we hit a UX wall almost immediately. Opening the dashboard meant waiting 24.5 seconds, every time. And the wait got longer as more sites were added.
A user put it bluntly: "It launches a heavy operation the moment I open it. I wasn't mentally prepared for that." This post walks through the slightly unusual async-UX combination we landed on for that page — cache-first display, explicit fetch, and a "closes-but-keeps-running" notice.
What was eating the time
Under the hood, the dashboard was running parallel SSH scans against every connected site, invoking wp plugin list --update=available and aggregating which plugins needed updates. Reasonable behavior for a WordPress maintenance tool, but doing it on every open meant a multi-second silence every time.
Note: SSH (Secure Shell — the protocol used to log into servers and run commands securely) is being used here to call WP-CLI (the official WordPress command-line interface) on each site. We were already parallelizing, but the sum of network latency and per-site response time still landed as a noticeable load wait.
