Some pages in the Ever Teams web application are rendering large or complex components upfront, even when they are not immediately visible or used by the user. This causes unnecessary CPU/RAM usage and delays in initial page load or hydration, especially on complex views like /dashboard, /projects, /task/[id], etc.

Next.js supports native lazy loading of components via dynamic imports with the App Router. This feature allows us to defer the loading of heavy or non-critical UI blocks until the user needs them.

More info: https://nextjs.org/docs/app/guides/lazy-loading

Objective

The goal of this task is to:

1. Identify components within pages that are heavy, costly, or non-visible at first render.
2. Refactor them to be lazy-loaded using next/dynamic or similar patterns, as recommended by the Next.js App Router documentation.
3. Ensure no side effects or functionality loss occurs after the lazy loading (especially components with modals, forms, or context).
4. Document which components were optimized and how it impacted performance.

Acceptance Criteria

• Components are loaded only when needed (on interaction, or conditional render,on scroll,...).
• No layout shift or UI break introduced.
• Code is clean, clear, and consistent with our architecture.
• Performance gains (load time or memory) are measurable (optional but encouraged).
• Optional: usage of React.memo or useMemo to reduce re-renders when possible.

Scope of Work

• Investigate pages like:

  • /dashboard
  • /projects/[id]
  • /task/[id]
  • /timesheet
  • Any page with modals, nested tabs, editors, heavy charts or large tables

• Components that could benefit from lazy loading:

  • Rich text editors
  • Charts
  • Modal content not rendered initially
  • Tabs or views not visible at first
  • Components containing complex computations or heavy DOM trees
  • Time tracking and activities components

Suggested Approach

1. Use next/dynamic(() => import(...)) with { ssr: false } if necessary.
2. Check visually that the behavior is not broken (check transitions, animations, state).
3. Use React DevTools and browser profiler to validate reduced render time and JS heap.
4. Be cautious about side effects (e.g., authentication state, modals, useEffect calls).
5. Do not use lazy loading for components that are critical or layout-blocking.

Follow-up

Once implemented:

• Consider defining guidelines for lazy-loading practices across the codebase.
• Include performance profiling steps in the PR to support your refactor.

📌 References

• Next.js Lazy Loading Guide: https://nextjs.org/docs/app/guides/lazy-loading
• Example of lazy loading in App Router: https://www.freecodecamp.org/news/next-js-performance-optimization/

This task is part of our ongoing effort to improve performance, reduce memory usage, and make the app more responsive across devices.