When I first started working with Next.js, I was amazed by how fast and efficient it was. The automatic optimizations, built-in server-side rendering (SSR), and static site generation (SSG) made it seem like performance was never going to be an issue. But as my projects grew, I started noticing something strange, pages that were once lightning-fast became sluggish. Even though I followed the best practices for optimizing images, caching, and reducing unnecessary API calls, the load times weren’t improving.

After digging deeper, I realized the real problem: poor code splitting. It wasn’t something that stood out immediately, but once I understood how it worked, it changed the way I structured my Next.js projects forever.

1. What is Code Splitting, and Why Does It Matter?

Code splitting is exactly what it sounds like, splitting your JavaScript code into smaller bundles so the browser doesn’t have to download everything at once. The idea is simple, only load the code the user needs at that moment. Next.js does some automatic code splitting based on pages, but if you’re not careful, you can still end up with huge JavaScript bundles that slow down your app.

Poor code splitting can lead to:

• Longer initial load times: If too much JavaScript is bundled together, users have to download and parse a large file before they can see anything.
• Sluggish performance on mobile: Many users access websites on mobile devices, and large scripts can make things painfully slow.
• Higher memory usage: When too much code is loaded unnecessarily, it takes up memory and affects performance.

2. Mistakes I Made (So You Don’t Have To)

Importing Everything at the Top

One of the first mistakes I made was importing all components globally, even if they weren’t needed on the initial page load. I had a dashboard with multiple sections, charts, tables, modals, but everything was being loaded right away, even if the user never interacted with certain features.

Bad Example:

import Chart from ’some-heavy-chart-library’;

import Modal from ’../components/Modal’;

This meant that even if the user never opened the modal or viewed the chart, those components were still being loaded.

Better Approach:

import dynamic from ’next/dynamic’;

const Chart = dynamic(() => import(’some-heavy-chart-library’), { ssr: false });

const Modal = dynamic(() => import(’../components/Modal’));

With this approach, the chart and modal are only loaded when they are actually needed.

Overloading app.js

Another big mistake was putting too much logic inside app.js. Since this file wraps every single page, adding heavy libraries or state management logic here can lead to unnecessarily large JavaScript bundles. Instead, I started loading global dependencies only when absolutely necessary.

Ignoring Lazy Loading for Third-Party Libraries

I used to install libraries like moment.js, lodash, and charting libraries without thinking about their impact on performance. Many of these libraries are massive, and including them directly in components that load immediately was a big mistake. The solution? Lazy load them using next/dynamic or only import the parts I needed.

3. How to Check If You Have a Code Splitting Issue

If your Next.js app feels slower than it should, you might have a code splitting problem. Here’s how to check:

• Use Next.js Bundle Analyzer – Install it with: npm install @next/bundle-analyzer

Then, add it to your next.config.js and run ANALYZE=true npm run build to see which parts of your app are taking up the most space.

• Inspect Chrome DevTools Network Tab: If your JavaScript bundles are too large, you’ll see them in the "Network" tab when you load your site.
• Check Lighthouse Performance Score: A low score often means you’re shipping too much JavaScript upfront.

Final Thoughts

Code splitting is something many developers overlook until they run into performance issues. If you’re building a Next.js app, don’t wait until it’s too late, start thinking about code splitting early. By using dynamic imports, lazy loading heavy libraries, and keeping _app.js lightweight, you’ll ensure your app stays fast, even as it scales.