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: auto so 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.