Back to Blog
Next.jsPerformanceCase Study

How I Reduced Load Time from 60s to 3s

A real-world case study on how I optimized a large Next.js portal with 25+ systems, tackling slow load times, legacy code, and poor architecture.

January 5, 202610 min read

When I joined SustainGRC, the main portal had a 60+ second initial load time. It was built with outdated patterns, bundled everything at once, and had no code splitting. Here's how I fixed it.

The Problem

The portal had 25+ systems all loaded eagerly on the initial page. No lazy loading, no route-based code splitting, and hundreds of unused dependencies were included in the bundle.

Step 1: Audit and Measure

Before optimizing, I measured everything using Lighthouse, Web Vitals, and Chrome DevTools. The bundle analyzer revealed that 70% of the JavaScript was unused on the initial page load.

Step 2: Route-Based Code Splitting

I restructured the app to use Next.js dynamic imports. Each system became its own route with lazy-loaded components. This alone cut the initial bundle by 60%.

Step 3: State Management Cleanup

The previous implementation stored everything in a global state, causing unnecessary re-renders across the entire app. I moved to a more granular approach with Zustand stores scoped to each system.

Step 4: Modern UI Component Library

I replaced the legacy UI components with a consistent, modern design system using Tailwind CSS. This eliminated duplicate styles and reduced the CSS bundle by 40%.

Results

  • Initial load time: 60s → 3s
  • Bundle size: reduced by 75%
  • Lighthouse Performance score: 35 → 92
  • User complaints about speed: eliminated

Enjoyed this article?

Follow me on Twitter or LinkedIn for more content.