[chubes4]

Related issues

• Follows Studio CLI: Import each date-fns function from its own path #5313 and Studio CLI: Load @inquirer/prompts when a prompt is shown #5316, which made each CLI process start faster. This change starts fewer of them.

How AI was used in this PR

Claude (via the Pi coding agent in a Roadie session) found the spawn pattern in CI logs, wrote the change and tests, and ran the local measurements below. I reviewed the design and the code.

Proposed Changes

The app ran site list --format json (a fresh CLI process each time) for every getSites()/getSite(). That covers each renderer refetch after a site event, and also each IPC handler that looks up a site. In a desktop E2E run, 252 of 362 CLI processes were site list.

The app already runs the _events stream, and each site event carries the site's full details plus running, computed the same way site list computes it. So the main process now keeps the list:

• src/lib/site-list-cache.ts: holds the CLI's site list.
  • It is filled by one site list and kept current by applying each site event.
  • It is used only while _events runs.
  • It refetches when:
    • a CLI command exits (a command's event can reach the stream after the command exits);
    • an event can't be applied;
    • the list is older than 2 minutes, which matches the renderer's poll and covers changes no event reports, such as a daemon crash.
  • Events that arrive during a fetch are applied to its result, so a reader that heard of an event never gets a list from before it.
• cli-events-subscriber.ts:
  • Applies each event before forwarding it to the renderer, so the renderer's refetch already sees it.
  • Goes live on the stream's first message, which comes after it listens for changes, so nothing falls in between.
  • Seeds its thumbnail state from that first read.
• execute-command.ts: adds onCliCommandFinished, which the subscriber uses to drop the list after commands.
• getSites(): unchanged for callers. Studio's metadata and PHP-recovery state are still merged on each read, and neither is cached.

Testing Instructions

• npx vitest run --project studio: 274 tests pass.
  • site-list-cache.test.ts covers events, overlapping reads, events during a fetch, dropping, age, failures, and running without the stream.
  • The subscriber test covers going live and dropping the list after commands.
• Local desktop E2E against packaged builds of this branch and its base 157fa556e (macOS arm64). CLI processes were counted with a wrapper around the bundled node:

Run	Base: site list / all CLI	This PR: site list / all CLI	Result
Full suite	252 / 362	110 / 219	34/34 passed on both
sites + site-navigation	89 / 136	44 / 91	17/17 passed on both

• tools/metrics site-startup test, 3 interleaved local runs each. These are local estimates; CI's Performance Test Results will be the real number.
  • siteStartup: 2318 / 2324 / 1817 ms vs base 3342 / 3325 / 2316 ms.
  • siteCreation: about the same (6436 / 6478 / 6976 vs 6967 / 6471 / 6437 ms).
• CI Performance Test Results: siteStartup 2865 → 2385 ms (−16.8%), siteCreation 6532 → 6500 ms, editor load unchanged.

Pre-merge Checklist

• Have you checked for TypeScript, React or other console errors?

[wpmobilebot]

📊 Performance Test Results

Comparing a7f0968 vs trunk

app-size

Metric	trunk	a7f0968	Diff	Change
App Size (Mac)	940.68 MB	940.68 MB	0.00 MB	⚪ 0.0%

site-editor

Metric	trunk	a7f0968	Diff	Change
load	1225 ms	1236 ms	+11 ms	⚪ 0.0%

site-startup

Metric	trunk	a7f0968	Diff	Change
siteCreation	6532 ms	6500 ms	32 ms	⚪ 0.0%
siteStartup	2865 ms	2385 ms	480 ms	🟢 -16.8%

---

Results are median values from multiple test runs.

Legend: 🟢 Improvement (faster) | 🔴 Regression (slower) | ⚪ No change (<50ms diff)

[youknowriad]

I think the only cache we should have in our application is the tanstack query cache, so this was an explicit decision I made and I'd rather not revert it. That said, we can tweak the tanstack query cache's config if needed.

[chubes4]

I'm interested in reducing latency in the CLI as this affects the entire application.

[youknowriad]

I think it's fair, but I'd like to understand the architectural impacts and whether they're worth it. The goal is good though. So I'm interesting in knowing whether we can achieve the same gain in startup time without introducing a new cache layer (some more fragility and bugs).

[chubes4]

Closing: agreed, the TanStack Query cache stays the only cache. The startup gain comes from startServer running site list to look up the site before site start; a follow-up can remove that lookup at its source instead.