Web Performance
Loading-path architecture, budgets, and verification for the Clapilot web app.
Clapilot prioritizes useful persisted data before remote synchronization and keeps optional surfaces off the critical navigation path.
Loading-path rules
- The root language provider starts from the server cookie, owns one dictionary/listener set, and prevents a German-to-selected-language hydration refetch.
- The global chat rail loads the full floating chat only when expanded or after an idle window for users who left it expanded.
- Email, Calendar, and Documents paint persisted database/cache state first. Provider synchronization is explicit or scheduled after browser idle and must not block navigation.
- Dashboard and task lists use compact task payloads and SQL aggregates; task details and attachments load from the dedicated detail route.
- Module inventory uses a short process cache and direct slug lookup. Module pages request one manifest; static module assets use ETags and private browser caching.
- Long email, task, and chat rows use
content-visibility: autoso off-screen rows do not consume initial layout/paint work.
Regression gates
npm run perf:bundle:gate checks raw, gzip, and Brotli JavaScript totals and per-chunk limits. Environment overrides are PERF_MAX_CHUNK_KB, PERF_MAX_TOTAL_JS_MB, PERF_MAX_CHUNK_BROTLI_KB, and PERF_MAX_TOTAL_JS_BROTLI_MB.
npm run e2e:local:performance covers Dashboard, Chat, Documents, Email, Tasks, Calendar, Canvas, and Agent Orchestrator. Route checks record interactive time and include request-count, transferred-byte, compact-payload, provider-sync, and overlapping-poll assertions where applicable.
Use a production build for bundle comparisons. Browser development-server measurements are useful for request fan-out and behavior, but they are not production latency SLAs.
