openclaw - 💡(How to fix) Fix Control UI: browser (F5) full-page reload re-fetches all API data — slow and state-less

Problem

When the user presses F5 (or clicks the browser refresh button) on the Control UI page, the entire page reloads and all API data is re-fetched from scratch. While the Service Worker (sw.js) caches the app shell and hashed assets well (cache-first for /assets/), API responses are explicitly excluded from caching:

if (
  url.pathname.startsWith("/api/") ||
  url.pathname.startsWith("/rpc") ||
  url.pathname.startsWith("/plugins/")
) {
  return; // never cache
}

This means on every full-page reload:

1. App shell loads instantly from Service Worker cache ✅
2. All <openclaw-app> state is lost (current tab, expanded items, selections)
3. Every API call (sessions.list, chat.history, etc.) goes directly to the network ❌
4. The user sees a blank/spinner state until all data loads

Impact

The most expensive reload is the sessions list (sessions.list), which by default loads ALL sessions with no pagination limit (limit=0). On a gateway with many sessions (especially archived ones), this can take multiple seconds on every F5.

Suggested improvements

1. API response caching in Service Worker (medium effort, high impact)

Add a stale-while-revalidate strategy for selected API endpoints in sw.js. The most impactful ones:

• GET /api/sessions or sessions.list RPC
• GET /api/chat/* (chat history)
• GET /api/status (gateway status)

Cache the response and serve it instantly on reload, then fetch fresh data in the background. This is a standard SW pattern and would dramatically improve perceived load time after F5.

2. UI state persistence across reloads (medium effort, medium impact)

Save lightweight UI state to sessionStorage so it survives F5:

• Active tab/view (sessions vs chat vs config vs ...)
• Expanded session checkpoint details
• Filter/search state
• Selected sessions

Restore on load before the fresh data arrives, so the user sees a consistent layout immediately.

3. Sessions list is still loaded all-at-once (smaller issue, related)

Even without F5, the sessions list uses limit=0 (unlimited) by default, which means it loads every session in one call. A practical default limit (e.g. 50+ Load More) combined with caching would make the initial load much faster.

Technical background

• Service Worker: ui/public/sw.js
• SW registration: ui/src/main.ts (on production builds)
• Current caching strategy: cache-first for hashed /assets/, network-first with offline fallback for everything else, and never cache for /api/, /rpc, /plugins/
• Full-relaod app state loss: The Control UI is a Lit-based SPA (<openclaw-app>) with no state persistence layer (no sessionStorage/IndexedDB for UI state)

Related

• ui/src/ui/controllers/sessions.ts — loadSessions(), full reload of session list
• ui/public/sw.js — fetch handler that explicitly skips API routes
• PR #85237 added Load More pagination to session list (2026.5.22)