perf(web): defer non critical app load work#1081
Conversation
Deploying with
|
| Status | Name | Latest Commit | Updated (UTC) |
|---|---|---|---|
| ✅ Deployment successful! View logs |
supermemory-mcp | a8be1d2 | Jun 10 2026, 08:42 AM |
Deploying with
|
| Status | Name | Latest Commit | Preview URL | Updated (UTC) |
|---|---|---|---|---|
| ✅ Deployment successful! View logs |
supermemory-app | a8be1d2 | Commit Preview URL Branch Preview URL |
Jun 10 2026, 08:42 AM |
|
Claude finished @ved015's task in 3m 8s —— View job Review Complete
Summary: This PR cleanly defers non-critical app load work to improve initial render performance. All timeout patterns have proper cleanup, race conditions are handled with Score: 9/10 — Good to ship. |
There was a problem hiding this comment.
Overview: Defers non-critical data fetching (recents, connections, MCP status, billing, analytics) until after the initial app shell renders by introducing 900-1500ms timeouts and gating queries behind enabled flags.
Issues found: None — this looks good to ship.
The implementation is clean:
- All
setTimeoutcalls have proper cleanup functions in theiruseEffectreturns - The
cancelledflag pattern inauth-context.tsxcorrectly prevents stale state updates after unmount - The
OrganizationListItem→Organizationcast is safe sincehydrateFullOrg()runs immediately after and any field differences are short-lived - PostHog deferral correctly captures the initial pageview in the
loadedcallback, avoiding duplicates withPostHogPageTracking - Hook interfaces remain backward compatible (
usePersonalizationdefaultsenabled: true)
Score: 9/10
Summary
Why
Initial load was doing too much work at once. Only session/org context is needed to enter the app shell; dashboard suggestions, billing plan display, analytics, and secondary metadata can load shortly after.