Optimizing React Applications with Code Splitting and Lazy Loading

  • Web Development
On this page

React Code Splitting and Lazy Loading: A Practical Guide to Better Performance

Performance is one of the most important factors in the success of a modern web application. Users expect pages to load quickly, interactions to feel smooth, and content to become available without unnecessary delays.

As React applications grow, their JavaScript bundles can also become larger. More features, dependencies, components, and pages mean more code for the browser to download, parse, and execute.

One effective way to address this problem is through code splitting and lazy loading.

Instead of sending the entire application to the browser on the initial load, you can split your application into smaller chunks and load them only when they are needed.

In this guide, we'll explore how code splitting works in React, how to implement lazy loading with React.lazy() and Suspense, how to split routes with React Router, and how Vite handles code splitting in production builds.

Why Performance Matters in React Applications

When a user opens a React application, the browser needs to download JavaScript and then parse and execute it before the application becomes fully interactive.

As an application grows, a single JavaScript bundle can become unnecessarily large.

This can lead to:

  • Slower initial page loads
  • Increased bandwidth consumption
  • Longer time-to-interactive
  • Higher memory usage
  • Poorer performance on mobile devices
  • A less responsive user experience

This is particularly noticeable for users on slower networks or less powerful devices.

The goal is not to eliminate JavaScript. Instead, the goal is to make sure users only download the JavaScript they actually need.

That's where code splitting comes in.

What Is Code Splitting?

Code splitting is a technique used to divide a large JavaScript bundle into multiple smaller chunks.

Without code splitting, an application might load code for every page and feature when the user first visits the website.

For example, imagine an application with:

  • Home
  • Dashboard
  • Profile
  • Settings
  • Reports
  • Admin panel

A user visiting the homepage probably doesn't need the JavaScript required for the reports or admin panel immediately.

With code splitting, these parts of the application can be separated into individual chunks and downloaded when they are required.

This can help:

  • Reduce the initial JavaScript payload
  • Improve initial load performance
  • Reduce unnecessary network usage
  • Improve application scalability
  • Make better use of browser caching

React applications can take advantage of code splitting through dynamic imports.

For example:

import("./Dashboard");

The dynamic import creates a separate loading point that modern bundlers such as Vite can turn into a separate JavaScript chunk.

What Is Lazy Loading?

Lazy loading is closely related to code splitting.

Instead of loading a component immediately, lazy loading allows the application to load it only when it is actually required.

React provides React.lazy() specifically for this purpose.

This is particularly useful for:

  • Application routes
  • Large components
  • Dashboards
  • Reports
  • Admin panels
  • Feature-heavy sections
  • Components that aren't immediately visible

For example:

import React, { Suspense } from "react";

const LazyComponent = React.lazy(() => import("./LazyComponent"));

function App() {
  return (
    <div>
      <h1>Welcome to Bugbittle</h1>

      <Suspense fallback={<div>Loading...</div>}>
        <LazyComponent />
      </Suspense>
    </div>
  );
}

export default App;

Here, LazyComponent isn't loaded as part of the initial JavaScript execution.

When React needs to render the component, the corresponding chunk is requested from the server.

While that happens, Suspense displays the fallback UI.

Understanding React.lazy() and Suspense

There are two important pieces in this example.

React.lazy()

React.lazy() allows a component to be loaded using a dynamic import.

const Dashboard = React.lazy(() => import("./Dashboard"));

The component is loaded when React attempts to render it.

Suspense

Because the component may not be available immediately, React needs something to display while it is loading.

That's what Suspense provides:

<Suspense fallback={<div>Loading...</div>}>
  <Dashboard />
</Suspense>

The fallback can be a simple loading message, skeleton screen, spinner, or any other loading experience.

For production applications, a skeleton or properly designed loading state is usually better than displaying a plain "Loading..." message.

Route-Based Code Splitting

One of the best places to implement code splitting is application routing.

Most users don't visit every page during a single session, so loading all route components upfront can waste bandwidth.

With React Router, each route can be lazy-loaded independently.

For example:

import React, { Suspense } from "react";
import { BrowserRouter, Routes, Route } from "react-router-dom";

const Home = React.lazy(() => import("./Home"));
const About = React.lazy(() => import("./About"));
const Contact = React.lazy(() => import("./Contact"));

function App() {
  return (
    <BrowserRouter>
      <Suspense fallback={<div>Loading...</div>}>
        <Routes>
          <Route path="/" element={<Home />} />
          <Route path="/about" element={<About />} />
          <Route path="/contact" element={<Contact />} />
        </Routes>
      </Suspense>
    </BrowserRouter>
  );
}

export default App;

Now, the application doesn't need to download all three page components when the user opens the homepage.

The relevant route's JavaScript can be downloaded when the user navigates to it.

For larger applications, route-based splitting can make a significant difference to the initial JavaScript payload.

Lazy Loading Large Features

Lazy loading isn't limited to routes.

You can also use it for large parts of your application that aren't immediately required.

For example, suppose an application contains a reporting system with charts, tables, filters, and data-processing libraries.

Instead of loading all of that code when the application starts, you can defer it:

const Reports = React.lazy(() => import("./Reports"));

This keeps the initial application smaller while allowing the reports section to load when the user needs it.

The same strategy can be useful for:

  • Rich text editors
  • Charting libraries
  • Maps
  • PDF viewers
  • Advanced filters
  • Admin tools
  • Complex forms

When Lazy Loading Can Cause Delays

Lazy loading isn't a magic solution.

Although it reduces the amount of JavaScript downloaded initially, the user may experience a short delay when opening a lazy-loaded feature for the first time.

For example:

  1. The user opens the application.
  2. The dashboard code isn't loaded yet.
  3. The user navigates to the dashboard.
  4. The browser requests the dashboard chunk.
  5. React displays the loading state.
  6. The dashboard becomes available.

The delay depends on factors such as network speed, server performance, device performance, and chunk size.

This is why loading states are important.

More importantly, you shouldn't blindly lazy-load everything. Components that are used immediately or frequently may be better kept in the initial bundle.

Preloading Components When Appropriate

Sometimes you know what the user is likely to do next.

For example, if the user is currently viewing the homepage and is likely to open the dashboard, you can begin downloading the dashboard code before they actually navigate there.

A simple approach is:

const Dashboard = React.lazy(() => import("./Dashboard"));

function preloadDashboard() {
  import("./Dashboard");
}

You could then call preloadDashboard() when appropriate—for example, when a user hovers over a dashboard navigation link.

This gives the browser a chance to download the chunk before the component is rendered.

The key is to preload based on user intent or likely navigation, rather than immediately downloading every lazy-loaded component.

Code Splitting with Vite

Vite has excellent support for code splitting through dynamic imports.

For example:

const Dashboard = React.lazy(() => import("./Dashboard"));

During a production build, Vite uses Rollup to analyze the application and generate separate chunks for dynamically imported modules.

This means you don't normally need to manually configure code splitting for basic use cases.

A typical build might produce files similar to:

assets/
  index.js
  Dashboard.js
  Reports.js
  Settings.js

The exact output depends on your project and Vite's build optimization.

The important point is that the application can load these chunks independently instead of downloading everything upfront.

Manual Chunking in Vite

For larger applications, you may sometimes want more control over how dependencies are grouped.

Vite allows you to configure Rollup's chunking behavior.

For example:

export default {
  build: {
    rollupOptions: {
      output: {
        manualChunks: {
          vendor: ["react", "react-dom"]
        }
      }
    }
  }
};

This can place selected dependencies into a separate chunk.

One potential advantage is improved caching.

For example, if your application code changes but React itself doesn't, the browser may be able to continue using the cached dependency chunk.

However, manual chunking shouldn't automatically be considered an optimization.

Vite and Rollup already perform chunking and optimization, so manual configuration should generally be introduced after analyzing your production bundle and identifying a specific problem.

Measuring Bundle Size

Before making optimization decisions, it's useful to understand what's actually making your application large.

Instead of guessing, analyze your production build.

Look for:

  • Large dependencies
  • Duplicate packages
  • Large route chunks
  • Heavy third-party libraries
  • Unused code
  • Unexpectedly large components

Tools such as Lighthouse and bundle analyzers can help you identify these issues.

For example, replacing a large dependency with a smaller alternative may sometimes provide a bigger performance improvement than introducing additional lazy-loading boundaries.

Lazy Loading vs. Loading Everything Upfront

The difference can be summarized simply.

Without code splitting

User opens application
        ↓
Download large JavaScript bundle
        ↓
Parse and execute JavaScript
        ↓
Application becomes interactive

With code splitting

User opens application
        ↓
Download essential JavaScript
        ↓
Application becomes interactive
        ↓
User opens Dashboard
        ↓
Download Dashboard chunk
        ↓
Render Dashboard

The second approach allows the initial page to become usable without requiring every feature to be downloaded first.

Benefits of Code Splitting and Lazy Loading

When used correctly, code splitting provides several important benefits.

Faster Initial Loading

The browser has less JavaScript to download and process during the initial visit.

Smaller Initial Bundles

Large features can be moved into separate chunks instead of being included in the initial bundle.

Better Mobile Performance

Smaller initial payloads can be particularly helpful for users on slower networks or lower-powered devices.

Better Caching

Separating application code from relatively stable dependencies can sometimes improve browser caching.

Improved Scalability

As an application grows, code splitting helps prevent every new feature from increasing the initial bundle unnecessarily.

Better User Experience

Users can reach the initial interface faster while additional features load when needed.

Potential Drawbacks

Code splitting also introduces some trade-offs.

Additional Network Requests

More chunks can mean more requests, although modern browsers and HTTP protocols handle multiple requests efficiently.

Loading States

Users may see a loading state when accessing a chunk for the first time.

Increased Complexity

Applications need to handle loading and error states properly.

Poor Splitting Can Hurt Performance

Creating too many tiny chunks isn't necessarily better.

The goal is to find a sensible balance between initial bundle size and the number of chunks loaded during navigation.

Handling Lazy-Loaded Component Errors

Lazy-loaded components depend on successful network requests.

If a chunk fails to download—for example, because of a temporary network problem or a deployment-related caching issue—the component may fail to render.

For production applications, consider using an error boundary around important lazy-loaded sections.

This allows you to display a useful error message or provide a retry option instead of leaving the user with a broken interface.

Best Practices for React Code Splitting

To get the most out of code splitting and lazy loading, keep these practices in mind:

  • Lazy-load routes and large features.
  • Avoid lazy-loading every small component.
  • Keep frequently used UI elements in the initial bundle.
  • Use meaningful loading states.
  • Preload predictable next actions when appropriate.
  • Analyze your production bundle before manually changing chunk configuration.
  • Monitor bundle sizes as the application grows.
  • Avoid unnecessarily large third-party dependencies.
  • Use error boundaries around important lazy-loaded sections.
  • Test performance on slower networks and lower-end devices.

The goal isn't to load less code at any cost.

The goal is to load the right code at the right time.

Final Thoughts

Code splitting and lazy loading are powerful techniques for keeping React applications fast as they grow.

By splitting large applications into smaller chunks, you can reduce the amount of JavaScript required during the initial page load and defer less frequently used features until they are actually needed.

React provides React.lazy() and Suspense to make component-level lazy loading straightforward, while Vite and Rollup handle much of the underlying bundling and chunk generation automatically.

For most applications, a good starting point is simple:

  1. Lazy-load application routes.
  2. Identify large features that don't need to load immediately.
  3. Analyze your production bundle.
  4. Preload features when there is a strong reason to expect they will be needed soon.
  5. Measure the results instead of optimizing based on assumptions.

Performance optimization is rarely about one single technique. Code splitting is one piece of the larger picture, but when applied thoughtfully, it can make a noticeable difference in how quickly and smoothly a React application feels.

Build for the experience users need now—and load everything else when they actually need it.

Related articles