Skip to content

Issue 17: Strict Dynamic Component Code Splitting Tailored for Slow Field Networks #16

Description

@elizabetheonoja-art

Scope

File: src/app/layout.tsx

Problem

The initial JavaScript bundle includes all spatial rendering, tariff editing, and analytics libraries regardless of whether the user is a field engineer (needs only spatial + provisioning) or an administrator (needs tariffs + analytics). On slow field networks (2G/3G), this 500KB+ initial payload causes 10+ second load times.

Requirements

  1. Implement dynamic imports for heavy components:
    • GridMapnext/dynamic with ssr: false
    • LiveDataViewnext/dynamic
    • TariffEditornext/dynamic
    • TxModalnext/dynamic
  2. Each dynamic import should have a loading skeleton matching the component dimensions.
  3. Strip @stellar/stellar-sdk, bignumber.js, and canvas libraries from the initial critical path.
  4. Use React.lazy + Suspense as fallback for client-only transitions.
  5. Measure bundle size impact: target <150KB initial JS for field-focused routes.

Resolution Strategy

  • next/dynamic with named exports: dynamic(() => import("@/components/spatial/GridMap"), { ssr: false }).
  • Loading skeleton: same border-radius, height, and background as the actual component.
  • Verify with npx next build and check the .next/static/chunks sizes.

Tags

layout, performance, code-splitting, network

Metadata

Metadata

Assignees

Type

No type

Projects

No projects

Milestone

No milestone

Relationships

None yet

Development

No branches or pull requests

Issue actions