Perf: reduce entry bundle + patch live data for a more instant UI

[Martin-Hausleitner]

Summary

The UI could feel considerably more “instant”/snappy. Below are concrete, file-referenced performance findings from a read-only audit against a recent build, plus a suggested quick-win ordering. Happy to help with PRs if useful.

⚡ Performance findings (file:line)

Area	Issue	Location	Impact
Browser entry	All pages statically imported → 4.09 MB entry chunk (1.15 MB gzip)	ui/src/App.tsx:1-60,278-340	high
Instant data	Live events invalidate queries → HTTP refetch instead of cache patch	ui/src/context/LiveUpdatesProvider.tsx:807-875	high
Live runs / API	up to 50 runs × 2 extra DB queries	server/src/routes/agents.ts:3171-3182	high
Issue list / API	default 500 / max 1000 + enrichment waves, no virtualization	server/src/services/issues.ts:89-91,3905-3955	high
Blocked inbox	builds company-wide graph, paginates via slice() afterwards	server/src/services/issues.ts:2451-2510	high
Run history	up to ~120 backfill queries (6 serial × 20 runs)	server/src/services/activity.ts:148-270	high
Scheduler	no time-leading index for due-retry	server/src/services/heartbeat.ts:5765-5776	high

✅ Suggested quick-win order

1. Lazy-load routes/onboarding + prefetch on link intent → shrink entry chunk
2. Patch full live payloads directly via setQueryData (optimistic) instead of refetch
3. On WS reconnect, snapshot-refresh visible keys
4. Virtualize issue list; batch DB queries (run_id IN (…))
5. Add missing indexes; validate with EXPLAIN (ANALYZE, BUFFERS)
6. UI first page 50–100 instead of 500, summary DTO + explicit include=

Note: some latency figures are unverified estimates; the file:line locations and the 4.09 MB entry chunk are measured on a production build.