Fine-Grained Code Splitting Configurations Tailored for Limited Edge Connections

[JamesEjembi]

Problem Statement

Heavy charting packages and crypto parsing bundles degrade page loads on slow mobile connections. The current monolithic bundle weighs 2.4 MB (uncompressed) and includes all charting libraries (Recharts, d3, vis-network), crypto libraries (@stellar/stellar-sdk, tweetnacl, bignumber.js), and the full UI component tree — all loaded on every page regardless of whether the user lands on the login page or the analytics dashboard. First Contentful Paint on 3G is 8.2 seconds, well above the 2.5s target.

Technical Bounds & Invariants

• Target FCP on 3G (400 kbps, 400ms RTT): < 2.5 seconds
• Target Time to Interactive (TTI) on 3G: < 4 seconds
• Maximum critical bundle size for initial route (login): < 100 KB gzipped
• Code splitting granularity: route-based + component-level (dynamic import for heavy components)
• Framework: Next.js 14 App Router (supports next/dynamic and React.lazy natively)

Codebase Navigation Guide

• Primary target: /src/app/dashboard/layout.tsx
• Route structure: /src/app/(auth)/login/page.tsx, /src/app/(dashboard)/dashboard/page.tsx, /src/app/(analytics)/analytics/page.tsx
• Current import map: /src/app/layout.tsx — global imports at lines 1-20
• Bundle analysis config: /next.config.js — withBundleAnalyzer at line 10

Step-by-Step Resolution Blueprint

1. Analyze the current bundle composition using @next/bundle-analyzer to identify the top 10 largest modules; record baseline sizes in a ticket comment
2. Configure next/dynamic with ssr: false for all charting components: const AttestationChart = dynamic(() => import('@/components/charts/AttestationPerformance'), { ssr: false, loading: () => <ChartSkeleton /> }) — charts are loaded only on the analytics route
3. Create a lazy-loaded CryptoCore module that defers @stellar/stellar-sdk import to when wallet interaction is first triggered (not on page load): const StellarSdk = await import('@stellar/stellar-sdk') called inside useWeb3Auth().login() — the SDK bundle is fetched only when the user clicks "Connect Wallet"
4. Add route group layout splitting: wrap (auth) routes in a minimal layout that imports only login-specific CSS and components; wrap (dashboard) routes in the full layout with sidebar and nav; wrap (analytics) with analytics-specific heavy imports
5. Configure experimental.nextScriptWorkers: true in next.config.js and move non-critical third-party scripts (Sentry, analytics, hotjar) to a Partytown web worker
6. Add resource hints: <link rel="preload" href="/fonts/Inter-Regular.woff2" as="font" type="font/woff2" crossorigin> for critical fonts; add <link rel="modulepreload" href="/_next/static/chunks/app/(dashboard)/layout.js"> for the most common landing route after login
7. Set a performance budget CI check: add a Lighthouse CI step in GitHub Actions that asserts: FCP < 2.5s, TBT < 200ms, LCP < 4s on a simulated 3G connection; fail the build if any budget is exceeded

[aliyuHabibu]

Hi, I'm a software engineer, I've gone through the issue and I can resolve it. Assign it to me thank you

[BarryArinze]

I’d like to work on this issue.

The main problem is that heavy charting, crypto, and analytics dependencies are being loaded for every route, significantly impacting FCP and TTI. I would address this by implementing route-level and component-level code splitting using Next.js 14 dynamic imports.

My approach includes:
• Running bundle analysis to identify the largest modules and establish a baseline.
• Lazy loading charting libraries with next/dynamic and loading them only on analytics pages.
• Deferring @stellar/stellar-sdk and related crypto packages until wallet actions are triggered.
• Splitting layouts for auth, dashboard, and analytics routes to avoid loading unnecessary code.
• Moving non-critical third-party scripts to web workers where appropriate.
• Adding preload/modulepreload hints for critical assets and common navigation paths.
• Adding Lighthouse CI performance budgets to prevent regressions.

This should significantly reduce the initial bundle size and help achieve the target FCP and TTI requirements while maintaining functionality across routes.

Thank you for your consideration.

[grantfox-oss]

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

Next steps:

1. Open a Pull Request referencing this issue (e.g., Closes #17)
2. Your PR will be reviewed by the VeriNode-Labs 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 campaign!

@BarryArinze's PR #90 was approved and merged by @JamesEjembi.

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

👏 Great work, @BarryArinze! Keep contributing to VeriNode-Labs.