← Back to Blogs

Invalid Date

title: Tree-Shaking and Code Splitting: Strategies for Reducing React Bundle Size in Enterprise Apps date: 2026-05-14T07:46:18.987Z description: Blog about Tree-Shaking and Code Splitting: Strategies for Reducing React Bundle Size in Enterprise Apps

Stop Shipping 5MB Bundles: My Practical Guide to Tree-Shaking and Code Splitting

Hey everyone, I’m Prashuk Jain. I’m a full-stack developer who spends most of my day living in React and Next.js.

If you’ve ever worked on an enterprise-level app, you know how quickly things can spiral out of control. One day your app is snappy, and the next, you've added three heavy libraries for "essential" charts and a date picker, and suddenly your Lighthouse score is screaming at you in red.

I’m not a fan of over-complicating things with theory. Let’s talk about how I actually handle bundle sizes in the real world.

The "Oh No" Moment: When the Dashboard Crawls

I ran into this issue when I was building a massive SaaS dashboard for a fintech client. We had over 50 different components—modals, data tables, complex forms, and graphs—all living on one page.

Initially, we were shipping the entire bundle (about 2.5MB) to the user right at the start. On a slow 4G connection, the "Loading..." spinner felt like it lasted for an eternity. Honestly, it was embarrassing.

That’s when I realized we were breaking the first rule of performance: Don’t ship code the user doesn't need yet.

1. Code Splitting is Your Best Friend

The easiest win I’ve found is using dynamic imports. In React, we have React.lazy, but since I use Next.js mostly, next/dynamic is my go-to.

In that fintech project, we had a heavy "Report Generator" modal that used jspdf and some heavy filtering logic. Instead of importing it at the top of the file, I switched to a dynamic import.

What worked for me: Only load the heavy components when the user actually interacts with them (like clicking a "Download" button).

import dynamic from 'next/dynamic';
import { useState } from 'react';

// This is only loaded when needed
const HeavyReportModal = dynamic(() => import('../components/HeavyReportModal'), {
  loading: () => <p>Loading tool...</p>,
  ssr: false, // Useful if it uses window/document
});

export default function Dashboard() {
  const [showModal, setShowModal] = useState(false);

  return (
    <div>
      <h1>User Dashboard</h1>
      <button onClick={() => setShowModal(true)}>Generate Report</button>
      {showModal && <HeavyReportModal />}
    </div>
  );
}

2. The Tree-Shaking Trap

Tree-shaking sounds fancy, but it just means "tossing out the code you aren't using." However, a lot of devs think it happens automatically. It doesn't always.

In one of my projects, I realized we were importing lodash. We only used debounce, but we were accidentally pulling in the entire 70KB library.

My rule of thumb: Always check how you're importing.

  • Bad: import _ from 'lodash';
  • Good: import debounce from 'lodash/debounce';

Or better yet, use modern alternatives like radash or just native JS if you can. Every kilobyte counts when you're aiming for that sub-2-second load time.

3. Auditing with a Bundle Analyzer

I don’t like guessing what’s making my app fat. I use @next/bundle-analyzer (or webpack-bundle-analyzer if I’m on a legacy Create React App project).

Visualizing the bundle is a game changer. I remember running it once and seeing a massive rectangular block for a library called moment.js. It turns out one developer had used it for a single date format. We swapped it for date-fns (which is modular and tree-shakeable) and shaved 60KB off the bundle instantly.

4. Route-Based Splitting

In enterprise apps, users usually only visit one or two sections at a time. If I'm in the "Settings" page, why am I downloading the code for the "Analytics" engine?

Next.js does route-based splitting by default, which is great. But if you’re on a standard React SPA with react-router, make sure you are wrapping your routes in Suspense and using lazy() for your page components. It’s a 10-minute task that can cut your initial load time by 50%.

Best Practices I Follow

  • Lazy Load Images: Not directly bundle size, but it affects the perceived performance. Use next/image.
  • Check your package.json: Every 3 months, I go through the dependencies. If we aren't using it, it's gone.
  • Prefer ESM: Use libraries that support ES Modules. They tree-shake much better than old CommonJS ones.
  • Barrel Files are Dangerous: I’ve found that index.ts files that export 50 components can sometimes break tree-shaking in certain build setups. I try to import directly from the component file if the bundle looks weird.

My Takeaway

At the end of the day, performance is a feature. You can have the cleanest UI in the world, but if it takes 10 seconds to load, users will leave.

Start with a bundle analyzer, fix your imports, and use dynamic loading for anything that isn't visible on the first fold of the screen. Your users (and your Lighthouse score) will thank you.

Keep it clean, Prashuk