Optimize startup latency: dependency caching, parallel init, and optional browser daemon

[DrEden33773]

Proposal

Reduce VHS startup delay. Currently, every vhs <tape> invocation goes through a fully serial pipeline — dependency checks, ttyd startup, Chromium cold-start, page navigation — before any recording begins. On most systems this adds 2–6 seconds of idle wait time.

I've analyzed the bottlenecks and built an implementation across three incremental optimizations, each backward-compatible:

1. Cache dependency checks — ensureDependencies() runs LookPath + ttyd --version every time. Results are now cached to disk with a 1h TTL.
2. Parallelize startup — ttyd and Chromium launch concurrently via goroutines instead of sequentially. An HTTP readiness probe ensures ttyd is listening before the browser navigates to it.
3. Browser daemon (vhs daemon) — optionally keep a headless Chromium running in the background. When available, VHS reuses it instead of cold-starting a new browser, eliminating the single largest bottleneck.

Root cause analysis

The startup call chain is fully serial:

ensureDependencies() → ttyd.Start() → launcher.LookPath() → launcher.Launch() → browser.Page() → Page.Wait(window.term)

The dominant cost is Chromium cold-start (1–5s), followed by the serial ordering of ttyd and browser init, and redundant dependency checks on every run.

Proposed solution

Phase 1 & 2: transparent optimizations (no user-facing changes)

• Dependency cache via go-app-paths DataPath (JSON, 1h TTL)
• sync.WaitGroup for concurrent ttyd + Chromium launch
• waitForTTYD() readiness probe (50ms poll, 10s timeout)

Phase 3: vhs daemon subcommand (new feature)

vhs daemon start       # launch persistent Chromium
vhs demo.tape          # reuses daemon — no cold-start
vhs daemon stop

# Or register as system service (systemd / launchd / Windows Service)
vhs daemon install
vhs daemon uninstall

When no daemon is running, VHS falls back to the existing behavior (now with Phase 1+2 optimizations).

Cross-platform service registration uses kardianos/service (new dependency).

Implementation

A working implementation is available on my fork: DrEden33773/vhs@feat/optimize-startup-latency

Key files:

• main.go — dependency cache logic
• vhs.go — parallel startup + daemon probe in Start()
• daemon.go — daemon lifecycle (Start/Stop/Health/URL), CDP URL persistence
• daemon_cmd.go — vhs daemon subcommands + kardianos/service integration
• daemon_test.go — unit tests for URL persistence

All existing tests pass (go test ./...), lint is clean (golangci-lint).

Related

• Issue #88 — discusses the long-term direction of removing the Chromium dependency entirely (the daemon approach is a pragmatic mid-term solution that works within the current architecture)