DEV Community: saijami

Cutting React Bundle Size by 72%: A Deep Dive into main.chunk.js & vendor.chunk.js

saijami — Tue, 23 Dec 2025 03:38:10 +0000

When I ran npm run build on our React production app, the numbers were alarming:

main.chunk.js: ~2.27 MB (gzip)
vendor.chunk.js: bloated with libraries used only in edge flows
Warning: “The bundle size is significantly larger than recommended”

This post breaks down how I reduced the frontend bundle size by 72%, focusing specifically on:

Component lazy loading
Route-based lazy loading
Dynamic imports
Minification
And how these changes directly impacted main.chunk.js and vendor.chunk.js

Understanding the Problem: Why main.chunk.js & vendor.chunk.js Matter

Before optimization:

main.chunk.js
Contained:

App bootstrap logic
All routes
All components (even unused ones)
Business-heavy modules (Inventory, POS, Admin, etc.)

vendor.chunk.js
Contained:

React + ReactDOM
UI libraries
Utility libraries
Large dependencies used only on specific pages

This meant every user downloaded everything upfront, regardless of what they actually used.

1️⃣ Component-Level Lazy Loading

❌ Before: Eager Component Imports

import HeavyTable from "./components/HeavyTable"; import Charts from "./components/Charts";
Even if these components rendered conditionally, they were still bundled into main.chunk.js.

✅ After: Component Lazy Loading
const HeavyTable = React.lazy(() => import("./components/HeavyTable") ); const Charts = React.lazy(() => import("./components/Charts") );
Wrapped with:
<Suspense fallback={<Loader />}> <HeavyTable /> </Suspense>

📉 Impact on Bundles

main.chunk.js stopped carrying rarely-used components
New component-specific chunks were created
Initial JS execution dropped significantly

2️⃣ Route-Based Lazy Loading

❌ Before: All Routes in main.chunk.js
import Inventory from "./pages/Inventory"; import POS from "./pages/POS"; import Admin from "./pages/Admin";
Every route → bundled upfront.

✅ After: Route-Based Lazy Loading
const Inventory = React.lazy(() => import("./pages/Inventory")); const POS = React.lazy(() => import("./pages/POS")); const Admin = React.lazy(() => import("./pages/Admin"));
<Suspense fallback={<PageLoader />}> <Routes> <Route path="/inventory" element={<Inventory />} /> <Route path="/pos" element={<POS />} /> <Route path="/admin" element={<Admin />} /> </Routes> </Suspense>

📉 Impact on Bundles
main.chunk.js now only contains:

App shell
Router
Core layout
Each route became an independent chunk
Users download code only when they navigate

3️⃣ Dynamic Imports (Targeting Vendor Bloat)

Some libraries were used only in specific flows (exports, charts, reports).

❌ Before: Static Import
import ExcelJS from "exceljs";
Now every user downloads ExcelJS, even if they never export anything.

✅ After: Dynamic Import
async function exportData() { const ExcelJS = await import("exceljs"); // use library here }

📉 Impact on Bundles

vendor.chunk.js shrank significantly
Heavy libraries moved to on-demand chunks
Vendor code stopped blocking initial render

4️⃣ Minification: Squeezing the Final Bytes

Minification is not optional — it’s the last mile optimization.

What Minification Did:

Removed dead code
Shortened variable names
Eliminated whitespace & comments
Optimized conditionals

Result:

Smaller main.chunk.js
Smaller vendor.chunk.js
Faster parse & execution time in the browser

📊 Before vs After: Real Build Output

Before Optimization

main.chunk.js: ~2.27 MB (gzip)
vendor.chunk.js: Large, monolithic
Single heavy JS download
Long main-thread blocking

After Optimization

main.chunk.js: ~615 KB (gzip)
vendor.chunk.js: Lean core dependencies only
Dozens of feature-based chunks
JS downloaded progressively

👉 72% total bundle size reduction

⚡ What Happens to App Performance When These Shrink?

Reducing main.chunk.js and vendor.chunk.js directly impacts:

🚀 Faster Initial Load

Less JS to download
Faster Time-to-First-Byte (TTFB)
Faster First Contentful Paint (FCP)

🧠 Faster JS Parsing & Execution

Browsers spend less time parsing JS
Main thread is unblocked sooner
UI becomes interactive faster

📱 Better Performance on Low-End Devices

Lower memory usage
Less CPU pressure
Fewer dropped frames

🔄 Better Long-Term Scalability

New features don’t inflate initial load
App remains fast as it grows

Final Takeaway

Most React bundle issues are architectural, not tooling problems.

If your:

main.chunk.js is massive
vendor.chunk.js keeps growing

Then:

Your app is doing too much upfront
And users are paying the cost

Fix the loading strategy —
the bundle size will follow.

Get rid of useEffect for Data: Why React Query is a Game Changer

saijami — Mon, 04 Aug 2025 03:23:45 +0000

This document explores the limitations of using useEffect and useState for data fetching in React applications and introduces React Query as a superior alternative. It highlights the benefits of React Query, such as automatic caching, refetching on focus, built-in loading/error states, and smart syncing, which significantly reduce boilerplate code and improve the overall development experience. The document aims to encourage developers to consider React Query for more efficient and maintainable data management in their React projects.

The useEffect + useState Struggle

For a long time, the go-to pattern for fetching data in React involved a combination of useEffect and useState. It looked something like this:

import React, { useState, useEffect } from 'react';

function MyComponent() {
  const [data, setData] = useState(null);
  const [loading, setLoading] = useState(false);
  const [error, setError] = useState(null);

  useEffect(() => {
    const fetchData = async () => {
      setLoading(true);
      try {
        const response = await fetch('/api/data');
        const jsonData = await response.json();
        setData(jsonData);
      } catch (err) {
        setError(err);
      } finally {
        setLoading(false);
      }
    };

    fetchData();
  }, []); // Empty dependency array for initial fetch

  if (loading) return <p>Loading...</p>;
  if (error) return <p>Error: {error.message}</p>;
  if (!data) return <p>No data to display</p>;

  return (
    <div>
      {/* Display your data here */}
      <pre>{JSON.stringify(data, null, 2)}</pre>
    </div>
  );
}

export default MyComponent;

While this approach works, it quickly becomes bulky as applications grow in complexity. Here's why:

Manual Loading and Error Handling: You're responsible for managing loading and error states manually, leading to repetitive code across components.
No Automatic Caching: Every time the component mounts (or the dependency array changes), a new API call is made, even if the data hasn't changed. This wastes bandwidth and can lead to a poor user experience.
Manual Refetching: If the data on the server changes, you need to implement a mechanism to manually refetch the data.
Stale Data: The data displayed might be stale, especially if the user switches between tabs or navigates away and back to the component.
Complex State Management: Managing multiple states (data, loading, error) can become challenging, especially in more complex scenarios.

React Query to the Rescue

React Query is a powerful library that simplifies data fetching, caching, and state management in React applications. It provides a declarative and efficient way to interact with APIs, reducing boilerplate code and improving the overall development experience.

Here's how the same data fetching logic looks with React Query:

import { useQuery } from 'react-query';

async function fetchData() {
  const response = await fetch('/api/data');
  return response.json();
}

function MyComponent() {
  const { data, isLoading, error } = useQuery('myData', fetchData);

  if (isLoading) return <p>Loading...</p>;
  if (error) return <p>Error: {error.message}</p>;
  if (!data) return <p>No data to display</p>;

  return (
    <div>
      {/* Display your data here */}
      <pre>{JSON.stringify(data, null, 2)}</pre>
    </div>
  );
}

export default MyComponent;

Notice how much cleaner and more concise the code is. React Query handles the loading, error, and data states internally, freeing you from managing them manually.

Key Benefits of React Query

Here's a breakdown of the key advantages React Query offers:

Automatic Caching: React Query automatically caches data in memory, so subsequent requests for the same data are served from the cache instead of making a network request. This significantly improves performance and reduces network traffic. The cache is intelligently managed, invalidating stale data based on configurable settings.
Refetch on Focus: React Query automatically refetches data when the user refocuses the browser window or tab. This ensures that the data displayed is always fresh and up-to-date. This behavior is configurable and can be disabled if needed.
Built-in Loading and Error States: React Query provides built-in isLoading and error states, eliminating the need to manage them manually. This simplifies the component logic and reduces boilerplate code.
Smart Syncing: React Query provides powerful mutation capabilities that allow you to update data on the server and automatically sync the changes across your application. This ensures data consistency and eliminates the need for manual state updates. Optimistic updates and rollback mechanisms are also supported.
Background Updates: React Query can automatically update data in the background, ensuring that the user always sees the most recent information without interrupting their workflow.
Pagination and Infinite Scrolling: React Query provides built-in support for pagination and infinite scrolling, making it easy to handle large datasets.
Devtools: React Query comes with a powerful devtools extension that allows you to inspect the cache, view query status, and trigger manual refetches. This makes debugging and troubleshooting much easier.

Conclusion

React Query is a game-changer for data fetching in React applications. It provides a declarative, efficient, and maintainable way to manage data, reducing boilerplate code and improving the overall development experience. If you're still using useEffect and useState for data fetching, I highly recommend giving React Query a try. You'll be amazed at how much simpler and more efficient your data management can be.

Implementing a CDN in Your React App in 3 Simple Steps

saijami — Wed, 25 Jun 2025 03:06:21 +0000

If your React app is feeling sluggish, overwhelmed by traffic, or just generally underperforming, the problem might not be your code itself, but rather how you're delivering it to your users. A CDN can provide a number of benefits to your React project:

⚡ Faster First-Load
Core libraries already cached at edge servers; your app bundle is all that needs fetching.
📈 Instant Global Scale
CDNs handle sudden traffic spikes without breaking a sweat.
💸 Lower Hosting Costs
Offload bandwidth-intensive static delivery—your origin server just serves dynamic requests.
🔄 Zero-Config Caching
CDNs cache assets automatically; you only purge when you deploy new versions.
🔒 Built-In Security & SSL
Most CDNs offer free HTTPS, DDoS mitigation, and bot protection out of the box.

Leverage a CDN to slash load times and offload your server—plus pull in popular React libraries directly from the edge. Let’s dive in.

Build Your React App

npm run build
# or
yarn build

This spins up a build/ folder with all your minified JS/CSS ready for distribution.

2.Host Your Build on a CDN

Pick any modern CDN (Cloudflare, Netlify, Vercel, AWS CloudFront). Then either:

Drag & drop your build/ folder into their dashboard
Connect your Git repo for automatic deploys on every push

Deploy time: under a minute.

3.Load Assets & Libraries via CDN in index.html
Instead of bundling every dependency, point your HTML to both your app bundle and key React libraries on the CDN. In your public/index.html, replace or augment scripts like this:

<!DOCTYPE html>
<html lang="en">
<head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width,initial-scale=1" />
  <title>My React App</title>

  <!-- Preconnect to speed up DNS/TLS -->
  <link rel="preconnect" href="https://unpkg.com" />

  <!-- Popular React Libraries via CDN -->
  <!-- React & ReactDOM -->
  <script crossorigin src="https://unpkg.com/react@18/umd/react.production.min.js"></script>
  <script crossorigin src="https://unpkg.com/react-dom@18/umd/react-dom.production.min.js"></script>

  <!-- Redux (state management) -->
  <script src="https://unpkg.com/redux@4/umd/redux.min.js"></script>
  <script src="https://unpkg.com/react-redux@8/umd/react-redux.min.js"></script>

  <!-- React Router (routing) -->
  <script src="https://unpkg.com/react-router-dom@6/umd/react-router-dom.min.js"></script>

  <!-- Axios (HTTP client) -->
  <script src="https://unpkg.com/axios/dist/axios.min.js"></script>

  <!-- Lodash (utilities) -->
  <script src="https://unpkg.com/lodash/lodash.min.js"></script>

  <!-- Your App Bundle (served from your CDN) -->
  <script defer src="https://your-cdn-domain.com/static/js/main.[hash].js"></script>
</head>
<body>
  <div id="root"></div>
</body>
</html>

Wrap-Up

Build your app.
Deploy build/ to a CDN.
Load both your bundle and popular React libs via CDN script tags.

Deploy in under five minutes—then watch your performance and reliability skyrocket. Happy coding!

Boost Your React App Performance with Lazy Loading

saijami — Sun, 22 Jun 2025 03:42:04 +0000

🧠 What Is Lazy Loading?
Lazy loading delays loading components, images, or routes until they're actually needed. Instead of bundling your entire app upfront, you load only what the user needs first - improving initial load times and bandwidth usage.

💡 Key Benefits
Faster initial page loads - fewer unused components ship immediately.
Reduced bandwidth usage - only loaded when requested.
Improved user experience - above-the-fold content appears quickly.
Scalable architecture - lazy loading keeps large codebases performant.

🛠️ How to Implement Lazy Loading in React
1.Component-Level with React.lazy() + Suspense

import React, { lazy, Suspense } from 'react';

const LazyComponent = lazy(() => import('./LazyComponent'));

function App() {
  return (
    <Suspense fallback={<div>Loading...</div>}>
      <LazyComponent />
    </Suspense>
  );
}

2.Route-Based Loading (React Router)

import { BrowserRouter as Router, Routes, Route } from 'react-router-dom';
import { lazy, Suspense } from 'react';

const Home = lazy(() => import('./Home'));
const ImagePage = lazy(() => import('./Image'));

function App() {
  return (
    <Router>
      <Suspense fallback={<div>Loading page...</div>}>
        <Routes>
          <Route path="/" element={<Home />} />
          <Route path="/image" element={<ImagePage />} />
        </Routes>
      </Suspense>
    </Router>
  );
}

3.Image & Component Libraries

import LazyLoad from 'react-lazyload';

<LazyLoad height={200} once>
  <img src="..." alt="…" />
</LazyLoad>

4.Dynamic Imports with Buttons or Interactions

const LazyProfile = lazy(() => import('./LazyProfile'));

function App() {
  const [showProfile, setShowProfile] = useState(false);

  return (
    <>
      <button onClick={() => setShowProfile(!showProfile)}>
        {showProfile ? 'Hide' : 'Show'} Profile
      </button>
      {showProfile && (
        <Suspense fallback={<div>Loading...</div>}>
          <LazyProfile />
        </Suspense>
      )}
    </>
  );
}

✅ Best Practices

Lazy-load only non-critical code - e.g., modals, routes, images.
Always pair with fallback UI using Suspense.
Consider preloading components likely to be used soon.
Handle errors gracefully with Error Boundaries.
Test on real devices and low-bandwidth connections.

🔚 Final Words
Done right, lazy loading reduces initial payloads, improves perceived responsiveness, and keeps your app scalable. Done poorly, it adds complexity and brittle flows.
Try adding a lazy-loaded route or image to your next React build - it could save your user seconds of load time.

The Art of State Management in React: Avoiding Common Pitfalls

saijami — Sat, 14 Jun 2025 04:30:33 +0000

Not every app needs Redux. Not every bug needs Zustand.
Yet so many React developers (me included) jump to global state tools too early — and pay for it with bloated code and hard-to-follow flows.
Here’s what I wish I’d known earlier:👇

The 80/20 Rule of State Management:
🔹 80% of your state should stay local — where it belongs.
🔹 Only 20% truly needs global sync and control.

🧠 My personal tool progression (the hard way):
➡️ useState → For simple local state
➡️ useReducer → When logic got messy
➡️ Context → Sharing across 3–5 components
➡️ Zustand/Redux → When true global, persistent state was unavoidable

Here’s a simple cheat sheet I use now:👇
✅ Stick with local state when:
• State is used in a single component
• Logic is easy to test and reason about
• No cross-page sync is needed
⚙️ Reach for external tools when:
• You’re syncing state across routes or sessions
• You need undo/redo, throttling, persistence
• You’re hitting performance limits from context nesting or prop drilling
Zustand is lean and intuitive.
Redux is powerful but comes with overhead.
Context is great — until it’s not.
The tool isn’t the problem. Knowing when to use it is.
💬 What’s your biggest React state management mistake?
Let’s make the community smarter, one insight at a time.