 is a product-minded Full-Stack Engineer. He is the co-founder of 

, an enterprise-grade multi-tenant communication SaaS platform. Beyond architecting low-latency infrastructures and advanced AI systems, Kanat is a dedicated student of peak performance—optimizing his lifestyle through rigorous fitness, precise nutrition, and creative production in music. He operates on the core philosophy that breakthrough technical results stem from a high-functioning, deeply disciplined life.

Kanat Nazarov

If you’ve built web apps in Next.js, you’ve probably run into this problem:

You need a feature like a rich-text editor, an interactive chart, or a code syntax highlighter(or any heavy package dependecy). So you 

 the package, import it into your page, and move on.

Everything looks fine on your local machine. But when you run a Lighthouse test, your 

 score drops, and the initial JavaScript bundle size explodes.

Here is why that happens—and how to fix it in under 5 minutes without changing how your app works.

When you write a standard import at the top of a file:

Next.js bundles that entire library directly into the main page payload.

Even if the editor sits at the very bottom of the page, or inside a modal that hasn't been opened yet, 

every visitor has to download, parse, and execute that entire 400KB file before your page can finish loading.

Instead of loading everything upfron we can split the code so the browser will download 

To do this cleanly without breaking layout or server-side rendering (SSR), we split our code into three small files:

Step 1: Put the Heavy Library in Its Own Component

, which is a fantastic editor, but pretty heavy (~750KB):

While the heavy code chunk downloads over the network, we render a quick 

 > Many client-side editor or canvas libraries look for browser objects like 

. If Next.js tries to render them on the server during build time, it will crash with 

 stops Next.js from rendering this component on the server, safely isolating it to the browser.

By making this small architectural change, we got noticeable performance gains:

 The main page loads instantly, displaying a clean skeleton box for ~200ms while the editor chunk arrives.

Don't let third-party tools slow down your main page.

 If a component requires a heavy package, lazy-load it.

 If you lazy-load without a placeholder, the page content will jump once the component loads, ruining your Cumulative Layout Shift (CLS) score.

How I Learned This as my personal experience.

Back in 2024, during a major migration from an old WordPress setup to Next.js, our team realized that simply moving to a modern framework doesn't automatically make your app fast if you bring along bloated third-party dependencies.

 and SSR guards, we chopped hundreds of kilobytes off our initial bundle size and got the sub-second page loads our users actually expected.

What’s your go-to trick for keeping your Next.js bundle lean? Let’s chat in the comments!

KANAT NAZAROV

KANAT NAZAROV

How I Saved 400KB in Next.js by Fixing Heavy Imports

Logs & Discussion1

Leave a comment

Kanat Nazarov