Improve initial-load performance of the member dashboard via streaming/SSR

[Lakes41]

Difficulty: Advanced | Type: Performance

Background: This is a Next.js 14 App Router app, which supports React Server Components, streaming, and Suspense boundaries for progressive rendering.

Problem: If the member dashboard currently fetches membership/profile/resource data entirely client-side after hydration, first-load performance suffers (extra client-server round trips) compared to what App Router's streaming SSR could provide.

Expected Outcome: Non-wallet-dependent initial data (e.g. community info, public resource listing) is server-rendered/streamed, while wallet-dependent data (membership status for the connected address) hydrates client-side, with appropriate Suspense boundaries so the page shell renders immediately.

Suggested Implementation: Convert applicable dashboard sub-sections to Server Components fetching directly from the live API (server-side, avoiding CORS/client bundle cost) where they don't depend on the connected wallet, wrap wallet-dependent sections in Suspense with the skeletons from #1, and measure the before/after with Next.js's built-in performance tooling or Lighthouse.

Acceptance Criteria:

• Community/public resource sections render via SSR/streaming without waiting on wallet connection.
• Wallet-dependent sections still hydrate correctly client-side once connected.
• Measured improvement in Largest Contentful Paint / Time to First Byte, documented in the PR.

Likely Affected Files/Directories: app/(member)/*, app/layout.tsx, lib/api/live.ts

Labels: performance, architecture, GrantFox OSS, Maybe Rewarded, Official Campaign | FWC26

[Lixzon]

Good candidate for App Router's streaming model, and the split between wallet-independent and wallet-dependent data is the right boundary to design around.

Approach:

1. Audit app/(member)/* to split dashboard sub-sections into two groups: those needing only public data (community info, public resource listing) vs. those needing the connected wallet's membership status.
2. Convert the public-data sections to Server Components fetching directly from lib/api/live.ts server-side — removes the client round trip and CORS/bundle cost for data that never depended on the wallet in the first place.
3. Wrap wallet-dependent sections in <Suspense> with skeleton fallbacks (reusing the skeletons from Improve live API error handling #1 as suggested) so the page shell and public content stream in immediately, without blocking on wallet connection/hydration.
4. Keep wallet-dependent logic as Client Components (needs useAccount/wagmi hooks, which require the client), but scoped tightly to just what needs the wallet — not the whole dashboard.
5. Will measure LCP/TTFB before and after using Lighthouse (or Next.js's built-in reporting) and include the comparison numbers in the PR, per the acceptance criteria.

Will open a PR against a dedicated branch (perf/member-dashboard-ssr-streaming or similar) once ready.

[grantfox-oss]

🦊 GrantFox — @Lixzon has been assigned to this issue as part of the Official Campaign | FWC26 campaign!

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #248)
2. Your PR will be reviewed by the Adamantine-guild maintainers

Good luck! Track your progress on GrantFox.

[grantfox-oss]

🎉 This issue has been marked as completed on GrantFox as part of the Official Campaign | FWC26 campaign!

@Lixzon's PR #363 was approved and merged by @Lakes41.

🏆 @Lixzon: You earned 35 FoxPoints for this contribution! Your current tier: Explorer (519 total points). Track your full progress on GrantFox.

👏 Great work, @Lixzon! Keep contributing to Adamantine-guild.